--- In "dawydiuk" <> wrote:
>
> Hello,
>
> > Here's a summary of the free command output at 0 hours and 46
> > hours into the test:
> >
> > used free buf cached
> > 0 hrs 15568 13304 788 8788
> > 46hrs 25004 3568 2500 10112
> >
> > You'll notice that buffer/cache allocations increase, but not
> > nearly enough to account for the decrease in free memory.
> >
> "The short answer is that you should never worry about the amount of
> free memory on Linux. The kernel attempts to keep this slightly
> above zero by keeping the cache as large as possible. This is a
> feature not a bug."
>
> Why doesn't free memory go down
> http://sourcefrog.net/weblog/software/linux-kernel/free-mem.html
We make network appliances that run the linux kernel. Take a look at
this output from one of those machines, which is a live
router/firewall in our company's network (and note its uptime):
/root]# uptime
19:38:11 up 83 days, 2:51, load average: 0.07, 0.01, 0.00
/root]# cat /proc/meminfo [output trimmed]
MemTotal: 61992 kB
MemFree: 30204 kB
MemShared: 0 kB
Buffers: 3920 kB
Cached: 13840 kB
In light of the quote you took from Martin Pool's blog, why is there
so many pages on the free list (MemFree)? For two reasons: (1) kernel
and user threads haven't made enough allocations to consume more, and
(2) current processing requirements require no more cache/buffer
blocks (Buffers + Cached) than are being used.
The quote is taken out of context. It assumes a busy machine with
swap space, where the VM subsystem balances cached pages, active
in-core pages and active out-of-core pages in an effort to keep as
many of the the most relevant pages in RAM as possible.
Take a look at the memory output for the TS-7200 at the very top of
this e-mail. You'll notice that in the time the free list was reduced
by about 10MB, only 4MB of which is accounted for by increased buffer
and cache page usage. This leaves 6MB allocated elsewhere, which is
a behavior I haven't seen before. Also note that allocations would
most likely have continued had I not stopped the test. This behavior,
continuous increases in allocations that grow statistically large over
time, is symptomatic of a memory leak. It could be something else,
but it doesn't seem likely.
Because the running processes don't seem to be accumulating memory
blocks, I presume the allocations are happening in the kernel. This
leads me to suspect the modifications that have been made to support
the EP9302, or a kernel module for this platform.
I'll be looking into this over the next few weeks and will let you
know what I find. If there's anyone out there that has TS-7200's with
uptimes measured in weeks or months, It'd be helpful to learn more
from you to better target my research.
All the best,
Steve
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|