rails 服务的稳定性有关问题
rails 服务的稳定性问题
项目有需求，这么个情况，我们的rails由于情况特殊，要部署在AIX/hp等系统上，首页是做系统监控，需要不断的刷新，而且这个页面要求长时间打开，无论白天还是晚上，连续运行（监控用,并发量非常小）。连续运行几天后监控页面就出现不稳定状况，有服务报错，但手动刷新一切恢复正常，后台mongrel出现进程假死，有守护进程重启mongrel。客户不能接受手动刷新恢复正常页面。（ruby 常驻进程很容易coredump）。一般连续运行2天肯定会碰到一次，linux上相对稳定性高一些。
也选用了tomcat和glassfish来跑rails，碍于对内存的需求过高（old gen 的gc不是太好），很难推行。
其他部署方案附有apache的放弃尝试了，因为在部分客户环境不允许gcc，而且东西太大了，对实施成本有影响。鉴于这样的情况，如果追求连续稳定的运行rails。大家看看还有没什么更好的方案尝试。
1.自动刷新是js里面做了跳转刷新refresh
2.mongrel 进程假死，过几分钟是会自动恢复正常状态，并非crash掉这个进程
3.linux 的确会存在这种情况，但几率非常小，感觉不太到
4.软件冲突是不存在的，至于是不是只有我的mongrel会不会出问题，这个我就不好回答了，我倒是很希望只是我
部署的服务有问题，那反而好办
这个应用前提是一个页面长时间的运行，以周为单位，不需要人工干预的监控。有session过期问题之类的都已排除，我的页面在刷新之前用ajax先对服务器相应做了判断，后台用curl对mongrel进程也做了判断。但是稳定性上的问题还是没法解决。
mongrel 老早该过时了，，其他方式也试过了，多多少少也会表现出一些问题，现在是没办法，只能部署在linux上，AIX上的稳定性还是有待考验。
1.我的开发环境就是用passenger的，但客户环境AIX、HP居多。而且passenger和apache配用，没单独用
2.应用中的外部访问如dblink之类的容易报异常的很早之前就被我移除这个action了，稳定性和这个经测试，关系不大。
3.确保总有可用的后台进程服务，一直有监控重启脚本，问题在于，即使我curl发起的http请求能检测到服务进程挂住，此时我页面的出错，已经无法自动恢复，所以解决不了我的问题，需求是不能手动刷新页面。
linux下稳定性相对不错，，但是我的问题是在AIX/HP下的稳定性，所以就犯难了，而且AIX下的ruby coredump，分析不出具体出在那个环节上
thin 貌似在unix上实施不太方便的吧，，，没仔细测试过，，有时间的话，可以去尝试尝试
apache等不是不能用，对实施成本有影响，在此 不讨论为什么不能用，谢谢
其实用mod_rails 就得也能够用apache了，，在AIX上编译apache。。起初也是用apache等部署方案，实施组消耗的时间成本过大。
其实用mod_rails 就得也能够用apache了，，在AIX上编译apache。。起初也是用apache等部署方案，实施组消耗的时间成本过大。
你也可以用nginx啊 整合能更方便，更简单。。消耗更低。。
根据楼主的需求，你的答案最为实在靠普。
项目有需求，这么个情况，我们的rails由于情况特殊，要部署在AIX/hp等系统上，首页是做系统监控，需要不断的刷新，而且这个页面要求长时间打开，无论白天还是晚上，连续运行（监控用,并发量非常小）。连续运行几天后监控页面就出现不稳定状况，有服务报错，但手动刷新一切恢复正常，后台mongrel出现进程假死，有守护进程重启mongrel。客户不能接受手动刷新恢复正常页面。（ruby 常驻进程很容易coredump）。一般连续运行2天肯定会碰到一次，linux上相对稳定性高一些。
也选用了tomcat和glassfish来跑rails，碍于对内存的需求过高（old gen 的gc不是太好），很难推行。
其他部署方案附有apache的放弃尝试了，因为在部分客户环境不允许gcc，而且东西太大了，对实施成本有影响。鉴于这样的情况，如果追求连续稳定的运行rails。大家看看还有没什么更好的方案尝试。
1 楼
hellojinjie
2010-12-07
你的手动刷新和自动刷新有什么区别啊，手动刷新就是点一下浏览器的刷新按钮？
那自动刷新呢？
既然mongrel 都假死了，那手动刷新又怎么会恢复正常呢？？
linux 相对稳定些。。。是不是说linux上也会出现假死的问题。。。
我是相当得奇怪，为什么只会你的mongrel出现问题？是您的mongrel的版本和机器上其他的软件冲突？
那自动刷新呢？
既然mongrel 都假死了，那手动刷新又怎么会恢复正常呢？？
linux 相对稳定些。。。是不是说linux上也会出现假死的问题。。。
我是相当得奇怪，为什么只会你的mongrel出现问题？是您的mongrel的版本和机器上其他的软件冲突？
2 楼
jiachengxi38
2010-12-08
hellojinjie 写道
你的手动刷新和自动刷新有什么区别啊，手动刷新就是点一下浏览器的刷新按钮？
那自动刷新呢？
既然mongrel 都假死了，那手动刷新又怎么会恢复正常呢？？
linux 相对稳定些。。。是不是说linux上也会出现假死的问题。。。
我是相当得奇怪，为什么只会你的mongrel出现问题？是您的mongrel的版本和机器上其他的软件冲突？
那自动刷新呢？
既然mongrel 都假死了，那手动刷新又怎么会恢复正常呢？？
linux 相对稳定些。。。是不是说linux上也会出现假死的问题。。。
我是相当得奇怪，为什么只会你的mongrel出现问题？是您的mongrel的版本和机器上其他的软件冲突？
1.自动刷新是js里面做了跳转刷新refresh
2.mongrel 进程假死，过几分钟是会自动恢复正常状态，并非crash掉这个进程
3.linux 的确会存在这种情况，但几率非常小，感觉不太到
4.软件冲突是不存在的，至于是不是只有我的mongrel会不会出问题，这个我就不好回答了，我倒是很希望只是我
部署的服务有问题，那反而好办
这个应用前提是一个页面长时间的运行，以周为单位，不需要人工干预的监控。有session过期问题之类的都已排除，我的页面在刷新之前用ajax先对服务器相应做了判断，后台用curl对mongrel进程也做了判断。但是稳定性上的问题还是没法解决。
3 楼
cbjeye
2010-12-08
用linux吗？一直刷新，没遇到这样的问题
4 楼
amonlei
2010-12-10
不用mongrel这个没人要的孩子了，都没人维护了。换其他部署方案44
5 楼
jiachengxi38
2010-12-10
amonlei 写道
不用mongrel这个没人要的孩子了，都没人维护了。换其他部署方案44
mongrel 老早该过时了，，其他方式也试过了，多多少少也会表现出一些问题，现在是没办法，只能部署在linux上，AIX上的稳定性还是有待考验。
6 楼
dazuiba
2010-12-11
两处着手解决稳定问题：
1. 完善部署方案
想省事儿就用passenger, 要不就得自己写监控/重启脚本。 确保总有可用的后台进程服务
2. 隔离应用程序中容易除问题的操作
容易出错的可以理解成“耗时的”或者“访问外部环境的”
针对“耗时”的部分，可以考虑做成backgroud, 或者单拉出来部署，不影响主应用。
针对“访问外部环境”的部分， 要做timeout等判断。尽量也单独部署。
1. 完善部署方案
想省事儿就用passenger, 要不就得自己写监控/重启脚本。 确保总有可用的后台进程服务
2. 隔离应用程序中容易除问题的操作
容易出错的可以理解成“耗时的”或者“访问外部环境的”
针对“耗时”的部分，可以考虑做成backgroud, 或者单拉出来部署，不影响主应用。
针对“访问外部环境”的部分， 要做timeout等判断。尽量也单独部署。
7 楼
fansofjava
2010-12-11
在linux下的话,我觉得用nginx+thin/passenger都算不错吧，最近听说passenger挺火的，都可以试一下，当然特殊一点需求可以试一下其它的。
8 楼
t0uch
2010-12-12
thin/unicorn/passenger + nginx 都是不错的选择，lz可以考虑看看
9 楼
jiachengxi38
2010-12-13
dazuiba 写道
两处着手解决稳定问题：
1. 完善部署方案
想省事儿就用passenger, 要不就得自己写监控/重启脚本。 确保总有可用的后台进程服务
2. 隔离应用程序中容易除问题的操作
容易出错的可以理解成“耗时的”或者“访问外部环境的”
针对“耗时”的部分，可以考虑做成backgroud, 或者单拉出来部署，不影响主应用。
针对“访问外部环境”的部分， 要做timeout等判断。尽量也单独部署。
1. 完善部署方案
想省事儿就用passenger, 要不就得自己写监控/重启脚本。 确保总有可用的后台进程服务
2. 隔离应用程序中容易除问题的操作
容易出错的可以理解成“耗时的”或者“访问外部环境的”
针对“耗时”的部分，可以考虑做成backgroud, 或者单拉出来部署，不影响主应用。
针对“访问外部环境”的部分， 要做timeout等判断。尽量也单独部署。
1.我的开发环境就是用passenger的，但客户环境AIX、HP居多。而且passenger和apache配用，没单独用
2.应用中的外部访问如dblink之类的容易报异常的很早之前就被我移除这个action了，稳定性和这个经测试，关系不大。
3.确保总有可用的后台进程服务，一直有监控重启脚本，问题在于，即使我curl发起的http请求能检测到服务进程挂住，此时我页面的出错，已经无法自动恢复，所以解决不了我的问题，需求是不能手动刷新页面。
10 楼
jiachengxi38
2010-12-13
fansofjava 写道
在linux下的话,我觉得用nginx+thin/passenger都算不错吧，最近听说passenger挺火的，都可以试一下，当然特殊一点需求可以试一下其它的。
linux下稳定性相对不错，，但是我的问题是在AIX/HP下的稳定性，所以就犯难了，而且AIX下的ruby coredump，分析不出具体出在那个环节上
11 楼
jiachengxi38
2010-12-13
t0uch 写道
thin/unicorn/passenger + nginx 都是不错的选择，lz可以考虑看看
thin 貌似在unix上实施不太方便的吧，，，没仔细测试过，，有时间的话，可以去尝试尝试
12 楼
Hooopo
2010-12-13
你的意思是单进程部署？不能用nginx和apache?
13 楼
ramus
2010-12-13
我之前用的是 ruby 1.8 rails 2.3.2 mongrel+ apache。。跑一天后就挂了。。重启后就没事了。。经常假死。。
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
14 楼
jiachengxi38
2010-12-14
Hooopo 写道
你的意思是单进程部署？不能用nginx和apache?
apache等不是不能用，对实施成本有影响，在此 不讨论为什么不能用，谢谢
15 楼
jiachengxi38
2010-12-14
ramus 写道
我之前用的是 ruby 1.8 rails 2.3.2 mongrel+ apache。。跑一天后就挂了。。重启后就没事了。。经常假死。。
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
其实用mod_rails 就得也能够用apache了，，在AIX上编译apache。。起初也是用apache等部署方案，实施组消耗的时间成本过大。
16 楼
ramus
2010-12-14
jiachengxi38 写道
ramus 写道
我之前用的是 ruby 1.8 rails 2.3.2 mongrel+ apache。。跑一天后就挂了。。重启后就没事了。。经常假死。。
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
后来我换了ruby 1.8企业版 把mongrel换成mod_rails 目前稳定得很。。而且速度也快
其实用mod_rails 就得也能够用apache了，，在AIX上编译apache。。起初也是用apache等部署方案，实施组消耗的时间成本过大。
你也可以用nginx啊 整合能更方便，更简单。。消耗更低。。
17 楼
kingwkb
2011-03-22
变通一下
你的问题是网页刷新是时候如果服务器有问题或者网络有问题都会出现刷新不出来的情况
你用一个父页面，iframe监控页面，在父页面上用js定时刷新iframe，这样即使遇到问题监控页面刷不出来，那等到下次刷新时也就出来了。
你的问题是网页刷新是时候如果服务器有问题或者网络有问题都会出现刷新不出来的情况
你用一个父页面，iframe监控页面，在父页面上用js定时刷新iframe，这样即使遇到问题监控页面刷不出来，那等到下次刷新时也就出来了。
18 楼
alang
2011-05-16
换java做吧。看你这么纠结。
19 楼
qichunren
2011-05-18
kingwkb 写道
变通一下
你的问题是网页刷新是时候如果服务器有问题或者网络有问题都会出现刷新不出来的情况
你用一个父页面，iframe监控页面，在父页面上用js定时刷新iframe，这样即使遇到问题监控页面刷不出来，那等到下次刷新时也就出来了。
你的问题是网页刷新是时候如果服务器有问题或者网络有问题都会出现刷新不出来的情况
你用一个父页面，iframe监控页面，在父页面上用js定时刷新iframe，这样即使遇到问题监控页面刷不出来，那等到下次刷新时也就出来了。
根据楼主的需求，你的答案最为实在靠普。