diff options
| -rw-r--r-- | src/rabbit_alarm.erl | 73 |
1 files changed, 45 insertions, 28 deletions
diff --git a/src/rabbit_alarm.erl b/src/rabbit_alarm.erl index b3e629079b..5cc1e75caa 100644 --- a/src/rabbit_alarm.erl +++ b/src/rabbit_alarm.erl @@ -55,38 +55,49 @@ start() -> undefined -> case os:type() of {unix, linux} -> - %% memsup doesn't take account of buffers or cache when considering - %% "free" memory - therefore on Linux we can get memory alarms - %% very easily without any pressure existing on memory at all. - %% Therefore we need to use our own simple memory monitor - - supervisor:start_child(os_mon_sup, {memsup, {rabbit_linux_memory, start_link, []}, - permanent, 2000, worker, [rabbit_linux_memory]}), - ok; + %% memsup doesn't take account of buffers or cache + %% when considering "free" memory - therefore on + %% Linux we can get memory alarms very easily + %% without any pressure existing on memory at all. + %% Therefore we need to use our own simple memory + %% monitor + {ok, _} = start_memsup(rabbit_linux_memory); _ -> - %% Start memsup programmatically rather than via the rabbitmq-server - %% script. This is not quite the right thing to do as os_mon checks - %% to see if memsup is available before starting it, but as memsup - %% is available everywhere (even on VXWorks) it should be ok. - supervisor:start_child(os_mon_sup, {memsup, {memsup, start_link, []}, - permanent, 2000, worker, [memsup]}), - - - %% The default memsup check interval is 1 minute, which is way too - %% long - rabbit can gobble up all memory in a matter of - %% seconds. Unfortunately the memory_check_interval configuration - %% parameter and memsup:set_check_interval/1 function only provide - %% a granularity of minutes. So we have to peel off one layer of - %% the API to get to the underlying layer which operates at the + %% Start memsup programmatically rather than via + %% the rabbitmq-server script. This is not quite + %% the right thing to do as os_mon checks to see + %% if memsup is available before starting it, but + %% as memsup is available everywhere (even on + %% VXWorks) it should be ok. + %% + %% One benefit of the programmatic startup is that + %% we can add our alarm_handler before memsup is + %% running, thus ensuring that we notice memory + %% alarms that go off on startup. + {ok, _} = start_memsup(memsup), + + %% The default memsup check interval is 1 minute, + %% which is way too long - rabbit can gobble up + %% all memory in a matter of seconds. + %% Unfortunately the memory_check_interval + %% configuration parameter and + %% memsup:set_check_interval/1 function only + %% provide a granularity of minutes. So we have to + %% peel off one layer of the API to get to the + %% underlying layer which operates at the %% granularity of milliseconds. %% - %% Note that the new setting will only take effect after the first - %% check has completed, i.e. after one minute. So if rabbit eats - %% all the memory within the first minute after startup then we + %% Note that the new setting will only take effect + %% after the first check has completed, i.e. after + %% one minute. So if rabbit eats all the memory + %% within the first minute after startup then we %% are out of luck. - ok = os_mon:call(memsup, {set_check_interval, ?MEMSUP_CHECK_INTERVAL}, - infinity) - end; + ok = os_mon:call( + memsup, + {set_check_interval, ?MEMSUP_CHECK_INTERVAL}, + infinity) + end, + ok; _ -> ok end. @@ -143,6 +154,12 @@ code_change(_OldVsn, State, _Extra) -> %%---------------------------------------------------------------------------- +start_memsup(Module) -> + %% This is based on os_mon:childspec(memsup, true) + supervisor:start_child(os_mon_sup, + {memsup, {Module, start_link, []}, + permanent, 2000, worker, [Module]}). + alert(Alert, Alertees) -> dict:fold(fun (Pid, {M, F, A}, Acc) -> ok = erlang:apply(M, F, A ++ [Pid, Alert]), |
