On 2014-08-01 02:02, Harshavardhana wrote:> On Thu, Jul 31, 2014 at 11:31 AM, 
Anders Blomdell
> <anders.blomd...@control.lth.se> wrote:
>> During rsync of 350000 files, memory consumption of glusterfs
>> rose to 12 GB (after approx 14 hours), I take it that this is a
>> bug I should try to track down?
>>
> 
> Does it ever come down? what happens if you repeatedly the same files
> again? does it OOM?
Well, it OOM'd my firefox first (that's how good I monitor my experiments :-()
No, memory usage does not come down by itself, ACAICT


On 2014-08-01 02:12, Raghavendra Gowdappa wrote:> Anders,
> 
> Mostly its a case of memory leak. It would be helpful if you can file a bug 
> on this. Following information would be useful to fix the issue:
> 
> 1. valgrind reports (if possible).
>  a. To start brick and nfs processes with valgrind you can use following 
> cmdline when starting glusterd.
>     # glusterd --xlator-option *.run-with-valgrind=yes
> 
>     In this case all the valgrind logs can be found in standard glusterfs log 
> directory.
> 
>  b. For client you can start glusterfs just like any other process in 
> valgrind. Since glusterfs is daemonized, while running with valgrind we need 
> to prevent it by running it in foreground. We can use -N option to do that
>     # valgrind --leak-check=full --log-file=<path-to-valgrind-log> glusterfs 
> --volfile-id=xyz --volfile-server=abc -N /mnt/glfs
> 
> 2. Once you observe a considerable leak in memory, please get a statedump of 
> glusterfs
> 
>   # gluster volume statedump <volname>
> 
> and attach the reports in the bug.
Since it looks like Pranith has a clue, I'll leave it for a few weeks (other
pressing duties).

On 2014-08-01 03:24, Pranith Kumar Karampuri wrote:
> Yes, even I saw the following leaks, when I tested it a week back. These were 
> the leaks:
> You should probably take a statedump and see what datatypes are leaking.
> 
> root@localhost - /usr/local/var/run/gluster
> 14:10:26 ? awk -f /home/pk1/mem-leaks.awk glusterdump.22412.dump.1406174043
> [mount/fuse.fuse - usage-type gf_common_mt_char memusage]
> size=341240
> num_allocs=23602
> max_size=347987
> max_num_allocs=23604
> total_allocs=653194
> ... 
I'll revisit this in a few weeks,

Harshavardhana, Raghavendra, Pranith (and all others),

Gluster is one of the most responsive Open Source project I
have participated in this far, I'm very happy with all support,
help and encouragement I have got this far. Even though my initial
tests weren't fully satisfactory, you are the main reason for
my perseverance :-)

/Anders



-- 
Anders Blomdell                  Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University                  Phone:    +46 46 222 4625
P.O. Box 118                     Fax:      +46 46 138118
SE-221 00 Lund, Sweden

_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

Reply via email to