Re: Client memory footprint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 24 Aug 2011 11:50:45 +0200, manu@xxxxxxxxxx (Emmanuel Dreyfus) wrote:
Pavan T C <tcp@xxxxxxxxxxx> 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



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux