| Yes, the "check program" executes the given program per schedule (by default every cycle) and collects results from it.
Hi Martin:I am still getting a CPU spike even with the exec on state change feature.I suspect the CPU spike now happens because of the following line: check program syslog-check with path "/sbin/service rsyslog status"Could it be that monit performs a fork & exec on every poll when it runs"/sbin/service rsyslog status" in order to get the status?Thanks,BillOn 03/18/2016 05:55 AM, Martin Pala wrote:Hi Bill,
monit 5.16 or newer executes the "exec" action by default on state change only. Previous monit versions executed the program each cycle the test matched.
You can reduce the number of times the script is executed by upgrading monit (5.17.1 recommended) and merging the status tests into one statement:
--8<--
check program syslog-check with path "/sbin/service rsyslog status"
if status != 0 then exec "/mnt/scripts/foo down" else if recovered then exec "/mnt/scripts/foo up"
--8<--
The exec action will be now executed only once, on state change. Note that when you start monit and the service has no problem, the "else if recovered" part is not executed (it is activated when the service failed and then recovered).
Regards,
Martin
On 18 Mar 2016, at 00:13, Bill Durant <address@hidden> wrote:
Hi Jan-Henrik:
Thank you for the response. That explains the temporary CPU spike.
Following is the rule where the exec action runs 'foo' which does nothing:
check program syslog-check with path "/sbin/service rsyslog status"
if status = 0 then
exec "/mnt/scripts/foo up"
if status != 0 then
exec "/mnt/scripts/foo down"
There are 20 of those 'check programs' that run 'foo' with a different
path every 30 seconds.
Is there anything that can be tuned to alleviate the "temporary" CPU
spike under this scenario?
Thanks,
Bill
On 03/17/2016 03:59 PM, Jan-Henrik Haukeland wrote:
A standard exec action is performed with spawn() which you can investigate here, https://bitbucket.org/tildeslash/monit/src/80ce931b4f4e4dc0324d0bd290cd7fc50c741c87/src/spawn.c?at=master&fileviewer=file-view-default
This is basically a standard fork->exec (with a twist) which you can also see in posix_spawn etc. Three things to note, 1) a fork->exec is “expensive” in computing terms, but this is also what your OS or shell does when it starts a new program. I.e. it is a standard operation. 2) Seeing a CPU spike at program startup, especially when done 20 times in a short timeframe is to be expected. If the CPU usage goes back to normal fairly quick it is nothing to worry about. 3) In Monit, “if X then exec ..” is meant to be used in out of bounds situations and if you have 20 execs you should probably tune ‘X’ above.
Ps. "check program”, start and restart executes in a slightly different way
On 17 Mar 2016, at 22:58, Bill Durant <address@hidden> wrote:
Hello:
How does Monit perform the exec action internally?
I am finding that running too many "exec" actions during a polling
interval causes a high system CPU usage spike.
I am able to duplicate the CPU spike by having Monit run 20 exec actions
at every 30 second polling interval even it runs a program that does
nothing such as the following:
$ cat foo.c
main(){}
$ cc -c foo foo.c
So when Monit runs "foo" 20 times via the exec action, at every polling
interval, the system CPU usage jumps to 90%+.
And staggering the exec's with a 'run every N cycles' or 'run every cron
xxx' appears to not guarantee that the number of exec's run on every
polling cycle will be minimized.
Is the exec action heavy weight by design?
Thanks,
Bill
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
-- V/r,Bill DurantG2 Software Systems, Inc.SPAWAR Systems Center Pacific, Code 5514053560 Hull Street, Bldg 606, Rm 139, San Diego, CA 92152Office: 619-553-9752 / Fax: 619-553-9376Lab: 619-553-3948 / Lab Conf. Room: 619-553-4125
|