On Tue, 10 Feb 2009 20:25:59 +0530, Anand Avati <avati@xxxxxxxxxxxxx> wrote: >> Is there a parameter to limit this cache? And how does this compare to >> the normal page cache on the underlying FS? > > It is not possible to limit this cache as it is decided by the dcache > pruning algorithm in the linux kernel vm. You can however force a > forget of all the build cache by doing an 'echo 3 > > /proc/sys/vm/drop_caches' Interesting, I thought the drop_caches didn't include the caches that reflect in the process size itself. So the 300MB of the resident size of glusterfs gets included? I'll have to try this. So, running # updatedb and/or # ls -laR / should make it go up to maximum size and not grow much further? >> The thing that seems particularly odd is that although both the root and >> the /home glusterfs daemons seem to grow over time, the growth of the >> root >> one seems to be vastly greater. The rootfs only contains about 1.2GB of >> data, but I have seen it's daemon process get to nearly 300MB. The /home >> FS >> contains several hundred gigabytes of data, but I haven't seen it grow to >> more than about 60MB. Since the /home FS gets a lot more r/w access, it >> seems to be something specific to the rootfs usage that causes the >> process >> bloat. Perhaps something like shared libraries (all of which are on the >> rootfs)? Maybe some kind of a leak in mmap() related code? > > Memory usage of GlusterFS is largely decided by the dcache, which is a > reflection of how many files/directories are present in your volume > (and not related to the data size). OK, thanks for clarifying. Gordan
