[Gluster-users] Problem with Glusterfs - taking over CPU time on clients

[Milos Kurtes]

It is very possible but how to solve?

When I start command gluster volume heal rep-tmp info I've got Number of
entries: 111 and all on a first server (main one).

When I start command gluster volume heal rep-tmp I've got a message that
command is accepted and I can see status but is nothing there. Even in logs.


On Fri, Jul 1, 2016 at 9:03 PM, Ted Miller <tmiller at sonsetsolutions.org>
wrote:

> On 7/1/2016 5:22 AM, Milos Kurtes wrote:
>
> Hi,
>>
>> I have 7 clients on AWS in ELB and every of them is connected to
>> glusterfs servers group of two.
>>
>> On clients, version of glusterfs is glusterfs 3.7.1 built on Nov 22 2015
>> 17:39:20 and
>> on server side both of servers have same glusterfs 3.6.2 built on Jan 22
>> 2015 12:58:10
>>
>> The major and urgent problem is the situation after disconnecting and
>> connecting one of the servers, on one of the clients (and that is changing
>> which one after few minutes) are overtaken with glusterfs process (all
>> apache processes are on sleep in the same moment) which is responsible for
>> rw session files. This is a very frequent job.
>>
>> Without disconnection, everything working except filling log files with a
>> big amount of messages (probably incompatibility versions of glusterfs on
>> servers and clients side why I tried yesterday to get the update for server
>> side).
>>
>> Do anybody have a solution for this overtaking situation?
>>
>> Milos Kurtes, System Administrator, Alison Co.
>>
> I'm no expert, but it sounds like the heal process hogging resources
> healing (or checking for differences) the replicated volume back into the
> cluster.
> Ted Miller
> Elkhart, IN, USA
>
> _______________________________________________
> 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/20160703/7362e267/attachment.html>