Claus Guttesen <kome...@gmail.com> wrote:
> > > I'm trying to read how much ram an app is using reading
> >
> > Could you phrase that question more precisely?
> > It might be helpful to know *WHY* you are interested
> > in the app's RAM usage, in order to be able to give the
> > most appropriate advice.
>
> I'm testing the redis key-value-store with the (upcoming 2.2)
> maxmemory directive and redis - at least on FreeBSD - seems to report
> less ram used than what is shown in top (SIZE column). ru.ru_maxrss is
> more accurate at least when redis grows.
The "SIZE" column of top(1) is the same as the "VSZ" column
of ps(1): It displays the virtual process size. Basically
this is the sum of all VM mappings that are assigned to the
process. It has _nothing_ to do with the RAM usage.
Somewhat more useful for your purpose is the resident set
size ("RES" in top, "RSS" in ps). This is the amount of
memory actually in use. But this also includes files that
were mmap()ed, including libraries shared between many
processes. I'm not sure this is what you want. Another
problem is that the resident set size does NOT include
pages in swap. So, if your process is swapped completely,
the RSS is zero, as you can see here:
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
14388 olli 1 5 0 3864K 0K ttyin 0:00 0.00% <zsh>
> Redis is useful with an expire in the key (setex) in my case where I
> want to store as much as
> possible and retain used key and have redis delete unused keys (LRU)
>
> In freeMemoryIfNeeded() redis deletes keys until allocated memory <
> maxmemory. I used ru.ru_maxrss for testing allocated memory but I
> ended up deleting all keys since ru.ru_maxrss is not counting down
> "fast enough", probably for quite reasonable reasons. But not what I
> wanted. :-)
If you free an object with the free() function, the pages
are not necessarily unmapped immediately. This depends on
the malloc implementation and configuration. Also, even
if it is unmapped, the rusage statistics are not updated
immediately (this depends on the statclock, see ``sysctl
kern.clockrate'').
I think that applications should better track their memory
usage themselves, so it is portable and independent of
implementation details of the VM system and malloc library.
That's what most applications do, for example squid.
> > > struct thread *td;
> > > td = curthread;
> > > p = td->td_proc;
> > > vm = p->p_vmspace;
> > > rss = pgtok(vmspace_resident_count(vm));
> >
> > That's a piece of kernel source code. It won't work in
> > user space.
>
> Saw #ifdef _KERNEL in older versions of sys/pcpu.h that explicitly
> told it was kernel-related code
> (http://fxr.watson.org/fxr/source/sys/pcpu.h?v=FREEBSD70) but not on
> 8-stable.
Your code snipped was from sys/kern/kern_clock.c which is
kernel source. Curthread is a kernel variable (it's part
of the per-CPU struct pcpu); it's not directly accessible
from userland.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"Unix gives you just enough rope to hang yourself --
and then a couple of more feet, just to be sure."
-- Eric Allman
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
