<div dir="ltr"><div class="gmail_quote"><br><br><div dir="ltr">Of course~  suricata.log in attachment.<div><img src="cid:ii_1468a261488d4420" alt="内嵌图片 2" width="327" height="226"><br></div><div>(It is very nice of you.<span style="color:rgb(0,0,0);font-family:Helvetica,Arial,'Droid Sans',sans-serif;font-size:14px;line-height:19.9999942779541px">( ͡° ͜ʖ ͡°)</span> )</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-11 16:33 GMT+08:00 Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span>:<div><div class="h5">
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Sun, Jun 8, 2014 at 11:01 AM, Christophe Vandeplas<br>
<<a href="mailto:christophe@vandeplas.com" target="_blank">christophe@vandeplas.com</a>> wrote:<br>
> Hi,<br>
><br>
><br>
> What kind of drop do you have?<br>
> - capture.kernel_drops<br>
> - tcp.segment_memcap_drop<br>
> - tcp.ssn_memcap_drop<br>
><br>
> Lower the number of threads in the af-packet section to the number of<br>
> cores your system has. (cat /proc/cpuinfo |  fgrep processor | wc -l )<br>
><br>
> Run suricata with no rules, and tweak the configuration, you should<br>
> have (almost) no packet drop before you activate rules.<br>
><br>
> After having made changes in the yaml configuration file I usually:<br>
> - stop suricata<br>
> - empty the logfiles<br>
> - start suricata<br>
> This way there's no risk of looking at older logs and misinterpreting<br>
> configuration changes.<br>
><br>
><br>
> If possible, link your stats.log to a monitoring tool to greate<br>
> graphs. This way you can correlate packet drops by suricata with other<br>
> events on the system. I've written an article about this :<br>
> <a href="http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html" target="_blank">http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html</a><br>
>  But also other scripts exist.<br>
> Make sure you edit the suricata_stats.py script with the number of<br>
> threads configured in suricata.yaml<br>
><br>
><br>
> If your drops are capture.kernel_drops, then :<br>
> Have you read this article?<br>
> <a href="http://christophe.vandeplas.com/2013/11/suricata-capturekerneldrops-caused-by.html" target="_blank">http://christophe.vandeplas.com/2013/11/suricata-capturekerneldrops-caused-by.html</a><br>
> Please do the first part "Confirmation of the problem" and see if you<br>
> also have the problem caused by the lack of NIC queues.<br>
> In a few words:<br>
> - start suricata<br>
> - as root, run  "top -H" and check how many AFPacketethXX threads are<br>
> generating load.<br>
> - if it's only one thread, then the problem has been pinpointed.<br>
> However working with cluster_flow should solve this problem. Make sure<br>
> you read the rest of the article then.<br>
><br>
><br>
> Kind regards<br>
> Christophe<br>
><br>
><br>
<br>
<br>
</div></div>Can you share your suricata.log as well please?<br>
What is the output of<br>
ethtool -k your_interface<br>
?<br>
</blockquote></div></div></div><br></div>
</div><br></div>