[Gluster-users] Memory leak with a replica 3 arbiter 1 configuration
Ravishankar N
ravishankar at redhat.com
Tue Aug 23 07:38:39 UTC 2016
Hi Benjamin
On 08/23/2016 06:41 AM, Benjamin Edgar wrote:
> I've attached a statedump of the problem brick process. Let me know
> if there are any other logs you need.
Thanks for the report! I've sent a fix @
http://review.gluster.org/#/c/15289/ . It would be nice if you can
verify if the patch fixes the issue for you.
Thanks,
Ravi
>
> Thanks a lot,
> Ben
>
> On Mon, Aug 22, 2016 at 5:03 PM, Pranith Kumar Karampuri
> <pkarampu at redhat.com <mailto:pkarampu at redhat.com>> wrote:
>
> Could you collect statedump of the brick process by following:
> https://gluster.readthedocs.io/en/latest/Troubleshooting/statedump
> <https://gluster.readthedocs.io/en/latest/Troubleshooting/statedump>
>
> That should help us identify which datatype is causing leaks and
> fix it.
>
> Thanks!
>
> On Tue, Aug 23, 2016 at 2:22 AM, Benjamin Edgar
> <benedgar8 at gmail.com <mailto:benedgar8 at gmail.com>> wrote:
>
> Hi,
>
> I appear to have a memory leak with a replica 3 arbiter 1
> configuration of gluster. I have a data brick and an arbiter
> brick on one server, and another server with the last data
> brick. The more I write files to gluster in this
> configuration, the more memory the arbiter brick process takes up.
>
> I am able to reproduce this issue by first setting up a
> replica 3 arbiter 1 configuration and then using the following
> bash script to create 10,000 200kB files, delete those files,
> and run forever:
>
> while true ; do
> for i in {1..10000} ; do
> dd if=/dev/urandom bs=200K count=1 of=$TEST_FILES_DIR/file$i
> done
> rm -rf $TEST_FILES_DIR/*
> done
>
> $TEST_FILES_DIR is a location on my gluster mount.
>
> After about 3 days of this script running on one of my
> clusters, this is what the output of "top" looks like:
> PID USER PR NI VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 16039 root 20 0 1397220 77720 3948 S
> 20.6 1.0 860:01.53 glusterfsd
> 13174 root 20 0 1395824 112728 3692 S 19.6
> 1.5 806:07.17 glusterfs
> 19961 root 20 0 2967204 *2.145g* 3896 S
> 17.3 29.0 752:10.70 glusterfsd
>
> As you can see one of the brick processes is using over 2
> gigabytes of memory.
>
> One work-around for this is to kill the arbiter brick process
> and restart the gluster daemon. This restarts arbiter brick
> process and its memory usage goes back down to a reasonable
> level. However I would rather not kill the arbiter brick every
> week for production environments.
>
> Has anyone seen this issue before and is there a known
> work-around/fix?
>
> Thanks,
> Ben
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
> http://www.gluster.org/mailman/listinfo/gluster-users
> <http://www.gluster.org/mailman/listinfo/gluster-users>
>
>
>
>
> --
> Pranith
>
>
>
>
> --
> Benjamin Edgar
> Computer Science
> University of Virginia 2015
> (571) 338-0878
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160823/f6b6aa12/attachment.html>
More information about the Gluster-users
mailing list