<div dir="ltr"><div>It is not always the Detect1 thread, though it was in that case.  As I write this, my Detect6 thread has been running at 100% CPU utilization for about 30 minutes while the other 7 threads are between 0% and 5% -- no dropped packets reported though.  I decreased my stream.reassembly.depth from 4mb to 2mb and have seen a drop in the frequency of Detect threads hitting 100% utilization (though my tcp.stream_depth_reached has increased, as expected I guess).</div>
<div><br></div><div>Now that I decreased the the stream.reassembly.depth, I saw instances of my FlowManagerThread hit 100% CPU utilization, during which time my flow_mgr.*pruned counters stopped increasing for the duration and when FlowManagerThread finished doing whatever it was doing there was a large spike in those counters.  No other counters on the system seemed affected.  I had increased the size of the flow.hash-size to 131072, but have since reverted it to the default as that did not seem to decrease the dropped packets.</div>
<div><br></div><div>Using perf top I still see libhtp (htp_list_array_get) consuming a majority of the event cycles on my system -- close to 20% overall and about 80% of the cycles in the Suricata-Main thread.  Is this something that is specific to my configuration or are others seeing similar libhtp utilization?  Maybe Anoop is on to something?</div>
<div><br></div><div>A couple of perf top screenshots attached.  Thanks!</div><div><br></div><div>stats.log: <a href="http://pastebin.com/13j0DV7E">http://pastebin.com/13j0DV7E</a></div><div>suricata.yaml: <a href="http://pastebin.com/QAib5dYZ">http://pastebin.com/QAib5dYZ</a></div>
<div><br></div><div>-dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 5:31 AM, Victor Julien <span dir="ltr"><<a href="mailto:lists@inliniac.net" target="_blank">lists@inliniac.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/18/2014 04:54 PM, David Vasil wrote:<br>
> I have been trying to track down an issue I am having with Suricata<br>
> dropping packets (seems to be a theme on this list), requiring a restart<br>
> of the daemon to clear the condition.  My environment is not large<br>
> (averge 40-80Mbps traffic, mostly user/http traffic) and I have Suricata<br>
> 2.0.1 running on a base installation of Security Onion 12.04.4 on a Dell<br>
> R610 (12GB RAM, Dual Intel X5570, Broadcom BCM5709 sniffing interface).<br>
><br>
> About once a day, Zabbix shows that I am starting to see a large number<br>
> of capture.kernel_drops and some corresponding tcp.reassembly_gap.<br>
>  Looking at htop, I can see that one of the Detect threads (Detect1 in<br>
> this screenshot) is pegged at 100% utilization.  If I use 'perf top' to<br>
> look at the perf events on the system, I see libhtp consuming a large<br>
> number of the cycles (attached).  Restarting suricata using<br>
> 'nsm_sensor_stop --only-snort-alert' results in child threads exiting,<br>
> but the main suricata process itself never stops (requiring a kill -9).<br>
>  Starting suricata again with 'nsm_sensor_start --only-snort-alert'<br>
> starts up Suricata and shows that we are able to inspect traffic with no<br>
> drops.<br>
><br>
> In the attached screenshots, I am only inspecting ~2k packets/sec<br>
> ~16Mbit/s when Suricata started dropping packets.  As I write this,<br>
> Suricata is processing ~7k packets/sec and ~40Mbit/s with no drops.  I<br>
> could not see anything that I can directly correlate to the drops and<br>
> the various tuning steps I have taken have not helped alleviate the<br>
> issue, so I was hoping to leverage the community's wisdom.<br>
><br>
> Some observations I had:<br>
><br>
> - Bro (running on the same system, on the same interface) drops 0%<br>
> packets without issue all day<br>
> - When I start seeing capture.kernel_drops, I also begin seeing an<br>
> uptick in flow_mgr.new_pruned and tcp.reassembly_gap, changing the<br>
> associated memcaps of each has not seemed to help<br>
> - tcp.reassembly_memuse jumps to a peak of around 2.66G even though my<br>
> reassembly memcap is set to 2gb<br>
> - http.memcap is set to 256mb in my config and logfile, but the<br>
> stats.log show http.memcap = 0 (bug?)<br>
<br>
</div></div>When this happens, do you see a peak in syn/synack and flow manager<br>
pruned stats each time?<br>
<br>
The current flow timeout code has a weakness. When it injects fake<br>
packets into the engine to do some final processing, it currently only<br>
injects into Detect1. You might be seeing this here.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<br>
<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
OISF: <a href="http://www.openinfosecfoundation.org/" target="_blank">http://www.openinfosecfoundation.org/</a><br>
</font></span></blockquote></div><br></div>