login
Login
/
Register
Search
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2007
»
August
»
26
Re: Slow, persistent memory leak in 2.6.20
view
thread
!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From:
Fred Tyler <fredty8@...>
To: <linux-kernel@...>
Subject:
Re: Slow, persistent memory leak in 2.6.20
Date: Sunday, August 26, 2007 - 12:14 pm
On 8/26/07, Fred Tyler <fredty8@gmail.com> wrote:
quoted text
> On 8/26/07, Jan Engelhardt <jengelh@computergmbh.de> wrote: > > > > On Aug 26 2007 11:51, Fred Tyler wrote: > > >On 8/26/07, Fred Tyler <fredty8@gmail.com> wrote: > > >> I think I've come across a memory leak in 2.6.20. I've upgraded to the > > >> latest 2.6.20.17, but it didn't seem to help. > > > > > >Sorry to keep replying to my own post, but further investigation > > >suggests that the memory losses may be occurring at times of heavy > > >filesystem access. The machines in question run rsyncs of hundreds of > > >thousands of files every few hours, and I'm starting to think that the > > >memory loss occurs during these times. I don't know how I'd go about > > >proving this though... > > > > Please rule out filesystem caches by issuing > > sync; > > echo 3 >/proc/sys/vm/drop_caches; > > > 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.) > > 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, > logging, etc) first, am I protected against data loss? >
-
unsubscribe notice
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/
Previous message: [thread] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
Re: Slow, persistent memory leak in 2.6.20
, Fred Tyler
, (Sun Aug 26, 12:14 pm)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Michal Piotrowski
Re: [BUG] fs/xfs/xfs_bmap_btree.c:2312: error: 'b' undeclared (first use in this f...
debian developer
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Greg KH
[GIT PATCH] driver core patches against 2.6.24
Paul Jackson
[PATCH 0/5 v2] x86 boot: various E820 & EFI related fixes - what changed in v2
git
:
openbsd-misc
:
linux-netdev
:
Paweł Staszewski
Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
David Miller
Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock().
Gerrit Renker
[PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side)
Jarek Poplawski
Re: Data corruption issue with splice() on 2.6.27.10
Colocation donated by:
Who's online
There are currently
1 user
and
810 guests
online.
Online users
zeekec
Syndicate