[Oisf-users] (no subject)

[X.qing]

Is there anything wrong with my suricata.log?
i forgot to tell that the suricata.log comes when i have changed
the cluster_flow to cluster_cpu and 20 threads to 16threads because i found
that it can not improve the performance even though more hard resource is
used, which is different from the yalm file i sent before.
the rent of my drop is between 50%-60% under 2-4Gps traffic flow.

I am really confused these days.  Greatly appreciate if you could offer any
suggestions.

thank you all. (ಥ_ಥ)



2014-06-11 17:23 GMT+08:00 X.qing <xqing.summer at gmail.com>:

>
>
> Of course~  suricata.log in attachment.
> [image: 内嵌图片 2]
> (It is very nice of you.( ͡° ͜ʖ ͡°) )
>
>
> 2014-06-11 16:33 GMT+08:00 Peter Manev <petermanev at gmail.com>:
>
> On Sun, Jun 8, 2014 at 11:01 AM, Christophe Vandeplas
>> <christophe at vandeplas.com> wrote:
>> > Hi,
>> >
>> >
>> > What kind of drop do you have?
>> > - capture.kernel_drops
>> > - tcp.segment_memcap_drop
>> > - tcp.ssn_memcap_drop
>> >
>> > Lower the number of threads in the af-packet section to the number of
>> > cores your system has. (cat /proc/cpuinfo |  fgrep processor | wc -l )
>> >
>> > Run suricata with no rules, and tweak the configuration, you should
>> > have (almost) no packet drop before you activate rules.
>> >
>> > After having made changes in the yaml configuration file I usually:
>> > - stop suricata
>> > - empty the logfiles
>> > - start suricata
>> > This way there's no risk of looking at older logs and misinterpreting
>> > configuration changes.
>> >
>> >
>> > If possible, link your stats.log to a monitoring tool to greate
>> > graphs. This way you can correlate packet drops by suricata with other
>> > events on the system. I've written an article about this :
>> >
>> http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html
>> >  But also other scripts exist.
>> > Make sure you edit the suricata_stats.py script with the number of
>> > threads configured in suricata.yaml
>> >
>> >
>> > If your drops are capture.kernel_drops, then :
>> > Have you read this article?
>> >
>> http://christophe.vandeplas.com/2013/11/suricata-capturekerneldrops-caused-by.html
>> > Please do the first part "Confirmation of the problem" and see if you
>> > also have the problem caused by the lack of NIC queues.
>> > In a few words:
>> > - start suricata
>> > - as root, run  "top -H" and check how many AFPacketethXX threads are
>> > generating load.
>> > - if it's only one thread, then the problem has been pinpointed.
>> > However working with cluster_flow should solve this problem. Make sure
>> > you read the rest of the article then.
>> >
>> >
>> > Kind regards
>> > Christophe
>> >
>> >
>>
>>
>> Can you share your suricata.log as well please?
>> What is the output of
>> ethtool -k your_interface
>> ?
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20140611/a280c113/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 17150 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20140611/a280c113/attachment-0002.png>