[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: exec action performance
From: |
Bill Durant |
Subject: |
Re: exec action performance |
Date: |
Mon, 21 Mar 2016 11:40:35 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 |
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 <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 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