Hi,<br><br>We didn't have any particular reason to choose this timeout. We had set it to larger values initially and then decreased it in steps. Timeouts started to happend at a limit of 1.5s. So, we doubled it to 3s. Ever since then, we have not encountered timeouts though the system did become slow at times. Are there heuristics available to estimate a good timeout settings?<br>
<br>Thanks and regards<br>Chandranshu<br><br><div class="gmail_quote">On Wed, Dec 17, 2008 at 11:48 PM, Raghavendra G <span dir="ltr"><<a href="mailto:raghavendra.hg@gmail.com">raghavendra.hg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br><br>As a side note, 3s transport-timeout seems to be too small. Is there any particular reason for using such a small timeout?<br>
<br>regards<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Wed, Dec 17, 2008 at 4:34 PM, Chandranshu . <span dir="ltr"><<a href="mailto:chandranshu@gmail.com" target="_blank">chandranshu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>Regards<br>Chandranshu<br><br>########################<br>## glusterfs-server.vol ##<br>########################<br>volume brick<br> type storage/posix<br> option directory /var/glusterfs<br>end-volume<br>
<br>volume server<br> type protocol/server<br> subvolumes brick<br> option transport-type tcp/server # For TCP/IP transport<br> option auth.ip.brick.allow *<br>end-volume<br>########## Server Vol ends ####<br><br>
########################<br>## glusterfs-client.vol ##<br>########################<br>volume client1<br> type protocol/client<br> option transport-type tcp/client<br> option remote-host 192.168.4.53<br>
option remote-subvolume brick<br> option transport-timeout 3<br>end-volume<br><br>volume client2<br> type protocol/client<br> option transport-type tcp/client<br> option remote-host 192.168.4.55<br> option remote-subvolume brick<br>
option transport-timeout 3<br>end-volume<br><br>volume afr<br> type cluster/afr<br> subvolumes client1 client2<br># option replicate *:2<br>end-volume<br>####### Glusterfs Client ends #####<div><div></div><div>
<br><br><div class="gmail_quote">
On Wed, Dec 17, 2008 at 5:49 PM, Basavanagowda Kanur <span dir="ltr"><<a href="mailto:basavanagowda@gmail.com" target="_blank">basavanagowda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chandranshu,<br> Can you share the volume file for the server which is keeping the files open?<br> It will also be helpful to debug if you can share the log of the corresponding server with us.<br><br>--<br>gowda<br><br>
<br><div class="gmail_quote"><div><div></div><div>On Wed, Dec 17, 2008 at 4:39 PM, Chandranshu . <span dir="ltr"><<a href="mailto:chandranshu@gmail.com" target="_blank">chandranshu@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div>
Hi,<br><br>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."<br>
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?<br>
<br>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?<br><br>Thanks and regards<br><font color="#888888">Chandranshu<br>
</font><br></div></div>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users</a><br>
<br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br>hard work often pays off after time, but laziness always pays off now<br>
</font></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br></div></div><font color="#888888">Raghavendra G<br><br>
</font></blockquote></div><br>