Re: glusterfs client problem

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

 



Does this get better if you use the --bwlimit flag on rsync?


On Apr 2, 2007, at 3:46 PM, Shawn Northart wrote:

I'm noticing a problem with our test setup with regard to (reasonably)
heavy read/write usage.
the probelem we're having is that during an rsync of content, the sync
bails due to the mount being lost with the following errors:

<snip>
rsync: stat "/vol/vol0/sites/TESTSITE.com/htdocs/trailers" failed:
Transport endpoint is not connected (107)
rsync: recv_generator: mkdir
"/vol/vol0/sites/TESTSITE.com/htdocs/trialmember" failed: Transport
endpoint is not connected (107)
rsync: stat "/vol/vol0/sites/TESTSITE.com/htdocs/trialmember" failed:
Transport endpoint is not connected (107)
rsync: recv_generator: mkdir
"/vol/vol0/sites/TESTSITE.com/htdocs/trialmember/bardoux" failed:
Transport endpoint is not connected (107)
rsync: stat "/vol/vol0/sites/TESTSITE.com/htdocs/trialmember/bardoux"
failed: Transport endpoint is not connected (107)
rsync: recv_generator: mkdir
"/vol/vol0/sites/TESTSITE.com/htdocs/trialmember/images" failed:
Transport endpoint is not connected (107)
rsync: stat "/vol/vol0/sites/TESTSITE.com/htdocs/trialmember/images"
failed: Transport endpoint is not connected (107)
rsync: recv_generator: mkdir
"/vol/vol0/sites/TESTSITE.com/htdocs/upgrade_trailers" failed: Transport
endpoint is not connected (107)
rsync: stat "/vol/vol0/sites/TESTSITE.com/htdocs/upgrade_trailers"
failed: Transport endpoint is not connected (107)
</snip>

normal logging shows nothing either client or server-side, but running
logging in DEBUG mode shows the following at the end of the client log
right as it breaks:

<snip>
[Apr 02 13:25:11] [DEBUG/common-utils.c:213/gf_print_trace()]
debug-backtrace:Got signal (11), printing backtrace
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/usr/local/glusterfs-mainline/lib/libglusterfs.so.0 (gf_print_trace+0x1f) [0x2a9556030f]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/lib64/tls/libc.so.6 [0x35b992e2b0]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/lib64/tls/libpthread.so.0(__pthread_mutex_destroy+0)
[0x35ba807ab0]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/usr/local/glusterfs-mainline/lib/glusterfs/1.3.0- pre2.2/xlator/cluster/afr.so [0x2a958b840c]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/usr/local/glusterfs-mainline/lib/glusterfs/1.3.0- pre2.2/xlator/protocol/client.so [0x2a957b06c2]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/usr/local/glusterfs-mainline/lib/glusterfs/1.3.0- pre2.2/xlator/protocol/client.so [0x2a957b3196]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/usr/local/glusterfs-mainline/lib/libglusterfs.so.0 (epoll_iteration+0xf8) [0x2a955616f8]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:[glusterfs] [0x4031b7]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:/lib64/tls/libc.so.6(__libc_start_main+0xdb)
[0x35b991c3fb]
[Apr 02 13:25:11] [DEBUG/common-utils.c:215/gf_print_trace()]
debug-backtrace:[glusterfs] [0x402bba]
</snip>


the server log shows the following at the time it breaks:
<snip>
[Apr 02 15:30:09] [ERROR/common-utils.c:54/full_rw()]
libglusterfs:full_rw: 0 bytes r/w instead of 113
[Apr 02 15:30:09]
[DEBUG/protocol.c:244/gf_block_unserialize_transport()]
libglusterfs/protocol:gf_block_unserialize_transport: full_read of
header failed
[Apr 02 15:30:09] [DEBUG/proto-srv.c:2868/proto_srv_cleanup()]
protocol/server:cleaned up xl_private of 0x510470
[Apr 02 15:30:09] [DEBUG/tcp-server.c:243/gf_transport_fini()]
tcp/server:destroying transport object for 192.168.0.96:1012 (fd=8)
[Apr 02 15:30:09] [ERROR/common-utils.c:54/full_rw()]
libglusterfs:full_rw: 0 bytes r/w instead of 113
[Apr 02 15:30:09]
[DEBUG/protocol.c:244/gf_block_unserialize_transport()]
libglusterfs/protocol:gf_block_unserialize_transport: full_read of
header failed
[Apr 02 15:30:09] [DEBUG/proto-srv.c:2868/proto_srv_cleanup()]
protocol/server:cleaned up xl_private of 0x510160
[Apr 02 15:30:09] [DEBUG/tcp-server.c:243/gf_transport_fini()]
tcp/server:destroying transport object for 192.168.0.96:1013 (fd=7)
[Apr 02 15:30:09] [ERROR/common-utils.c:54/full_rw()]
libglusterfs:full_rw: 0 bytes r/w instead of 113
[Apr 02 15:30:09]
[DEBUG/protocol.c:244/gf_block_unserialize_transport()]
libglusterfs/protocol:gf_block_unserialize_transport: full_read of
header failed
[Apr 02 15:30:09] [DEBUG/proto-srv.c:2868/proto_srv_cleanup()]
protocol/server:cleaned up xl_private of 0x502300
[Apr 02 15:30:09] [DEBUG/tcp-server.c:243/gf_transport_fini()]
tcp/server:destroying transport object for 192.168.0.96:1014 (fd=4)
</snip>

