[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