[dragonfly.git] / share / man / man7 / tuning.7
1 .\" Copyright (c) 2001 Matthew Dillon.  Terms and conditions are those of
2 .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in
3 .\" the source tree.
4 .\"
5 .Dd June 12, 2016
6 .Dt TUNING 7
7 .Os
8 .Sh NAME
9 .Nm tuning
10 .Nd performance tuning under DragonFly
12 Modern
13 .Dx
14 systems typically have just three partitions on the main drive.
15 In order, a UFS
16 .Pa /boot ,
17 .Pa swap ,
18 and a HAMMER
19 .Pa root .
20 The installer used to create separate PFSs for half a dozen directories,
21 but now it just puts (almost) everything in the root.
22 It will separate stuff that doesn't need to be backed up into a /build
23 subdirectory and create null-mounts for things like /usr/obj, but it
24 no longer creates separate PFSs for these.
25 If desired, you can make /build its own mount to separate-out the
26 components of the filesystem which do not need to be persistent.
27 .Pp
28 Generally speaking the
29 .Pa /boot
30 partition should be 1GB in size.  This is the minimum recommended
31 size, giving you room for backup kernels and alternative boot schemes.
32 .Dx
33 always installs debug-enabled kernels and modules and these can take
34 up quite a bit of disk space (but will not take up any extra ram).
35 .Pp
36 In the old days we recommended that swap be sized to at least 2x main
37 memory.  These days swap is often used for other activities, including
38 .Xr tmpfs 5
39 and
40 .Xr swapcache 8 .
41 We recommend that swap be sized to the larger of 2x main memory or
42 1GB if you have a fairly small disk and 16GB or more if you have a
43 modestly endowed system.
44 If you have a modest SSD + large HDD combination, we recommend
45 a large dedicated swap partition on the SSD.  For example, if
46 you have a 128GB SSD and 2TB or more of HDD storage, dedicating
47 upwards of 64GB of the SSD to swap and using
48 .Xr swapcache 8
49 and
50 .Xr tmpfs 5
51 will significantly improve your HDD's performance.
52 .Pp
53 In an all-SSD or mostly-SSD system,
54 .Xr swapcache 8
55 is not normally used but you may still want to have a large swap
56 partition to support
57 .Xr tmpfs 5
58 use.
59 Our synth/poudriere build machines run with a 200GB
60 swap partition and use tmpfs for all the builder jails.  50-100 GB
61 is swapped out at the peak of the build.  As a result, actual
62 system storage bandwidth is minimized and performance increased.
63 .Pp
64 If you are on a minimally configured machine you may, of course,
65 configure far less swap or no swap at all but we recommend at least
66 some swap.
67 The kernel's VM paging algorithms are tuned to perform best when there is
68 swap space configured.
69 Configuring too little swap can lead to inefficiencies in the VM
70 page scanning code as well as create issues later on if you add
71 more memory to your machine, so don't be shy about it.
72 Swap is a good idea even if you don't think you will ever need it as it
73 allows the
74 machine to page out completely unused data and idle programs (like getty),
75 maximizing the ram available for your activities.
76 .Pp
77 If you intend to use the
78 .Xr swapcache 8
79 facility with a SSD + HDD combination we recommend configuring as much
80 swap space as you can on the SSD.
81 However, keep in mind that each 1GByte of swapcache requires around
82 1MByte of ram, so don't scale your swap beyond the equivalent ram
83 that you reasonably want to eat to support it.
84 .Pp
85 Finally, on larger systems with multiple drives, if the use
86 of SSD swap is not in the cards or if it is and you need higher-than-normal
87 swapcache bandwidth, you can configure swap on up to four drives and
88 the kernel will interleave the storage.
89 The swap partitions on the drives should be approximately the same size.
90 The kernel can handle arbitrary sizes but
91 internal data structures scale to 4 times the largest swap partition.
92 Keeping
93 the swap partitions near the same size will allow the kernel to optimally
94 stripe swap space across the N disks.
95 Do not worry about overdoing it a
96 little, swap space is the saving grace of
97 .Ux
98 and even if you do not normally use much swap, it can give you more time to
99 recover from a runaway program before being forced to reboot.
100 However, keep in mind that any sort of swap space failure can lock the
101 system up.
102 Most machines are setup with only one or two swap partitions.
103 .Pp
104 Most
105 .Dx
106 systems have a single HAMMER root.
107 PFSs can be used to administratively separate domains for backup purposes
108 but tend to be a hassle otherwise so if you don't need the administrative
109 separation you don't really need to use multiple HAMMER PFSs.
110 All the PFSs share the same allocation layer so there is no longer a need
111 to size each individual mount.
112 Instead you should review the
113 .Xr hammer 8
114 manual page and use the 'hammer viconfig' facility to adjust snapshot
115 retention and other parameters.
116 By default
117 HAMMER keeps 60 days worth of snapshots.
118 Usually snapshots are not desired on PFSs such as
119 .Pa /usr/obj
120 or
121 .Pa /tmp
122 since data on these partitions cycles a lot.
123 .Pp
124 If a very large work area is desired it is often beneficial to
125 configure it as a separate HAMMER mount.  If it is integrated into
126 the root mount it should at least be its own HAMMER PFS.
127 We recommend naming the large work area
128 .Pa /build .
129 Similarly if a machine is going to have a large number of users
130 you might want to separate your
131 .Pa /home
132 out as well.
133 .Pp
134 A number of run-time
135 .Xr mount 8
136 options exist that can help you tune the system.
137 The most obvious and most dangerous one is
138 .Cm async .
139 Do not ever use it; it is far too dangerous.
140 A less dangerous and more
141 useful
142 .Xr mount 8
143 option is called
144 .Cm noatime .
145 .Ux
146 filesystems normally update the last-accessed time of a file or
147 directory whenever it is accessed.
148 However, this creates a massive burden on copy-on-write filesystems like
149 HAMMER, particularly when scanning the filesystem.
150 .Dx
151 currently defaults to disabling atime updates on HAMMER mounts.
152 It can be enabled by setting the
153 .Va vfs.hammer.noatime
154 tunable to 0 in
155 .Xr loader.conf 5
156 but we recommend leaving it disabled.
157 The lack of atime updates can create issues with certain programs
158 such as when detecting whether unread mail is present, but
159 applications for the most part no longer depend on it.
160 .Sh SSD SWAP
161 The single most important thing you can do is have at least one
162 solid-state drive in your system, and configure your swap space
163 on that drive.
164 If you are using a combination of a smaller SSD and a very larger HDD,
165 you can use
166 .Xr swapcache 8
167 to automatically cache data from your HDD.
168 But even if you do not, having swap space configured on your SSD will
169 significantly improve performance under even modest paging loads.
170 It is particularly useful to configure a significant amount of swap
171 on a workstation, 32GB or more is not uncommon, to handle bloated
172 leaky applications such as browsers.
174 .Xr sysctl 8
175 variables permit system behavior to be monitored and controlled at
176 run-time.
177 Some sysctls simply report on the behavior of the system; others allow
178 the system behavior to be modified;
179 some may be set at boot time using
180 .Xr rc.conf 5 ,
181 but most will be set via
182 .Xr sysctl.conf 5 .
183 There are several hundred sysctls in the system, including many that appear
184 to be candidates for tuning but actually are not.
185 In this document we will only cover the ones that have the greatest effect
186 on the system.
187 .Pp
188 The
189 .Va kern.ipc.shm_use_phys
190 sysctl defaults to 1 (on) and may be set to 0 (off) or 1 (on).
191 Setting
192 this parameter to 1 will cause all System V shared memory segments to be
193 mapped to unpageable physical RAM.
194 This feature only has an effect if you
195 are either (A) mapping small amounts of shared memory across many (hundreds)
196 of processes, or (B) mapping large amounts of shared memory across any
197 number of processes.
198 This feature allows the kernel to remove a great deal
199 of internal memory management page-tracking overhead at the cost of wiring
200 the shared memory into core, making it unswappable.
201 .Pp
202 The
203 .Va vfs.write_behind
204 sysctl defaults to 1 (on).  This tells the filesystem to issue media
205 writes as full clusters are collected, which typically occurs when writing
206 large sequential files.  The idea is to avoid saturating the buffer
207 cache with dirty buffers when it would not benefit I/O performance.  However,
208 this may stall processes and under certain circumstances you may wish to turn
209 it off.
210 .Pp
211 The
212 .Va vfs.hirunningspace
213 sysctl determines how much outstanding write I/O may be queued to
214 disk controllers system wide at any given instance.  The default is
215 usually sufficient but on machines with lots of disks you may want to bump
216 it up to four or five megabytes.  Note that setting too high a value
217 (exceeding the buffer cache's write threshold) can lead to extremely
218 bad clustering performance.  Do not set this value arbitrarily high!  Also,
219 higher write queueing values may add latency to reads occurring at the same
220 time.
221 The
222 .Va vfs.bufcache_bw
223 controls data cycling within the buffer cache.  I/O bandwidth less than
224 this specification (per second) will cycle into the much larger general
225 VM page cache while I/O bandwidth in excess of this specification will
226 be recycled within the buffer cache, reducing the load on the rest of
227 the VM system.
228 The default value is 200 megabytes (209715200), which means that the
229 system will try harder to cache data coming off a slower hard drive
230 and less hard trying to cache data coming off a fast SSD.
231 This parameter is particularly important if you have NVMe drives in
232 your system as these storage devices are capable of transferring
233 well over 2GBytes/sec into the system.
234 .Pp
235 There are various other buffer-cache and VM page cache related sysctls.
236 We do not recommend modifying their values.
237 As of
238 .Dx 4.3 ,
239 the VM system does an extremely good job tuning itself.
240 .Pp
241 The
242 .Va net.inet.tcp.sendspace
243 and
244 .Va net.inet.tcp.recvspace
245 sysctls are of particular interest if you are running network intensive
246 applications.
247 They control the amount of send and receive buffer space
248 allowed for any given TCP connection.
249 However,
250 .Dx
251 now auto-tunes these parameters using a number of other related
252 sysctls (run 'sysctl net.inet.tcp' to get a list) and usually
253 no longer need to be tuned manually.
254 We do not recommend
255 increasing or decreasing the defaults if you are managing a very large
256 number of connections.
257 Note that the routing table (see
258 .Xr route 8 )
259 can be used to introduce route-specific send and receive buffer size
260 defaults.
261 .Pp
262 As an additional management tool you can use pipes in your
263 firewall rules (see
264 .Xr ipfw 8 )
265 to limit the bandwidth going to or from particular IP blocks or ports.
266 For example, if you have a T1 you might want to limit your web traffic
267 to 70% of the T1's bandwidth in order to leave the remainder available
268 for mail and interactive use.
269 Normally a heavily loaded web server
270 will not introduce significant latencies into other services even if
271 the network link is maxed out, but enforcing a limit can smooth things
272 out and lead to longer term stability.
273 Many people also enforce artificial
274 bandwidth limitations in order to ensure that they are not charged for
275 using too much bandwidth.
276 .Pp
277 Setting the send or receive TCP buffer to values larger than 65535 will result
278 in a marginal performance improvement unless both hosts support the window
279 scaling extension of the TCP protocol, which is controlled by the
280 .Va net.inet.tcp.rfc1323
281 sysctl.
282 These extensions should be enabled and the TCP buffer size should be set
283 to a value larger than 65536 in order to obtain good performance from
284 certain types of network links; specifically, gigabit WAN links and
285 high-latency satellite links.
286 RFC 1323 support is enabled by default.
287 .Pp
288 The
289 .Va net.inet.tcp.always_keepalive
290 sysctl determines whether or not the TCP implementation should attempt
291 to detect dead TCP connections by intermittently delivering
292 .Dq keepalives
293 on the connection.
294 By default, this is now enabled for all applications.
295 We do not recommend turning it off.
296 The extra network bandwidth is minimal and this feature will clean-up
297 stalled and long-dead connections that might not otherwise be cleaned
298 up.
299 In the past people using dialup connections often did not want to
300 use this feature in order to be able to retain connections across
301 long disconnections, but in modern day the only default that makes
302 sense is for the feature to be turned on.
303 .Pp
304 The
305 .Va net.inet.tcp.delayed_ack
306 TCP feature is largely misunderstood.  Historically speaking this feature
307 was designed to allow the acknowledgement to transmitted data to be returned
308 along with the response.  For example, when you type over a remote shell
309 the acknowledgement to the character you send can be returned along with the
310 data representing the echo of the character.   With delayed acks turned off
311 the acknowledgement may be sent in its own packet before the remote service
312 has a chance to echo the data it just received.  This same concept also
313 applies to any interactive protocol (e.g. SMTP, WWW, POP3) and can cut the
314 number of tiny packets flowing across the network in half.   The
315 .Dx
316 delayed-ack implementation also follows the TCP protocol rule that
317 at least every other packet be acknowledged even if the standard 100ms
318 timeout has not yet passed.  Normally the worst a delayed ack can do is
319 slightly delay the teardown of a connection, or slightly delay the ramp-up
320 of a slow-start TCP connection.  While we aren't sure we believe that
321 the several FAQs related to packages such as SAMBA and SQUID which advise
322 turning off delayed acks may be referring to the slow-start issue.
323 .Pp
324 The
325 .Va net.inet.tcp.inflight_enable
326 sysctl turns on bandwidth delay product limiting for all TCP connections.
327 This feature is now turned on by default and we recommend that it be
328 left on.
329 It will slightly reduce the maximum bandwidth of a connection but the
330 benefits of the feature in reducing packet backlogs at router constriction
331 points are enormous.
332 These benefits make it a whole lot easier for router algorithms to manage
333 QOS for multiple connections.
334 The limiting feature reduces the amount of data built up in intermediate
335 router and switch packet queues as well as reduces the amount of data built
336 up in the local host's interface queue.  With fewer packets queued up,
337 interactive connections, especially over slow modems, will also be able
338 to operate with lower round trip times.  However, note that this feature
339 only affects data transmission (uploading / server-side).  It does not
340 affect data reception (downloading).
341 .Pp
342 The system will attempt to calculate the bandwidth delay product for each
343 connection and limit the amount of data queued to the network to just the
344 amount required to maintain optimum throughput.  This feature is useful
345 if you are serving data over modems, GigE, or high speed WAN links (or
346 any other link with a high bandwidth*delay product), especially if you are
347 also using window scaling or have configured a large send window.
348 .Pp
349 For production use setting
350 .Va net.inet.tcp.inflight_min
351 to at least 6144 may be beneficial.  Note, however, that setting high
352 minimums may effectively disable bandwidth limiting depending on the link.
353 .Pp
354 Adjusting
355 .Va net.inet.tcp.inflight_stab
356 is not recommended.
357 This parameter defaults to 50, representing +5% fudge when calculating the
358 bwnd from the bw.  This fudge is on top of an additional fixed +2*maxseg
359 added to bwnd.  The fudge factor is required to stabilize the algorithm
360 at very high speeds while the fixed 2*maxseg stabilizes the algorithm at
361 low speeds.  If you increase this value excessive packet buffering may occur.
362 .Pp
363 The
364 .Va net.inet.ip.portrange.*
365 sysctls control the port number ranges automatically bound to TCP and UDP
366 sockets.  There are three ranges:  A low range, a default range, and a
367 high range, selectable via an IP_PORTRANGE
368 .Fn setsockopt
369 call.
370 Most network programs use the default range which is controlled by
371 .Va net.inet.ip.portrange.first
372 and
373 .Va net.inet.ip.portrange.last ,
374 which defaults to 1024 and 5000 respectively.  Bound port ranges are
375 used for outgoing connections and it is possible to run the system out
376 of ports under certain circumstances.  This most commonly occurs when you are
377 running a heavily loaded web proxy.  The port range is not an issue
378 when running serves which handle mainly incoming connections such as a
379 normal web server, or has a limited number of outgoing connections such
380 as a mail relay.  For situations where you may run yourself out of
381 ports we recommend increasing
382 .Va net.inet.ip.portrange.last
383 modestly.  A value of 10000 or 20000 or 30000 may be reasonable.  You should
384 also consider firewall effects when changing the port range.  Some firewalls
385 may block large ranges of ports (usually low-numbered ports) and expect systems
386 to use higher ranges of ports for outgoing connections.  For this reason
387 we do not recommend that
388 .Va net.inet.ip.portrange.first
389 be lowered.
390 .Pp
391 The
392 .Va kern.ipc.somaxconn
393 sysctl limits the size of the listen queue for accepting new TCP connections.
394 The default value of 128 is typically too low for robust handling of new
395 connections in a heavily loaded web server environment.
396 For such environments,
397 we recommend increasing this value to 1024 or higher.
398 The service daemon
399 may itself limit the listen queue size (e.g.\&
400 .Xr sendmail 8 ,
401 apache) but will
402 often have a directive in its configuration file to adjust the queue size up.
403 Larger listen queues also do a better job of fending off denial of service
404 attacks.
405 .Pp
406 The
407 .Va kern.maxvnodes
408 specifies how many vnodes and related file structures the kernel will
409 cache.
410 The kernel uses a very generous default for this parameter based on
411 available physical memory.
412 You generally do not want to mess with this parameter as it directly
413 effects how well the kernel can cache not only file structures but also
414 the underlying file data.
415 But you can lower it if kernel memory use is higher than you would like.
416 .Pp
417 The
418 .Va kern.maxfiles
419 sysctl determines how many open files the system supports.
420 The default is
421 typically based on available physical memory but you may need to bump
422 it up if you are running databases or large descriptor-heavy daemons.
423 The read-only
424 .Va kern.openfiles
425 sysctl may be interrogated to determine the current number of open files
426 on the system.
427 .Pp
428 The
429 .Va vm.swap_idle_enabled
430 sysctl is useful in large multi-user systems where you have lots of users
431 entering and leaving the system and lots of idle processes.
432 Such systems
433 tend to generate a great deal of continuous pressure on free memory reserves.
434 Turning this feature on and adjusting the swapout hysteresis (in idle
435 seconds) via
436 .Va vm.swap_idle_threshold1
437 and
438 .Va vm.swap_idle_threshold2
439 allows you to depress the priority of pages associated with idle processes
440 more quickly than the normal pageout algorithm.
441 This gives a helping hand
442 to the pageout daemon.
443 Do not turn this option on unless you need it,
444 because the tradeoff you are making is to essentially pre-page memory sooner
445 rather than later, eating more swap and disk bandwidth.
446 In a small system
447 this option will have a detrimental effect but in a large system that is
448 already doing moderate paging this option allows the VM system to stage
449 whole processes into and out of memory more easily.
451 Some aspects of the system behavior may not be tunable at runtime because
452 memory allocations they perform must occur early in the boot process.
453 To change loader tunables, you must set their values in
454 .Xr loader.conf 5
455 and reboot the system.
456 .Pp
457 .Va kern.maxusers
458 controls the scaling of a number of static system tables, including defaults
459 for the maximum number of open files, sizing of network memory resources, etc.
460 On
461 .Dx ,
462 .Va kern.maxusers
463 is automatically sized at boot based on the amount of memory available in
464 the system, and may be determined at run-time by inspecting the value of the
465 read-only
466 .Va kern.maxusers
467 sysctl.
468 Some sites will require larger or smaller values of
469 .Va kern.maxusers
470 and may set it as a loader tunable; values of 64, 128, and 256 are not
471 uncommon.
472 We do not recommend going above 256 unless you need a huge number
473 of file descriptors; many of the tunable values set to their defaults by
474 .Va kern.maxusers
475 may be individually overridden at boot-time or run-time as described
476 elsewhere in this document.
477 .Pp
478 .Va kern.nbuf
479 sets how many filesystem buffers the kernel should cache.
480 Filesystem buffers can be up to 128KB each.  UFS typically uses an 8KB
481 blocksize while HAMMER typically uses 64KB.
482 The defaults usually suffice.
483 The cached buffers represent wired physical memory so specifying a value
484 that is too large can result in excessive kernel memory use, and is also
485 not entirely necessary since the pages backing the buffers are also
486 cached by the VM page cache (which does not use wired memory).
487 The buffer cache significantly improves the hot path for cached file
488 accesses.
489 .Pp
490 The
491 .Va kern.dfldsiz
492 and
493 .Va kern.dflssiz
494 tunables set the default soft limits for process data and stack size
495 respectively.
496 Processes may increase these up to the hard limits by calling
497 .Xr setrlimit 2 .
498 The
499 .Va kern.maxdsiz ,
500 .Va kern.maxssiz ,
501 and
502 .Va kern.maxtsiz
503 tunables set the hard limits for process data, stack, and text size
504 respectively; processes may not exceed these limits.
505 The
506 .Va kern.sgrowsiz
507 tunable controls how much the stack segment will grow when a process
508 needs to allocate more stack.
509 .Pp
510 .Va kern.ipc.nmbclusters
511 and
512 .Va kern.ipc.nmbjclusters
513 may be adjusted to increase the number of network mbufs the system is
514 willing to allocate.
515 Each normal cluster represents approximately 2K of memory,
516 so a value of 1024 represents 2M of kernel memory reserved for network
517 buffers.
518 Each 'j' cluster is typically 4KB, so a value of 1024 represents 4M of
519 kernel memory.
520 You can do a simple calculation to figure out how many you need but
521 keep in mind that tcp buffer sizing is now more dynamic than it used to
522 be.
523 .Pp
524 The defaults usually suffice but you may want to bump it up on service-heavy
525 machines.
526 Modern machines often need a large number of mbufs to operate services
527 efficiently, values of 65536, even upwards of 262144 or more are common.
528 If you are running a server, it is better to be generous than to be frugal.
529 Remember the memory calculation though.
530 .Pp
531 Under no circumstances
532 should you specify an arbitrarily high value for this parameter, it could
533 lead to a boot-time crash.
534 The
535 .Fl m
536 option to
537 .Xr netstat 1
538 may be used to observe network cluster use.
540 There are a number of kernel options that you may have to fiddle with in
541 a large-scale system.
542 In order to change these options you need to be
543 able to compile a new kernel from source.
544 The
545 .Xr config 8
546 manual page and the handbook are good starting points for learning how to
547 do this.
548 Generally the first thing you do when creating your own custom
549 kernel is to strip out all the drivers and services you do not use.
550 Removing things like
551 .Dv INET6
552 and drivers you do not have will reduce the size of your kernel, sometimes
553 by a megabyte or more, leaving more memory available for applications.
554 .Pp
555 If your motherboard is AHCI-capable then we strongly recommend turning
556 on AHCI mode in the BIOS if it is not the default.
558 The type of tuning you do depends heavily on where your system begins to
559 bottleneck as load increases.
560 If your system runs out of CPU (idle times
561 are perpetually 0%) then you need to consider upgrading the CPU or moving to
562 an SMP motherboard (multiple CPU's), or perhaps you need to revisit the
563 programs that are causing the load and try to optimize them.
564 If your system
565 is paging to swap a lot you need to consider adding more memory.
566 If your
567 system is saturating the disk you typically see high CPU idle times and
568 total disk saturation.
569 .Xr systat 1
570 can be used to monitor this.
571 There are many solutions to saturated disks:
572 increasing memory for caching, mirroring disks, distributing operations across
573 several machines, and so forth.
574 .Pp
575 Finally, you might run out of network suds.
576 Optimize the network path
577 as much as possible.
578 If you are operating a machine as a router you may need to
579 setup a
580 .Xr pf 4
581 firewall (also see
582 .Xr firewall 7 .
583 .Dx
584 has a very good fair-share queueing algorithm for QOS in
585 .Xr pf 4 .
587 The primary sources of kernel memory usage are:
588 .Bl -tag -width ".Va kern.maxvnodes"
589 .It Va kern.maxvnodes
590 The maximum number of cached vnodes in the system.
591 These can eat quite a bit of kernel memory, primarily due to auxiliary
592 structures tracked by the HAMMER filesystem.
593 It is relatively easy to configure a smaller value, but we do not
594 recommend reducing this parameter below 100000.
595 Smaller values directly impact the number of discrete files the
596 kernel can cache data for at once.
597 .It Va kern.ipc.nmbclusters , Va kern.ipc.nmbjclusters
598 Calculate approximately 2KB per normal cluster and 4KB per jumbo
599 cluster.
600 Do not make these values too low or you risk deadlocking the network
601 stack.
602 .It Va kern.nbuf
603 The number of filesystem buffers managed by the kernel.
604 The kernel wires the underlying cached VM pages, typically 8KB (UFS) or
605 64KB (HAMMER) per buffer.
606 .It swap/swapcache
607 Swap memory requires approximately 1MB of physical ram for each 1GB
608 of swap space.
609 When swapcache is used, additional memory may be required to keep
610 VM objects around longer (only really reducable by reducing the
611 value of
612 .Va kern.maxvnodes
613 which you can do post-boot if you desire).
614 .It tmpfs
615 Tmpfs is very useful but keep in mind that while the file data itself
616 is backed by swap, the meta-data (the directory topology) requires
617 wired kernel memory.
618 .It mmu page tables
619 Even though the underlying data pages themselves can be paged to swap,
620 the page tables are usually wired into memory.
621 This can create problems when a large number of processes are mmap()ing
622 very large files.
623 Sometimes turning on
624 .Va machdep.pmap_mmu_optimize
625 suffices to reduce overhead.
626 Page table kernel memory use can be observed by using 'vmstat -z'
627 .It Va kern.ipc.shm_use_phys
628 It is sometimes necessary to force shared memory to use physical memory
629 when running a large database which uses shared memory to implement its
630 own data caching.
631 The use of sysv shared memory in this regard allows the database to
632 distinguish between data which it knows it can access instantly (i.e.
633 without even having to page-in from swap) verses data which it might require
634 and I/O to fetch.
635 .Pp
636 If you use this feature be very careful with regards to the database's
637 shared memory configuration as you will be wiring the memory.
638 .El
639 .Sh SEE ALSO
640 .Xr netstat 1 ,
641 .Xr systat 1 ,
642 .Xr dm 4 ,
643 .Xr dummynet 4 ,
644 .Xr nata 4 ,
645 .Xr pf 4 ,
646 .Xr login.conf 5 ,
647 .Xr pf.conf 5 ,
648 .Xr rc.conf 5 ,
649 .Xr sysctl.conf 5 ,
650 .Xr firewall 7 ,
651 .Xr hier 7 ,
652 .Xr boot 8 ,
653 .Xr ccdconfig 8 ,
654 .Xr config 8 ,
655 .Xr disklabel 8 ,
656 .Xr fsck 8 ,
657 .Xr ifconfig 8 ,
658 .Xr ipfw 8 ,
659 .Xr loader 8 ,
660 .Xr mount 8 ,
661 .Xr newfs 8 ,
662 .Xr route 8 ,
663 .Xr sysctl 8 ,
664 .Xr tunefs 8
666 The
667 .Nm
668 manual page was originally written by
669 .An Matthew Dillon
670 and first appeared
671 in
672 .Dx 4.3 ,
673 May 2001.