FreeBSD 6.0 - amount of total visible memory is decreasing in
PeterJeremy at optushome.com.au
Tue Jan 10 16:00:24 PST 2006
Since no-one else has offered any input...
On Sun, 2006-Jan-08 03:04:44 +0300, Ilya E Veretenkin wrote:
>Problem: Total amount of visible memory is decreasing while system is
>(total amount = sum of all memory fields in 'top' utility output,
>in other words: Active+Inact+Wired+Cache+Buf+Free)
This information is also available in sysctl variables (note units):
Active: vm.stats.vm.v_active_count (pages)
Inact: vm.stats.vm.v_inactive_count (pages)
Wired: vm.stats.vm.v_wire_count (pages)
Cache: vm.stats.vm.v_cache_count (pages)
Buf: vfs.bufspace (bytes)
Free: vm.stats.vm.v_free_count (pages)
Unfortunately, the manipulation of these variables does not lend itself
to easy understanding. There's also a 7th category "unmanaged" which
is not directly reported. Active, inactive, cache and free pages are
all managed via page queues (vm_page_queues) whilst wired pages, buffers
and other other unmanaged pages don't exist on any queue.
Two possibilities are:
1) There's a leak where pages are becoming unmanaged over time.
Presumably there's a path where pages are being released without being
returned to the free page queue.
2) There's a bug where pages are being placed onto page queues without the
associated queue size variable being incremented.
Unfortunately,I can't suggest a fix offhand.
Note that since these counters are all managed independently and
there's no locking when you access them from userland, you could
expect to see some noise when adding them all up ("rounding errors"
as you've noted).
>OS: FreeBSD 6
>Server: 2xAmd64bit, 4GB memory, tyan motherboard
I presume you're running an amd64 kernel. Are you in a position to
check if the problem still exists with the i386 kernel or with a
non-SMP kernel? Are you in a position to build a kernel with
"INVARIANTS" enabled (which will impact kernel performance somewhat)?
If you're interested in kernel hacking, you could write a kernel
module that regularly scans vm_page_array and checks the number of
pages on each page queue with the number reported for that queue, as
well as reporting the number of unmanaged pages compared to the buffer
space and wired pages. This would at least provide a pointer to where
to look next.
More information about the freebsd-hackers