[Gluster-devel] memory leaks
Brent A Nelson
brent at phys.ufl.edu
Thu Mar 8 19:44:09 UTC 2007
On Thu, 8 Mar 2007, Amar S. Tumballi wrote:
> On Thu, Mar 08, 2007 at 12:52:35PM -0500, Brent A Nelson wrote:
>> volume server
>> type protocol/server
>> subvolumes share0 share1 share2 share3 share4 share5 share6 share7
>> share8 share9 share10 share11 share12 share13 share14 share15
>> ...
>> end-volume
>
> you can't have more than one subvolumes in protocol/server xlator. The clustering
> ability is there only within cluster/{unify,stripe,afr} xlators.
>
Doesn't that just export multiple volumes from one server so the client
can access them all? I use cluster/unify and cluster/afr on the client to
cluster together the server's volumes, and it works (except for what
appear to be memory leaks). Also, the examples in the documentation show
multiple subvolumes just as I am doing (e.g., the section "AFR Example
in Clustered Mode"), so I assumed that was the proper way to do it.
Otherwise, you'd do a protocol/server (or maybe a separate glusterfsd?)
for every export. Unless, of course, it makes sense to put a cluster
translator on the server, rather than the client...
>>
>> volume statprefetch
>> type performance/stat-prefetch
>> option cache-seconds 2
>> subvolumes server
>> end-volume
>>
>> volume writebehind
>> type performance/write-behind
>> option aggregate-size 131072 # in bytes
>> subvolumes statprefetch
>> end-volume
>>
>> volume readahead
>> type performance/read-ahead
>> option page-size 65536 ### in bytes
>> option page-count 16 ### memory cache size is page-count x page-size per
>> file#
>> subvolumes writebehind
>> end-volume
>>
>> volume iot
>> type performance/io-threads
>> option thread-count 8
>> subvolumes readahead
>> end-volume
>>
> no.. in server side, server should be the top most volume. and later, all other
> volumes should come.
Just to be clear, can you give me a proper basic example of a server
exporting two disks, with all performance translators correctly
configured? The documentation is lacking in this area...
> And about io-threads if you have used it in the client side,
> there is some work pending to make it run seemlessly (as few part of our code is
> not yet threadsafe). So, i advice you to run io-threads only on server.
>
Okay, will do.
>> Thanks,
>>
>
> I am working on read-ahead/memory leak issues now.. once found, will get back to you..
>
> Amar
>
Okay, great.
Thanks,
Brent
More information about the Gluster-devel
mailing list