Yes, the "check program" executes the given program per schedule (by default every cycle) and collects results from it.
> On 21 Mar 2016, at 19:40, Bill Durant <[email protected]> wrote: > > 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, > > Bill > > On 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 <[email protected]> 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 <[email protected]> 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 Durant > G2 Software Systems, Inc. > SPAWAR Systems Center Pacific, Code 55140 > 53560 Hull Street, Bldg 606, Rm 139, San Diego, CA 92152 > Office: 619-553-9752 / Fax: 619-553-9376 > Lab: 619-553-3948 / Lab Conf. Room: 619-553-4125
-- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
