lkml.org 
[lkml]   [2007]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Slow, persistent memory leak in 2.6.20

On Aug 26 2007 12:16, Fred Tyler wrote:
>> Please rule out filesystem caches by issuing
>> sync;
>> echo 3 >/proc/sys/vm/drop_caches;
>
>(Sorry if this goes to the list twice... Mailer problems.)
alright..

>Ok, I did this on a non-production machine that has only been up for a
>few hours, and here's what happened:
>
>======== Before =========
>
>$ free -m
> total used free shared buffers cached
>Mem: 878 824 54 0 111 422
>-/+ buffers/cache: 290 587
>Swap: 63 0 63
>
>
>======== After ========
>
>root@b0$ free -m
> total used free shared buffers cached
>Mem: 878 47 830 0 6 4
>-/+ buffers/cache: 36 841
>Swap: 63 0 63
>
>======================
>
>So, I guess it worked? (I don't know what was supposed to happen, but
>memory usage dropped significantly when I did this.)

So I guess you are not seeing any memory leak at all, but just the regular
caching?

>However, I'm not sure this staging machine has been up long enough or
>doing enough to exhibit the problem. I can try this on my production
>servers (the ones I provided graphs for) late tonight, but how safe is
>running this command? Does it permanently disable file caching? Do I
>need to reset it afterwards? If I stop all services (databases,

drop_cache is a trigger, not a setting. Hence your RAM will be used again
after you have used drop_caches.

>logging, etc) first, am I protected against data loss?


Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-26 18:33    [W:2.408 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site