On Friday 26 March 2010 wrote Amon Ott: > On Friday 26 March 2010 wrote Krzysztof Strasburger: > > On Fri, Mar 26, 2010 at 12:08:48PM +0100, Amon Ott wrote: > > > I can confirm this problem on our test system. glusterfs goes up to the > > > memory limit set for performance/io-cache (1.2 GB here), logs out of > > > memory errors and further access fails with "Stale NFS file handle". > > > The above command did not help, only remounting did. > > > > > > So I assume some memory leak in the io-cache filter. > > > > No, this should happen without any filters. What happens, if you disable > > io-cache? > > Disabled both io-cache and read-ahead. Now it only grew to 739 MB. Again, > drop_caches did not reduce that size, although it reduced the fuse_inode > slabs significantly. No out of memory now. Small update: The memory usage seems to be only related to the number of filesystem objects that get read, not to the sizes. I wonder why it does not shrink after a while. This really smells like a memory leak. If ca. 90000 used inodes already blow glusterfs to 739 MB, what will happen if I backup a real storage with millions of used inodes? Amon Ott -- Dr. Amon Ott - m-privacy GmbH Am K?llnischen Park 1, 10179 Berlin Tel: +49 30 24342334 Fax: +49 30 24342336 Web: http://www.m-privacy.de Handelsregister: Amtsgericht Charlottenburg HRB 84946 Gesch?ftsf?hrer: Dipl.-Kfm. Holger Maczkowsky, Roman Maczkowsky GnuPG-Key-ID: EA898571
