Thanks for that information Martin. I will give it a try. - Bill
On Mar 18, 2016, 5:55 AM, at 5:55 AM, Martin Pala <[email protected]> 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
-- To unsubscribe: https://lists.nongnu.org/mailman/listinfo/monit-general
