This are the parameters that are set:<br><br> 59: volume nfs-server<br> 60: type nfs/server<br> 61: option nfs.dynamic-volumes on<br> 62: option nfs.nlm on<br> 63: option rpc-auth.addr.cloud.allow *<br> 64: option nfs3.cloud.volume-id 84fcec8c-d11a-43b6-9689-3f39700732b3<br>
65: option nfs.enable-ino32 off<br> 66: option nfs3.cloud.volume-access read-write<br> 67: option nfs.cloud.disable off<br> 68: subvolumes cloud<br> 69: end-volume<br><br>And some errors are:<br>[2012-07-18 17:57:00.391104] W [socket.c:195:__socket_rwv] 0-socket.nfs-server: readv failed (Connection reset by peer)<br>
[2012-07-18 17:57:29.805684] W [socket.c:195:__socket_rwv] 0-socket.nfs-server: readv failed (Connection reset by peer)<br>[2012-07-18 18:04:08.603822] W [nfs3.c:3525:nfs3svc_rmdir_cbk] 0-nfs: d037df6: /one/var/datastores/0/99/disk.0 => -1 (Directory not empty)<br>
[2012-07-18 18:04:08.625753] W [nfs3.c:3525:nfs3svc_rmdir_cbk] 0-nfs: d037dfe: /one/var/datastores/0/99 => -1 (Directory not empty)<br><br>The directory not empty is just an attempt to delete a directory with files inside but I guess that it should not increase the CPU load.<br>
<br>Above case is just one of the many times that the NFS daemon started using CPU but it's not the only scenario (deleting not empyt directory) that causes the degradation. Sometimes it has happened wihout any concrete error on the log files. I'll try to make more tests and offer more debug information.<br>
<br>Thanks for your answer so far,<br>Samuel.<br><br><div class="gmail_quote">On 18 July 2012 21:54, Anand Avati <span dir="ltr"><<a href="mailto:anand.avati@gmail.com" target="_blank">anand.avati@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there anything in the nfs logs?<div><br></div><div>Avati<br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jul 18, 2012 at 9:44 AM, samuel <span dir="ltr"><<a href="mailto:samu60@gmail.com" target="_blank">samu60@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hi all,<br><br>We're experiencing with a 4 nodes distributed-replicated environment (replica 2). We were using gluster native client to access the volumes, but we were asked to add NFS accessibility to the volume. We then started the NFS daemon on the bricks. Everything went ok but we started experiencing some performance degradation accessing the volume.<br>
We debugged the problem and found out that quite often the NFS glusterfs process (NOT the glusterfsd) eats up all the CPU and the server where the NFS is being exported starts offering really bad performance.<br><br>Is there any issue with 3.3 and NFS performance? Are there any NFS parameters to play with that can mitigate this degradation (standard R/W values drops to a quarter of standard values)?<br>
<br>Thanks in advance for any help,<br><br>Samuel.<br>
<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://gluster.org/cgi-bin/mailman/listinfo/gluster-users" target="_blank">http://gluster.org/cgi-bin/mailman/listinfo/gluster-users</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br>