we're using 4 bricks in this setup and for the moment, just one client
(would like to scale between 20-30 clients and 4-8 server bricks).
the same behavior is observed when used with or without any combination
of any of the performance translators as well as with or without file
replication. alu, random, and round-robin schedulers were all used in
our testing.
the systems in question are running CentOS (4.4). these logs are from
our 64-bit systems but we have seen the exact same thing on the 32-bit
ones as well.
this (glusterfs) looks like it could be a good fit for some of the
high-traffic domains we host, but unless we can resolve this issue,
we'll have to continue using NFS.


our current server-side (brick) config consists of the following:
##-- begin server config
volume vol1
  type storage/posix
  option directory /vol/vol1/gfs
end-volume

volume vol2
  type storage/posix
  option directory /vol/vol2/gfs
end-volume

volume vol3
  type storage/posix
  option directory /vol/vol3/gfs
end-volume

volume brick1
  type performance/io-threads
  option thread-count 8
  subvolumes vol1
end-volume

volume brick2
  type performance/io-threads
  option thread-count 8
  subvolumes vol2
end-volume

volume brick3
  type performance/io-threads
  option thread-count 8
  subvolumes vol3
end-volume

volume server
  type protocol/server
  option transport-type tcp/server
  option bind-address 10.88.188.91
  subvolumes brick1 brick2 brick3
  option auth.ip.brick1.allow 192.168.0.*
  option auth.ip.brick2.allow 192.168.0.*
  option auth.ip.brick3.allow 192.168.0.*
end-volume
##-- end server config


our client config is as follows:

##-- begin client config
volume test00.1
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.91
  option remote-subvolume brick1
end-volume
volume test00.2
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.91
  option remote-subvolume brick2
end-volume
volume test00.3
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.91
  option remote-subvolume brick3
end-volume


volume test01.1
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.92
  option remote-subvolume brick1
end-volume
volume test01.2
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.92
  option remote-subvolume brick2
end-volume
volume test01.3
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.92
  option remote-subvolume brick3
end-volume


volume test02.1
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.93
  option remote-subvolume brick1
end-volume
volume test02.2
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.93
  option remote-subvolume brick2
end-volume
volume test02.3
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.93
  option remote-subvolume brick3
end-volume


volume test03.1
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.94
  option remote-subvolume brick1
end-volume
volume test03.2
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.94
  option remote-subvolume brick2
end-volume
volume test03.3
  type protocol/client
  option transport-type tcp/client
  option remote-host 192.168.0.94
  option remote-subvolume brick3
end-volume



volume afr0
  type cluster/afr
  subvolumes test00.1 test01.2 test02.3
  option replicate *.html:3,*.db:1,*:3
end-volume

volume afr1
  type cluster/afr
  subvolumes test01.1 test02.2 test03.3
  option replicate *.html:3,*.db:1,*:3
end-volume

volume afr2
  type cluster/afr
  subvolumes test02.1 test03.2 test00.3
  option replicate *.html:3,*.db:1,*:3
end-volume

volume afr3
  type cluster/afr
  subvolumes test03.1 test00.2 test01.3
  option replicate *.html:3,*.db:1,*:3
end-volume


volume bricks
  type cluster/unify
  subvolumes afr0 afr1 afr2 afr3
  option readdir-force-success on

  option scheduler alu
  option alu.limits.min-free-disk  60GB
  option alu.limits.max-open-files 10000

  option alu.order
disk-usage:read-usage:open-files-usage:write-usage:disk-speed-usage

  option alu.disk-usage.entry-threshold 2GB
  option alu.disk-usage.exit-threshold  60MB
  option alu.open-files-usage.entry-threshold 1024
  option alu.open-files-usage.exit-threshold 32
  option alu.stat-refresh.interval 10sec

 option alu.read-usage.entry-threshold 20%
 option alu.read-usage.exit-threshold 4%
 option alu.write-usage.entry-threshold 20%
 option alu.write-usage.exit-threshold 4%

end-volume
##-- end client config


~Shawn



_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel





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

  Powered by Linux