Notes - FreeBSD-stable Mailing List tips

.plan
[Last 5] [Last 10] [Index] [RSS Feed] [Full .plan]
Contact Me
Todo Chart (aka: How busy is Dylan?)

Research

ZFS Timeline Forensics
Honours Thesis
BSDCan 2014 Presentation
ZFS/ZDB Plaso Parsers

Notes

Notes
Security
Vim
C and C++
FreeBSD
more notes...

Software

Codepile
Assorted little scripts and apps.
rastodo.py
Commandline/Android ToDo list stored in a text file.
Android Apps
more software...

Game Mods

LethalMod
A Max Payne 2 mod - more realistic and deadly.
more mods...

RMITCS

C Helpdesk Resources
Customising Your CS Account
more RMITCS stuff...

Roleplaying Games

Shadowrun Notes(4th ed)
Heavy Gear Notes(2nd ed)
more RPG stuff...

Portfolio

Portfolio
Examples of my University work.

Miscellaneous

links
Old Image Gallery
Taglines
crazy
Trombone slide position chart [PDF]
[Back to home page]
[Back to Index]

[Raw XML]
A collection of useful/interesting stuff from the FBSD-stable mailing list.

Contents:

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


Full filesystems with du showing less usage than df

Tom Evans:
> [...] any unlinked files that have file handles open by running
> processes will not be accounted for in du, but will be counted in
> df. You could try restarting services that write to [the affected
> filesystem]
   

Shutting off the internal Sendmail daemon

> > > > 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"
   

Memory Management

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.
   

Process states

> > 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".
   

Swapping

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.
   
Generated Sat, 17 Jan 2015 11:14:49 +1100
Copyright © 2002-2014 Dylan Leigh.
[HTML 4.01 Transitional]