Thanks for clarifying. - Bill
On Mar 22, 2016, 4:07 AM, at 4:07 AM, Martin Pala <[email protected]> wrote: >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
