[Oisf-users] Couple of questions regarding stats.log

Brandon Ganem brandonganem+oisf at gmail.com
Fri Jun 8 17:24:42 UTC 2012


It looks like *tcp.ssn_memcap_drop       | Detect                    | 6019
*is starting to add up now too.

Thanks!

On Fri, Jun 8, 2012 at 1:09 PM, Brandon Ganem
<brandonganem+oisf at gmail.com>wrote:

> *Up your memcap settings to 4GB each and see if the numbers improve.
> Both memcap drop stats should be zero when everything's right. *
> Done
>
> *This is odd. Your stream related memcap is 1GB, yet this shows 6GB in
> use? Which again doesn't seem to match the memory usage you seem to be
> seeing for the whole process. Smells like a bug to me... *
> *
> *
> Let me know if you want me to compile in some debugging features. If I can
> provide any additional information let me know.
>
> CPU / MEM: ~50-125% (similar to before) ~2-2.6GB(similar as well.)
>  Suricata has only been running for a few minutes, but here is a new
> stats.log:
>
> tcp.sessions              | Detect                    | 464890
> *tcp.ssn_memcap_drop       | Detect                    | 0 (maybe better,
> it may have to run for a while to start adding up though?)*
> tcp.pseudo                | Detect                    | 10567
> tcp.invalid_checksum      | Detect                    | 0
> tcp.no_flow               | Detect                    | 0
> tcp.reused_ssn            | Detect                    | 0
> tcp.memuse                | Detect                    | 141604560
> tcp.syn                   | Detect                    | 465555
> tcp.synack                | Detect                    | 233829
> tcp.rst                   | Detect                    | 46181
> *tcp.segment_memcap_drop   | Detect                    | 1281114 (I don't
> think this is impoving)*
> *tcp.stream_depth_reached  | Detect                    | 70        (Looks
> like this is still going up*
> tcp.reassembly_memuse     | Detect                    | 6442450806
> *(still 6GB not 4GB)*
> *tcp.reassembly_gap        | Detect                    | 44583
> (Still going up)*
> detect.alert              | Detect                    | 25
> flow_mgr.closed_pruned    | FlowManagerThread         | 150973
> flow_mgr.new_pruned       | FlowManagerThread         | 207334
> flow_mgr.est_pruned       | FlowManagerThread         | 0
> flow.memuse               | FlowManagerThread         | 41834880
> flow.spare                | FlowManagerThread         | 10742
> flow.emerg_mode_entered   | FlowManagerThread         | 0
> flow.emerg_mode_over      | FlowManagerThread         | 0
> decoder.pkts              | RxPFR1                    | 17310168
> decoder.bytes             | RxPFR1                    | 7387022602
> decoder.ipv4              | RxPFR1                    | 17309598
> decoder.ipv6              | RxPFR1                    | 0
>  decoder.ethernet          | RxPFR1                    | 17310168
> decoder.raw               | RxPFR1                    | 0
> decoder.sll               | RxPFR1                    | 0
> decoder.tcp               | RxPFR1                    | 15519823
> decoder.udp               | RxPFR1                    | 210
> decoder.sctp              | RxPFR1                    | 0
> decoder.icmpv4            | RxPFR1                    | 1323
> decoder.icmpv6            | RxPFR1                    | 0
> decoder.ppp               | RxPFR1                    | 0
> decoder.pppoe             | RxPFR1                    | 0
> decoder.gre               | RxPFR1                    | 0
> decoder.vlan              | RxPFR1                    | 0
> decoder.avg_pkt_size      | RxPFR1                    | 427
> decoder.max_pkt_size      | RxPFR1                    | 1516
> defrag.ipv4.fragments     | RxPFR1                    | 15
> defrag.ipv4.reassembled   | RxPFR1                    | 5
> defrag.ipv4.timeouts      | RxPFR1                    | 0
> defrag.ipv6.fragments     | RxPFR1                    | 0
> defrag.ipv6.reassembled   | RxPFR1                    | 0
> defrag.ipv6.timeouts      | RxPFR1                    | 0
>
>
> Here's what has been changed in the cfg:
>
> flow:
> *  memcap: 4gb*
>   hash-size: 65536
>   prealloc: 10000
>   emergency-recovery: 30
>   prune-flows: 5
>
> stream:
> *  memcap: 4gb*
>
> On Fri, Jun 8, 2012 at 12:31 PM, Victor Julien <victor at inliniac.net>wrote:
>
>> On 06/08/2012 05:59 PM, Brandon Ganem wrote:
>> > tcp.reassembly_memuse     | Detect                    | 6442450854
>>
>> This is odd. Your stream related memcap is 1GB, yet this shows 6GB in
>> use? Which again doesn't seem to match the memory usage you seem to be
>> seeing for the whole process. Smells like a bug to me...
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120608/be2c180f/attachment-0002.html>


More information about the Oisf-users mailing list