[Gluster-devel] Client memory footprint

Gordan Bobic gordan at bobich.net
Wed Aug 24 09:51:05 UTC 2011


 On Wed, 24 Aug 2011 11:50:45 +0200, manu at netbsd.org (Emmanuel Dreyfus) 
 wrote:
> Pavan T C <tcp at gluster.com> wrote:
>
>> The glusterfs server process uses iomem pools. Initially, it starts 
>> with
>> one pool. Under memory pressure, it allocates more, but does not 
>> give
>> back the pool when the pressure decreases. It can be debated whether
>> this is a bug, but one can come up with heuristics to free the pool.
>
> I was concerned about machines with little memory. It would be nice 
> to
> have the ability to tell glusterfsd to avoid eating too much memory 
> for
> performances: if you do not have that memory, you clearly prefer to 
> have
> poor performance than to have a crash.

 Indeed. One of the (to me at least) obvious use-cases for a distributed 
 file system (GlusterFS with DHT) is micro-servers, which might have very 
 small memory (512MB on a typical ARM server, 1GB if you're lucky), and a 
 small amount of storage space (e.g. <= 32GB SD card) that would be handy 
 to pool together, but for this to work a very tight memory footprint is 
 needed. I'm not talking about just freeing memory as soon as it isn't 
 used, I'm talking about revising what actually needs to be kept in 
 memory at all.

 Emmanuel, in the absence of a low-memory solution, you may want to look 
 into zram (ramzswap before 2.6.32-ish) for swapping as a workaround.

 Gordan




More information about the Gluster-devel mailing list