From 492ccc900c3358f36b6b14a207beec071eb06707 Mon Sep 17 00:00:00 2001 From: Sage Weil Date: Thu, 8 Jan 2015 13:34:52 -0800 Subject: [PATCH] osd: requeue PG when we skip handling a peering event If we don't handle the event, we need to put the PG back into the peering queue or else the event won't get processed until the next event is queued, at which point we'll be processing events with a delay. The queue_null is not necessary (and is a waste of effort) because the event is still in pg->peering_queue and the PG is queued. Note that this only triggers when we exceeed osd_map_max_advance, usually when there is a lot of peering and recovery activity going on. A workaround is to increase that value, but if you exceed osd_map_cache_size you expose yourself to crache thrashing by the peering work queue, which can cause serious problems with heavily degraded clusters and bit lots of people on dumpling. Backport: giant, firefly Fixes: #10431 Signed-off-by: Sage Weil --- src/osd/OSD.cc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/osd/OSD.cc b/src/osd/OSD.cc index bda3622e8c560..7c45ae80d0e56 100644 --- a/src/osd/OSD.cc +++ b/src/osd/OSD.cc @@ -8372,7 +8372,9 @@ void OSD::process_peering_events( continue; } if (!advance_pg(curmap->get_epoch(), pg, handle, &rctx, &split_pgs)) { - pg->queue_null(curmap->get_epoch(), curmap->get_epoch()); + // we need to requeue the PG explicitly since we didn't actually + // handle an event + peering_wq.queue(pg); } else if (!pg->peering_queue.empty()) { PG::CephPeeringEvtRef evt = pg->peering_queue.front(); pg->peering_queue.pop_front(); -- 2.39.5