Adjust the RabbitMQ kernel net_ticktime parameter

W/o this fix, the situation is possible when some
arbitrary queue masters got stuck due to high
short-time CPU load spikes ending up in the
rabbitmqctl hanged and affected rabbit node erased
and restarted by OCF monitor logic of the related
pacemaker RA.

This is an issue as it seems that Oslo.messaging yet
to be in a good shape to survive this short-time
outage of underlying AMQP layer without disrupting
interrupted RPC calls being executed.

The workaround is to reduce the net_ticktime kernel
parameter from default 60 seconds to 10 seconds.
What would allow the RabbitMQ cluster to better detect
short-time partitions and autoheal them. And when the
partition has been detected and healed, the rabbitmqctl
would not hang hopefully as stucked queue masters will
be recovered.

Partial-bug: #1460762

Change-Id: I3aa47b51ae080bb4a8b298c61a629ac8225d2abd
Signed-off-by: Bogdan Dobrelya <bdobrelia@mirantis.com>
(cherry picked from commit 3ffae36b9d)
This commit is contained in:
Bogdan Dobrelya 2015-06-08 15:24:36 +02:00 committed by Denis V. Meltsaykin
parent 1c296931d1
commit ff320db589
1 changed files with 1 additions and 0 deletions

View File

@ -57,6 +57,7 @@ if $queue_provider == 'rabbitmq' {
'inet_dist_listen_min' => '41055',
'inet_dist_listen_max' => '41055',
'inet_default_connect_options' => '[{nodelay,true}]',
'net_ticktime' => '10',
}
)
$config_variables = hiera('rabbit_config_variables',