Export to GitHub

sersync - issue #18

sersync2.5beta1_32bit出现严重问题


Posted on May 15, 2010 by Massive Ox

我最近在测试这个软件 今天出现了严重的问题 被监控的这台服务器 不停的rsync 而且所有的rsync的进程僵死 defunct 系统压力狂升

进程情况: svn]# ps aux | grep rsync root 8129 0.0 0.0 63844 1080 ? R 17:00 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8136 2.2 0.0 0 0 ? Z 17:00 0:00 [rsync] <defunct> root 8139 0.0 0.0 63844 1076 ? R 17:00 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8140 2.5 0.0 0 0 ? Z 17:00 0:00 [rsync] <defunct> root 8155 0.0 0.0 63844 1080 ? R 17:00 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8156 2.5 0.0 0 0 ? Z 17:00 0:00 [rsync] <defunct> root 8159 0.0 0.0 63844 1076 ? R 17:00 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8160 2.5 0.0 0 0 ? Z 17:00 0:00 [rsync] <defunct> root 8161 0.0 0.0 63844 1076 ? R 17:00 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8162 2.5 0.0 0 0 ? Z 17:00 0:00 [rsync] <defunct> root 8179 0.0 0.0 63844 1076 ? R 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8180 5.0 0.0 0 0 ? Z 17:01 0:00 [rsync] <defunct> root 8181 0.0 0.0 63844 1076 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8182 0.0 0.0 65492 776 ? R 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.164::server root 8187 0.0 0.0 63844 1080 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8188 0.0 0.0 65492 772 ? R 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.164::server root 8191 0.0 0.0 63844 1076 ? R 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8192 5.0 0.0 0 0 ? Z 17:01 0:00 [rsync] <defunct> root 8193 0.0 0.0 63844 1076 ? R 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8194 0.0 0.0 0 0 ? Z 17:01 0:00 [rsync] <defunct> root 8197 0.0 0.0 63844 1080 ? R 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8198 5.0 0.0 0 0 ? Z 17:01 0:00 [rsync] <defunct> root 8199 0.0 0.0 63844 1076 ? R 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8200 0.0 0.0 0 0 ? Z 17:01 0:00 [rsync] <defunct> root 8207 0.0 0.0 63844 1076 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8208 9.0 0.0 66300 1204 ? S 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.163::server root 8209 0.0 0.0 63844 1080 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8210 0.0 0.0 65492 772 ? R 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.164::server root 8216 0.0 0.0 63844 1076 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8217 0.0 0.0 65492 816 ? R 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.163::server root 8218 0.0 0.0 63844 1080 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.164::server >/dev/null 2>&1 root 8219 0.0 0.0 65492 776 ? R 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.164::server root 8220 0.0 0.0 63844 1080 ? S 17:01 0:00 sh -c cd /home/server && rsync -rtu -R "./rsync_fail_log.sh" 192.168.13.163::server >/dev/null 2>&1 root 8221 0.0 0.0 65492 820 ? S 17:01 0:00 rsync -rtu -R ./rsync_fail_log.sh 192.168.13.163::server root 8224 0.0 0.0 6020 556 pts/10 R+ 17:01 0:00 grep rsync root 11597 41.9 0.0 304648 1796 ? Rsl May14 613:30 sersync2 -d -o /home/sh/confxml.xml

系统压力: top - 17:02:53 up 325 days, 1:30, 6 users, load average: 14.67, 13.63, 13.02 Tasks: 325 total, 13 running, 312 sleeping, 0 stopped, 0 zombie Cpu(s): 1.1%us, 0.9%sy, 1.7%ni, 94.6%id, 0.4%wa, 0.3%hi, 1.0%si, 0.0%st Mem: 4049336k total, 3996108k used, 53228k free, 170616k buffers Swap: 7118832k total, 635692k used, 6483140k free, 881148k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9246 root 16 0 66788 1692 764 R 19.3 0.0 0:00.10 rsync 9229 root 16 0 66788 1684 764 R 17.4 0.0 0:00.09 rsync 9239 root 16 0 66788 1688 764 R 17.4 0.0 0:00.09 rsync 9251 root 16 0 66788 1688 764 R 17.4 0.0 0:00.09 rsync 9213 root 15 0 66788 1688 764 R 9.6 0.0 0:00.05 rsync

系统监控图: 看附件 最后把所有的进程杀掉之后压力就降下来了。

说明: 1)使用的版本:sersync2.5beta1_32bit_binary.tar.gz 2)监控的目录并没有添加任何东西 3)传送的目录是rsync_fail_log.sh 4)远程目标服务器的rsync我都测试过正常 5)sersync没有其它日志说明

Comment #1

