A collection of useful/interesting stuff from the FBSD-stable mailing list.

Most of these posts have been trimmed down to provide more coherent top-to-bottom reading. My own FreeBSD notes and tips are here.

 > > > > Setting sendmail_enable to no in rc.conf does not work > > Bartosz Fabianowski: > > > Did you remember to set it to "NONE", not just "NO"? This distinction > > > was introduced a long time ago and sendmail_enable="NONE" has > > > always done the trick for me since then. > Freddie Cash: > > sendmail_enable="NONE" has been deprecated and will disappear in a > > future release. You need to explicitly set each of the > > sendmail_*_enable variables to NO in /etc/rc.conf. Bartosz Fabianowski: > Thanks for pointing that out. According to /etc/rc.d/sendmail, > sendmail_enable="NONE" corresponds to the following settings: > > sendmail_enable="NO" > sendmail_submit_enable="NO" > sendmail_outbound_enable="NO" > sendmail_msp_queue_enable="NO"

Also see "Swapping" below.

> > I was not able to find a correct definition of what "inactive" > > memory is. First, I would like to know what are these kind of pages : > > wired, active, inactive, cache and free. Peter Jeremy [Paragraph breaks inserted by me]: > Wired pages are pages that the kernel has wired to RAM so they cannot > be paged out. > Active pages are being mapped by virtual memory and in use by > running processes. > Inactive pages are not currently mapped but the kernel knows their > contents and can re-map them without needing to retrieve them from > disk - they may be dirty. > Cache pages are similar to active pages but aren't dirty and are > higher-priority candidates for being freed. > Free pages have no useful content and will be used to fulfil page-in > requests. > > Is that normal that inactive memory usage grows ? Peter Jeremy: > Yes. 'Free' memory is basically wasted and so the kernel tries to > limit it, subject to having sufficient free memory to meet > page-faults. Most of your RAM should be wired, active or inactive. > Inactive memory will start at 0 and grow as active pages are released. > > we've had some processes stuck in the *inp state as listed in 'top'. > > Those processes can't be killed and any resources they use up in > > terms of bound IP addresses or ports can't be freed. Does anyone know > > what this *inp state means or how to fix this problem? Robert Watson: > Processes in state '*inp' are waiting for an inpcb lock, suggesting a > deadlock or lock leak. Can you compile your kernel with invariants, > witness, ddb, etc, and do a bit of kernel debugging? You can find > basic instructions in the handbook; what I'm particularly interested > in is the output of "alltrace", "show alllocks", "show allpcpu". Oliver Fromme: > Note that it is normal that processes get swapped out if > they haven't been in the run queue for a very long time > and "free" memory has reached near zero (which is also > normal). That's a feature, because it improves efficiency > in most situations, because more RAM is available to > processes which really need it. > > For example, if you use X11 and don't log into syscons' > virtual terminals (/dev/vty*), you will notice that the > getty(8) processes will be swapped out after some time > when there is not many "free" memory left: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 382 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty > 383 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty > 384 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty > 385 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty > 386 root 3 0 996K 0K ttyin 0:00 0.00% 0.00% getty > > If you want to check whether there's a _real_ shortage of > RAM (or a memory leak somewhere), a good way is to watch > the "po" and "sr" columns in the output of "vmstat 5": > > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id > 1 0 0 39960 44944 62 0 0 0 61 3 0 0 157 6 36 2 1 97 > 0 0 0 39960 44944 2 0 0 0 0 0 0 0 1132 19 8 0 0 100 > 0 0 0 39960 44944 1 0 0 0 0 0 0 1 1132 19 8 0 0 100 > 0 0 0 34300 44944 1 0 0 0 0 0 0 0 1132 23 9 0 0 100 > > The "po" (page-out) column indicates paging activity, i.e. > data is moved to the swap. The "sr" (scan-rate) column > measures the speed at which inactive pages are scanned for > becomeing cache or "free" pages; this number is a good > measure of the "pressure" on the VM system. > > If both numbers are almost always near zero, you don't > have to worry at all. If the numbers are constantly > high, you either have a leak somewhere that you need to > discover, or you need to add more RAM to your machine.