使用monit监控rails app中的delayed_job进程的totalmem

Question

我已设置monit以密切关注delayed_job进程的运行，以确保它们不会耗尽太多内存。如果进程超过700MB，这最初设置为重新启动，因此monitrc文件的相关部分看起来像这样。

check process delayed_job_worker
  with pidfile /path/to/pidfile.pid
  start program = "/usr/bin/dj start" with timeout 60 seconds
  stop program = "/usr/bin/dj stop" with timeout 60 seconds
  if totalmem is greater than 700 MB then restart

这正如预期的那样工作但是delayed_job没有被删除所以在工作人员重新启动后，另一个人会出现并接受这个工作，delayed_job会处理这个，但是这个工作会耗费几次资源，所以我想要在这种情况下删除延迟的工作。我的解决方案看起来像这样。

check process delayed_job_worker
  with pidfile /path/to/pidfile.pid
  start program = "/usr/bin/dj start" with timeout 60 seconds
  stop program = "/usr/bin/dj stop" with timeout 60 seconds
  if totalmem is greater than 700 MB then
exec "/path/to/script/kill_and_remove_dj /path/to/pidfile.pid"

所以现在执行脚本，这个脚本从pidfile获取pid，杀死它并通过rails runner运行ruby脚本，从pid中找到delayed_job并将其从数据库中删除。这一切似乎都按预期工作，但是当我创建一个我知道将会达到内存限制的作业后我注意到ps aux | grep kill_and_remove_dj，这个命令正在反复执行。

我的理解是，在这种情况下，totalmem将是来自pid和所有子进程的进程的记忆。当exec运行脚本时，它将处于一个完全独立的过程中。只是寻找任何有可能导致此问题的人的任何指针或信息。如果需要，很高兴提供更多信息。