mmonit golang 重启缓慢且状态不存在
mmonit golang restarting slow and status does not exist
我创建了 monit 必须在崩溃时重新启动 golang site
的应用程序
$ cd /etc/monit/conf.d
$ vim checkSite
它以 nohup
启动程序并将其 pid
保存到文件:
check process site with pidfile /root/go/path/to/goSite/run.pid
start program = "/bin/bash -c 'cd /root/go/path/to/goSitePath; nohup ./goSite > /dev/null 2>&1 & echo $! > run.pid'" with timeout 5 seconds
stop program = "/bin/kill -9 `cat /root/go/path/to/goSitePath/run.pid`"
启动正常
Process 'site'
status Running
monitoring status Monitored
pid 29723
parent pid 1
uptime 2m
children 0
memory kilobytes 8592
memory kilobytes total 8592
memory percent 0.4%
memory percent total 0.4%
cpu percent 0.0%
cpu percent total 0.0%
data collected Thu, 05 Mar 2015 07:20:32
然后为了测试它如何在崩溃时重新启动,我手动杀死了 golang site
。
这里我有两个问题:
- 站点重新启动相当慢:需要 1 分钟,尽管在配置中我设置了
with timeout 5 seconds
monit
中 site
的状态变为 Does not exist
,甚至在站点实际上重新启动后也是如此。我想发生这种情况是因为在终止并重新启动网站后 pid
正在随机变化,但我不知道如何克服这个问题。
重启后状态:
Process 'site'
status Does not exist
monitoring status Monitored
data collected Thu, 05 Mar 2015 08:04:44
如何减少重启时间以及如何修复网站的monit status
?
monit
日志:
[Mar 5 08:04:44] error : 'site' process is not running
[Mar 5 08:04:44] info : 'site' trying to restart
[Mar 5 08:04:44] info : 'site' start: /bin/bash
[Mar 5 08:06:44] info : 'site' process is running with pid 31479
更新
我的 golang 网站比较简单:
package main
import (
"fmt"
"github.com/go-martini/martini"
)
func main() {
m := martini.Classic()
m.Get("/", func() {
fmt.Println("main page")
})
m.Run()
}
更新 2
我试图通过删除 pid 文件本身来提高 monit 重新加载我的 golang 站点的速度。假设我设置了 kill 29723 && rm run.pid
并打开计时器以计算网站再次可访问的时间。花了85秒。因此删除 pid 文件并没有帮助 monit 提高重新加载站点的速度。
monit 没有任何订阅机制来立即发现进程是否已死亡。
在 daemon mode 中,如文档所述,monit 通过定期轮询所有已配置规则的状态来工作,它的轮询周期是在守护程序启动时配置的,并且在某些 Linux 发行版中默认为 2 分钟,这意味着在这种情况下,monit 可能需要 2 分钟才能采取任何行动。
在你的monitrc中检查这个配置,它配置了set daemon
指令,例如,如果你想每5秒检查一次状态,那么你应该设置:
set daemon 5
在每个周期它都会更新其状态,并根据需要执行操作。因此,如果它检测到该进程不存在,它将报告 Does not exist
直到下一个轮询周期,即使它已经决定重新启动它。
start daemon
指令中的 timeout
与此轮询周期没有任何关系,这是 monit 将给予服务启动的时间。如果服务没有在这段时间内启动,monit 将报告它。
如果monit不能满足你的要求,你也可以尝试supervisord,它总是知道被执行程序的状态。
我创建了 monit 必须在崩溃时重新启动 golang site
的应用程序
$ cd /etc/monit/conf.d
$ vim checkSite
它以 nohup
启动程序并将其 pid
保存到文件:
check process site with pidfile /root/go/path/to/goSite/run.pid
start program = "/bin/bash -c 'cd /root/go/path/to/goSitePath; nohup ./goSite > /dev/null 2>&1 & echo $! > run.pid'" with timeout 5 seconds
stop program = "/bin/kill -9 `cat /root/go/path/to/goSitePath/run.pid`"
启动正常
Process 'site'
status Running
monitoring status Monitored
pid 29723
parent pid 1
uptime 2m
children 0
memory kilobytes 8592
memory kilobytes total 8592
memory percent 0.4%
memory percent total 0.4%
cpu percent 0.0%
cpu percent total 0.0%
data collected Thu, 05 Mar 2015 07:20:32
然后为了测试它如何在崩溃时重新启动,我手动杀死了 golang site
。
这里我有两个问题:
- 站点重新启动相当慢:需要 1 分钟,尽管在配置中我设置了
with timeout 5 seconds
monit
中site
的状态变为Does not exist
,甚至在站点实际上重新启动后也是如此。我想发生这种情况是因为在终止并重新启动网站后pid
正在随机变化,但我不知道如何克服这个问题。
重启后状态:
Process 'site'
status Does not exist
monitoring status Monitored
data collected Thu, 05 Mar 2015 08:04:44
如何减少重启时间以及如何修复网站的monit status
?
monit
日志:
[Mar 5 08:04:44] error : 'site' process is not running
[Mar 5 08:04:44] info : 'site' trying to restart
[Mar 5 08:04:44] info : 'site' start: /bin/bash
[Mar 5 08:06:44] info : 'site' process is running with pid 31479
更新
我的 golang 网站比较简单:
package main
import (
"fmt"
"github.com/go-martini/martini"
)
func main() {
m := martini.Classic()
m.Get("/", func() {
fmt.Println("main page")
})
m.Run()
}
更新 2
我试图通过删除 pid 文件本身来提高 monit 重新加载我的 golang 站点的速度。假设我设置了 kill 29723 && rm run.pid
并打开计时器以计算网站再次可访问的时间。花了85秒。因此删除 pid 文件并没有帮助 monit 提高重新加载站点的速度。
monit 没有任何订阅机制来立即发现进程是否已死亡。
在 daemon mode 中,如文档所述,monit 通过定期轮询所有已配置规则的状态来工作,它的轮询周期是在守护程序启动时配置的,并且在某些 Linux 发行版中默认为 2 分钟,这意味着在这种情况下,monit 可能需要 2 分钟才能采取任何行动。
在你的monitrc中检查这个配置,它配置了set daemon
指令,例如,如果你想每5秒检查一次状态,那么你应该设置:
set daemon 5
在每个周期它都会更新其状态,并根据需要执行操作。因此,如果它检测到该进程不存在,它将报告 Does not exist
直到下一个轮询周期,即使它已经决定重新启动它。
start daemon
指令中的 timeout
与此轮询周期没有任何关系,这是 monit 将给予服务启动的时间。如果服务没有在这段时间内启动,monit 将报告它。
如果monit不能满足你的要求,你也可以尝试supervisord,它总是知道被执行程序的状态。