We have met same performance issues when open a file. Sometime, it cost more than 10 seconds that a file open. We add some debug info to locate this problem and test again and again, find it's will cost a few seconds when execute 'xdr_callmsg' function in 'rpc_request_to_xdr'. A typical example of log is as below. From [2013-06-06 13:34:59.471004] to [2013-06-06 13:35:04.890363] , 'xdr_callmsg' function cost more than 5 seconds. [2013-06-06 13:34:59.470991] I [rpc-clnt.c:1175:rpc_clnt_record_build_record] 0-gfs1-client-51: (thread_id is 140257410492160 )add for open_slow rpc_fill_request_end [2013-06-06 13:34:59.471004] I [xdr-rpcclnt.c:87:rpc_request_to_xdr] 0-rpc: (thread_id is 140257410492160 len = 131072 )add for open_slow xdrmem_create_end [2013-06-06 13:34:59.570044] I [client.c:124:client_submit_request] 0-gfs1-client-86: (thread_id is 140257819739904 )add for open_slow rpc_clnt_submit [2013-06-06 13:34:59.570091] I [rpc-clnt.c:1363:rpc_clnt_submit] 0-gfs1-client-86: (thread_id is 140257819739904 )add for open_slow callid end ...... [2013-06-06 13:34:59.579865] I [client3_1-fops.c:2235:client3_1_lookup_cbk] 0-gfs1-client-5: (thread_id is 140257819739904)add for open_slow lookup_cbk path=/xmail_dedup/gfs1_000/1FA/1B1 [2013-06-06 13:34:59.579917] I [client3_1-fops.c:2235:client3_1_lookup_cbk] 0-gfs1-client-6: (thread_id is 140257819739904)add for open_slow lookup_cbk path=/xmail_dedup/gfs1_000/1FA/1B1 [2013-06-06 13:35:04.890363] I [xdr-rpcclnt.c:92:rpc_request_to_xdr] 0-rpc: (thread_id is 140257410492160 )add for open_slow xdr_callmsg_end [2013-06-06 13:35:04.890366] I [client.c:110:client_submit_request] 0-gfs1-client-44: (thread_id is 140257785079552 )add for open_slow create the xdr payload Native client and use 5 glusterfs in one server. When performance issues appear, the cpu usage is as below: top - 13:45:37 up 57 days, 14:04, 4 users, load average: 6.98, 5.38, 4.67 Tasks: 712 total, 8 running, 704 sleeping, 0 stopped, 0 zombie Cpu(s): 3.2%us, 63.5%sy, 0.0%ni, 31.5%id, 1.4%wa, 0.0%hi, 0.4%si, 0.0%st Mem: 65956748k total, 55218008k used, 10738740k free, 3362972k buffers Swap: 8388600k total, 41448k used, 8347152k free, 37370840k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13905 root 20 0 554m 363m 2172 R 244.8 0.6 9:51.01 glusterfs 13650 root 20 0 766m 610m 2056 R 184.8 0.9 18:24.37 glusterfs 13898 root 20 0 545m 356m 2176 R 179.2 0.6 12:04.87 glusterfs 13919 root 20 0 547m 360m 2172 R 111.6 0.6 9:16.89 glusterfs 22460 root 20 0 486m 296m 2200 S 100.4 0.5 194:59.10 glusterfs 13878 root 20 0 545m 361m 2176 R 99.7 0.6 8:35.88 glusterfs -----Original Message----- On Thu, 06 Jun 2013 10:39:21 -0300 Pablo <paa.listas@xxxxxxxxx> wrote: > I have never try this (In fact I'm just learning a bit more how to > administer a Gluster server.), buy you may find it useful. > > http://download.gluster.org/pub/gluster/glusterfs/doc/HA%20and%20Load% > 20Balancing%20for%20NFS%20and%20SMB.html > > Pablo. The thing with this way of failover is though, that you will likely corrupt a currently written file. If your NFS-server (gluster) node dies while you write your file will be corrupt. If you use native glusterfs mounts it will not (should not). This is why I consider the NFS server feature nothing more than a bad hack. It does not deliver the safety that glusterfs promises, even if you solve the failover problem somehow. -- Regards, Stephan _______________________________________________ Gluster-users mailing list http://supercolony.gluster.org/mailman/listinfo/gluster-users |
