]> git.ipfire.org Git - thirdparty/suricata.git/commit
flow/manager: fix flows not evicted & freed in time 6602/head
authorVictor Julien <victor@inliniac.net>
Sun, 7 Nov 2021 05:25:31 +0000 (06:25 +0100)
committerVictor Julien <victor@inliniac.net>
Thu, 11 Nov 2021 15:33:34 +0000 (16:33 +0100)
commit244dd11c34152fbdb01636da8a9fa4a9fa0de050
treedb2c21315e9d645f21f115e2c319fe6e63ea6888
parentace349d4d9208e18836c4312b220a93b1e3b154c
flow/manager: fix flows not evicted & freed in time

Flows have been shown to linger for a long time w/o giving up their
resources. This would lead to higher memory use and memcaps getting
reached.

Three main causes have been identified:

Slow passes hash passes. By default the flow manager will scan the
flow hash slowly. It is based on the flow timeout settings, and with
the default config it will take 4 minutes for a full scan to be
complete. This leaves a window for flows that are timed out to linger
for minutes longer than expected.

Flow Manager yields under pressure. The per row TryLock causes work
to be delayed more. The Flow manager will use trylock on a hash row
and will yield immediately if the row is busy. This means that it will
take a full pass before the row is revisited again. If the row holds
busy flows, this could happen many times in a row.

Flow Manager favors evicted flows over active flows. The Flow Manager
will only process the evicted flows if they are present. These flows
have been evicted by workers. The active flows on that hash row will
have to wait until the next hash pass. Of course by then there could
be more evicted flows.

Combined these factors could lead to flows not being considered for
freeing and logging for a very long time, potentially even indefinitly.

The patch addresses the latter two flow manager issues by no longer
using TryLock. It will now simply wait for the lock to be released and
then do its work on it. Additionally for each row both the evicted list
and the active flow list will be processed.

Bug: #4650.
src/flow-manager.c