701 / sersync

Automatically exported from code.google.com/p/sersync
0 stars 0 forks source link

sersync2.5beta1_32bit出现严重问题 #18

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
我最近在测试这个软件 今天出现了严重的问题
被监控的这台服务器 不停的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没有其它日志说明

Original issue reported on code.google.com by Ajian...@gmail.com on 15 May 2010 at 9:27

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by Ajian...@gmail.com on 15 May 2010 at 1:10

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by Ajian...@gmail.com on 15 May 2010 at 1:12

Attachments:

GoogleCodeExporter commented 9 years ago
感觉还是你配置有问题,在我的测试机和其他用户那没有发��
�类似问题。没有文件被监控也不会
产生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�
��出现无法删除远程非空目录
问题。你说的其他问题我再排查,尽快给你答复。

Original comment by zhouyang...@gmail.com on 15 May 2010 at 7:46

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

Original comment by zhouyang...@gmail.com on 15 May 2010 at 7:54

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

Original comment by Ajian...@gmail.com on 16 May 2010 at 7:15

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

Original comment by zhouyang...@gmail.com on 16 May 2010 at 9:48

GoogleCodeExporter commented 9 years ago
吐血重现你这个错误出现的原因,搞了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改成绝对路径就好了。

Original comment by zhouyang...@gmail.com on 16 May 2010 at 1:04

GoogleCodeExporter commented 9 years ago
嗯 
最好建议可以指定log日志就好了。

Original comment by Ajian...@gmail.com on 16 May 2010 at 1:13

GoogleCodeExporter commented 9 years ago
能重现就有办法了 辛苦了

Original comment by Ajian...@gmail.com on 16 May 2010 at 1:14