search

buaazp / zimg

A lightweight and high performance image storage and processing system.
http://zimg.buaa.us
BSD 3-Clause "New" or "Revised" License
2.69k stars 401 forks source link

twemproxy+lvs connect error #96

Open zzc1984 opened 8 years ago

zzc1984 commented 8 years ago

把启动命令/app/zimg/bin/zimg -d /app/zimg/bin/conf/zimg.lua添加到rc.local或者写init.d的启动脚本时都报错，直接在命令行下运行上述命令就正常，请问是什么问题，报错如下： zimg 3.1.0 Copyright (c) 2013-2014 zimg.buaa.us //script/process.lua open failed!

buaazp commented 8 years ago

配置文件里的/script/process.lua 这一行用绝对路径。

zzc1984 commented 8 years ago

感谢作者。除了这个问题外我还遇到一个掉进程的问题，两台zimg，本来要是要按建议架构挂twemproxy后再挂连接两台ssdb的，但twemproxy这一层没有冗余手段，就采用了keepalived+lvs的方法给twemproxy作负载，但是发现两台img运行一段时间后进程会掉，后来测试一台没有连lvs，直接连twemproxy，观察一段时间后就没有问题了。现在问题就定位到可能是连接了lvs导致zimg进程中断，请问有什么思路可寻找到问题？谢谢！

buaazp commented 8 years ago

zimg都挂了，原因比较复杂，你把挂掉的时候的log找一找发出来我看看先。

zzc1984 commented 8 years ago

直连twemproxy的没事，连了lvs的出问题。 监控server 80端口中断时间：imgserver http port check Failed:2015-08-03 19:34:09。

/var/log/message上发现的日志，时间 19:33:55： ################################################################### Aug 3 19:33:55 img2 kernel: zimg[1283]: segfault at 0 ip 0000000000426b08 sp 00007f a5fdf295f0 error 4 in zimg[400000+9f000]

zimg/bin/log/zimg.log日志，时间从19点开始： ##################################################################### 2015/08/03 19:02:15:179643 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:869 get_request_cb() Method: 0 2015/08/03 19:02:15:179714 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:940 get_request_cb() favicon.ico Request, Denied. 2015/08/03 19:02:15:179743 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:219 zimg_headers_add() headers: 1 2015/08/03 19:33:55:264387 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:869 get_request_cb() Method: 0 2015/08/03 19:33:55:264484 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:947 get_request_cb() Got a GET request for 2015/08/03 19:33:55:264509 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zhttpd.c:972 get_request_cb() md5 of request is <182e4fb71d2e0b737c0b5d8d27f1a326> 2015/08/03 19:33:55:264535 Thread ID: 140350906869504 [DEBUG] /app/zimg/src/zdb.c:67 get_img_mode_db() get_img() start processing zimg request...

以上日志是否足够？

buaazp commented 8 years ago

看你这些日志zimg几乎没打印出什么错误信息就崩了，怀疑是hiredis的长链接跟lvs的某种机制不兼容所致，这个最好是需要调试一下才能定位问题，建议暂时去掉lvs，增加的组件越多越容易出问题。

解释一下，zimg启动的时候初始化一个hiredis的连接指针redisContext*，后续有请求时会复用这个指针进行通信。这个连接连在twemproxy上时是没问题的，不知道连在lvs上会不会因为某种调度策略重置导致指针变空。目前我这边没有类似的场景进行测试，所以具体原因也不确定。

zzc1984 commented 8 years ago

感谢作者分析，那对twemproxy这一层的热备冗余，除了lvs，keepalived外，还有什么建议方案呢？

buaazp commented 8 years ago

说实话你这个问题我也还没研究。。。我只是觉得twemproxy是无状态的，热备目前做不了的话，可以起一个备份先放着，如果之前那个挂了，可以改一下zimg的配置指向新的然后重启，达到冷备的效果。当然了这样显得比较low，还得调研调研。