[Oisf-devel] Mem leaks

[Martin Holste]

I'm pleased to report that I found the issue that was affecting
traffic earlier and performance is now excellent using ac-gfbs with
reasonable memory usage (around 10G for 7k rules).  The issue was due
to port scans filling the connection hash table due to not being
aggressive enough with flow timeouts.  The thing that I don't
understand is why I was getting zero session drops listed for both
tcp.ssn_memcap_drop and tcp.segment_memcap_drop.  It appears that
there's no way to detect when Suricata has to enter the emergency flow
state and begin prematurely killing connections, or even when the flow
table is full.

For reference, here are the changes I made to attain good performance
on a link that peaks around 750 Mb/sec:

max-pending-packets: 5000
runmode: autofp
pfring:
  threads: 8
  cluster-id: 99
  cluster-type: cluster_flow
detect-engine:
  - profile: high
  - sgh-mpm-context: full
threading:
  cpu_affinity: yes
mpm-algo: ac-gfbs
flow:
  memcap: 3294967295
  hash_size: 108435456
  emergency_recovery: 40
  prune_flows: 500
flow-timeouts:
  default:
    new: 1
    established: 10
    closed: 0
    emergency_new: 1
    emergency_established: 1
    emergency_closed: 0
  tcp:
    new: 1
    established: 10
    closed: 0
    emergency_new: 1
    emergency_established: 5
    emergency_closed: 0
  udp:
    new: 1
    established: 1
    emergency_new: 1
    emergency_established: 1
  icmp:
    new: 1
    established: 1
    emergency_new: 1
    emergency_established: 1
stream:
  memcap: 3294967295
  checksum_validation: no      # reject wrong csums
  inline: no                    # no inline mode
  reassembly:
    memcap: 4294967295
    depth: 1048576              # reassemble 1mb into a stream
    toserver_chunk_size: 2560
    toclient_chunk_size: 2560


On Tue, Oct 18, 2011 at 5:27 AM, Anoop Saldanha <poonaatsoc at gmail.com> wrote:
> On Sat, Oct 15, 2011 at 3:34 AM, Anoop Saldanha <poonaatsoc at gmail.com> wrote:
>> On Sat, Oct 15, 2011 at 12:39 AM, Martin Holste <mcholste at gmail.com> wrote:
>>>> It's expected to be slower, but the much lower memory pressure might help.
>>>
>>> So far, it's gotten 49/50 heartbeats, so I think speed is good enough,
>>> and this was pretty close to peak usage.  I'm hoping that the weird
>>> low-traffic misses are due to some strangeness when ram usage goes up
>>> to 76G and this will alleviate that.  That seems fairly nonsensical,
>>> though.  Anyway, we'll see how this performs over the next week.
>>> _______________________________________________
>>> Oisf-devel mailing list
>>> Oisf-devel at openinfosecfoundation.org
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>>>
>>
>> And this with a non-optimized ac-gfbs.  With optimizations it should
>> fare a lot better.  Would be interesting to see how much out of 10gigs
>> is taken by ac.  I recollect the engine not crossing 1.8gigs on 13k
>> rules with ac-gfbs:full and 350megs with single.  Of course there's no
>> absolute co-relation between no of rules and ac mem usage though, but
>> would be good to profile it.
>>
>> --
>> Anoop Saldanha
>>
>
> Any more perf reports/stats with ac-gfbs + high traffic?
>
> --
> Anoop Saldanha
>