This are the parameters that are set: 59: volume nfs-server 60: type nfs/server 61: option nfs.dynamic-volumes on 62: option nfs.nlm on 63: option rpc-auth.addr.cloud.allow * 64: option nfs3.cloud.volume-id 84fcec8c-d11a-43b6-9689-3f39700732b3 65: option nfs.enable-ino32 off 66: option nfs3.cloud.volume-access read-write 67: option nfs.cloud.disable off 68: subvolumes cloud 69: end-volume And some errors are: [2012-07-18 17:57:00.391104] W [socket.c:195:__socket_rwv] 0-socket.nfs-server: readv failed (Connection reset by peer) [2012-07-18 17:57:29.805684] W [socket.c:195:__socket_rwv] 0-socket.nfs-server: readv failed (Connection reset by peer) [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) [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) 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. 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. Thanks for your answer so far, Samuel. On 18 July 2012 21:54, Anand Avati <anand.avati at gmail.com> wrote: > Is there anything in the nfs logs? > > Avati > > On Wed, Jul 18, 2012 at 9:44 AM, samuel <samu60 at gmail.com> wrote: > >> Hi all, >> >> 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. >> 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. >> >> 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)? >> >> Thanks in advance for any help, >> >> Samuel. >> >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users at gluster.org >> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120719/db2a1667/attachment.htm>