Abnormally large number of Open files with Glusterfs

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

 



Hi,

As a side note, 3s transport-timeout seems to be too small. Is there any
particular reason for using such a small timeout?

regards

On Wed, Dec 17, 2008 at 4:34 PM, Chandranshu . <chandranshu at gmail.com>wrote:

> I am including the server and client configurations inline in the mail. The
> log files are quite huge and we are looking into them ourselves. If you are
> looking for something in particular, I can attach the specific logs.
>
> Regards
> Chandranshu
>
> ########################
> ##       glusterfs-server.vol                 ##
> ########################
> volume brick
>   type storage/posix
>   option directory /var/glusterfs
> end-volume
>
> volume server
>   type protocol/server
>   subvolumes brick
>   option transport-type tcp/server     # For TCP/IP transport
>   option auth.ip.brick.allow *
> end-volume
> ########## Server Vol ends ####
>
> ########################
> ##      glusterfs-client.vol                   ##
> ########################
> volume client1
>   type protocol/client
>   option transport-type tcp/client
>   option remote-host 192.168.4.53
>   option remote-subvolume brick
>  option transport-timeout 3
> end-volume
>
> volume client2
>   type protocol/client
>   option transport-type tcp/client
>   option remote-host 192.168.4.55
>   option remote-subvolume brick
>  option transport-timeout 3
> end-volume
>
> volume afr
>  type cluster/afr
>  subvolumes client1 client2
> # option replicate *:2
> end-volume
> ####### Glusterfs Client ends #####
>
>
> On Wed, Dec 17, 2008 at 5:49 PM, Basavanagowda Kanur <
> basavanagowda at gmail.com> wrote:
>
>> Chandranshu,
>>   Can you share the volume file for the server which is keeping the files
>> open?
>>   It will also be helpful to debug if you can share the log of the
>> corresponding server with us.
>>
>> --
>> gowda
>>
>>
>> On Wed, Dec 17, 2008 at 4:39 PM, Chandranshu . <chandranshu at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I am using glusterfs to provide storage for a web server. The current
>>> server in question had been running for around 20 days now without requiring
>>> any intervention. However, the performance was degrading over the last week
>>> and it became completely unresponsive today. The panic button was pressed
>>> when we realized that not only glusterfs but all other processes on that
>>> machine were not responsive and trying to restart any service resulted in
>>> the error - "Too many files open."
>>> Doing an lsof showed over 115000 files open of which glusterfs was
>>> responsible for around 112000.  Checking the list of files opened by
>>> glusterfs, i was surprisd to see that glusterfs had opened same files again
>>> and again and again. More surprisingly, most of these file descriptors were
>>> for directories rather than files. Is it a fall off from some book keeping?
>>> Or are a new file descriptor is always opened by glusterfs irrespective of
>>> whether a previous one already exists or not?
>>>
>>> Also, can someone suggest a good time interval after which to restart
>>> glusterfsd or if there is already a mechanism in place to ask glusterfsd to
>>> release the open file descriptoes?
>>>
>>> Thanks and regards
>>> Chandranshu
>>>
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>>>
>>>
>>
>>
>> --
>> hard work often pays off after time, but laziness always pays off now
>>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>
>


-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zresearch.com/pipermail/gluster-users/attachments/20081217/16e069ce/attachment.htm 


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

  Powered by Linux