Actions
Bug #1202
closeddetect-engine profile medium consumes more memory than detect-engine profile high
Affected Versions:
Effort:
Difficulty:
Label:
Description
Between runs the only thing that I changed in suricata.yaml was from
detect-engine: - profile: high
to
detect-engine: - profile: medium
in both cases using - sgh-mpm-context: full :
detect-engine: - profile: high - custom-values: toclient-src-groups: 4 toclient-dst-groups: 4 toclient-sp-groups: 4 toclient-dp-groups: 6 toserver-src-groups: 4 toserver-dst-groups: 8 toserver-sp-groups: 4 toserver-dp-groups: 30 - sgh-mpm-context: full
detect-engine: - profile: medium - custom-values: toclient-src-groups: 4 toclient-dst-groups: 4 toclient-sp-groups: 4 toclient-dp-groups: 6 toserver-src-groups: 4 toserver-dst-groups: 8 toserver-sp-groups: 4 toserver-dp-groups: 30 - sgh-mpm-context: full
I can consistently reproduce the following -
with profile medium Suricata consumes 10G RAM more at startup as compared to profile high.
(with the very same set up)
It seems really strange that medium consumes a third more memory than high....
Some Suricata related info
suricata --build-info This is Suricata version 2.0dev (rev 7e8f80b) Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK HAVE_NSS HAVE_LIBJANSSON SIMD support: SSE_4_2 SSE_4_1 SSE_3 Atomic intrisics: 1 2 4 8 16 byte(s) 64-bits, Little-endian architecture GCC version 4.6.3, C version 199901 compiled with -fstack-protector compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 compiled with LibHTP v0.5.11, linked against LibHTP v0.5.11 Suricata Configuration: AF_PACKET support: yes PF_RING support: yes NFQueue support: no IPFW support: no DAG enabled: no Napatech enabled: no Unix socket enabled: yes Detection enabled: yes libnss support: yes libnspr support: yes libjansson support: yes Prelude support: no PCRE jit: no libluajit: no libgeoip: no Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: yes Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Coccinelle / spatch: yes Generic build parameters: Installation prefix (--prefix): /usr/local Configuration directory (--sysconfdir): /usr/local/etc/suricata/ Log directory (--localstatedir) : /usr/local/var/log/suricata/ Host: x86_64-unknown-linux-gnu GCC binary: gcc GCC Protect enabled: no GCC march native enabled: yes GCC Profile enabled: no
Updated by Victor Julien about 10 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 3.0RC2
The grouping is a bit of magic, which I'm considering to redo. Will test this if I do.
Updated by Victor Julien almost 9 years ago
- Target version changed from 3.0RC2 to 70
Updated by Victor Julien over 8 years ago
I expect this to be resolved in my detection engine rewrite work: https://github.com/inliniac/suricata/pull/1811
Updated by Peter Manev over 8 years ago
So far all indicates that this is the case (resolved by https://github.com/inliniac/suricata/pull/1811)
Updated by Victor Julien over 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.1rc1
Actions