[Oisf-users] (no subject)

[Peter Manev]

On Wed, Jun 11, 2014 at 3:32 PM, X.qing <xqing.summer at gmail.com> wrote:
>
> 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. (ಥ_ಥ)

Did you explore any of the suggestions form Christophe ?
Have you disabled irqbalance ?

Besides the dorps , I also see this in your suricata.log -
11/6/2014 -- 16:58:29 - <Info> - Flow emergency mode over, back to
normal... unsetting FLOW_EMERGENCY bit (ts.tv_sec: 1402477082,
ts.tv_usec:696562) flow_spare_q status(): 70% flows at the queue

Can you share your stats.log The last entries (last update/write in
the log) - I assume it will be very long so please use pastebin or
something similar.

thanks

>
>
>
>
> 2014-06-11 17:23 GMT+08:00 X.qing <xqing.summer at gmail.com>:
>
>>
>>
>> Of course~  suricata.log in attachment.
>>
>> (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
>>> ?
>>
>>
>>
>



-- 
Regards,
Peter Manev