Posted on May 15, 2010 by Massive Ox

(No comment was entered for this change.)

Attachments

Comment #2

Posted on May 15, 2010 by Massive Ox

(No comment was entered for this change.)

Attachments

Comment #3

Posted on May 15, 2010 by Massive Hippo

感觉还是你配置有问题,在我的测试机和其他用户那没有发现类似问题。没有文件被监控也不会 产生rsync_fail_log的情况的。我暂时还模拟不出你出的问题。还是不知道为什么你的会不停的 同步rsync_fail_log,这个里面有什么,能不能看一下?另外建议sersync不要放在被监控目录 下。还有疑问就是即使同步rsync_fail_log这个文件,rsync命令本身没有错误,也不会造成程序 死掉的。这个命令造成出错的命令,你单独粘出来执行会不会有问题?rsync会不会死。我的程序 原理很简单,如果我拼的rsync命令没有问题,其他配置的问题了。所以你可以开启xml中的 debug,并不要带其他参数运行,然后测试一下新建立文件,会在控制台(是控制台,不是 rsync_fail_log)打印什么信息。非常感谢你的测试,我的程序在rsync请求阻塞的时候会死掉, 所以我估计还是rsync命令问题。另外rsync版本要求是2.6的,3.0会出现无法删除远程非空目录 问题。你说的其他问题我再排查,尽快给你答复。

Comment #4

Posted on May 15, 2010 by Massive Hippo

我又想了想,目前我遇到的程序死掉的唯一原因就是大量rsync命令发送失败,如果只是部分失败 都不会死掉。因为同时开了很多线程。死掉的原因是因为,线程等待rsync传输文件,但rsync由 于配置原因或发送命令错误或者网络状况很差长时间阻塞或死掉,所以造成sersync工作一段时间 后所有线程全死,即所有线程等待rsync回复。 从目前的情况看先从rsync命令上找原因。开启debug查看sersync发送的rsync命令,并将其粘出 来调试,是最直接方法了。最近比较忙,你说的其他问题我尽力修改。但像你这样严重的问题, 应该不是sersync原因,否则其他用户,或者我自己多少都会碰到。非常感谢你的支持。

Comment #5

Posted on May 16, 2010 by Massive Ox

1、我并没有把sersync放在被监控的目录下 我是放在/usr/bin/sersync2 2、产生的rsync_fail_log文件前面说过内容是空的,而且我在debug的时候就会发现过一段时间 就会对这个文件进行同步,但文件内容同样是空的 3、传送失败的问题,就算产生这个文件传送我手动测试过也是可以传送的 远程服务器不存在服 务的问题,(我测试的远程服务器其实就是同交换机的内网服务,网络阻塞这些情况都可以排除) 4、对于你说的配置问题更不应该了,因为在出现问题之前我一直测试文件同步都是正常的 文件 都可以同步过去如果是配置问题那么在一开始就应该会有问题。 5、我的系统是centos5.4 x84_64 6、我再尝试能不能重现

Comment #6

Posted on May 16, 2010 by Massive Hippo

好的,既然文件同步时可以的,对于你说的问题,无论是什么原因造成的,看来只要保证 rsync_fail_log不在同步目录下就能解决,我改一下吧,这样就省着你费劲重现了。非常感谢你的 测试,我尽快改进,先保证你的项目可用,具体你在上个issue细节问题,我找时间再改~~~~。

Comment #7

Posted on May 16, 2010 by Massive Hippo

吐血重现你这个错误出现的原因,搞了1小时终于重现出来了:大概是相对路径和绝对路径原因, 你看看对不对哈~ 首先,我的程序的rsync_fail_log会在程序执行的目录产生,分两种情况: 1. 程序在非监控目录,/usr/bin下执行 ./sersync -d 这个时候会在/usr/bin下产生rsync_fail_log文件,是安全的,一般情况下大家都 是这样运行的。 2. 在监控目录下 /opt/watch 下执行 ./usr/bin/sersync -d -o /usr/bin/confxml.xml这个时 候会在监控目录下 /opt/watch 下产生rsync_fail_log文件,然后我的程序需要每隔一段时间寻 找rsync_fail_log并执行,然后就由于同步过程中不断的cd切换目录,会在你程序执行失败目录 产生这个文件,然后由于某种原因反复执行某一个失败的rsync_fail_log程序死亡。 估计把rsync_fail_log改成绝对路径就好了。

Comment #8

Posted on May 16, 2010 by Massive Ox

嗯 最好建议可以指定log日志就好了。

Comment #9

Posted on May 16, 2010 by Massive Ox

能重现就有办法了 辛苦了

Status: New

Labels:
Type-Defect Priority-Medium