<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Performance on To Linux and beyond !</title>
    <link>https://home.regit.org/tags/performance/</link>
    <description>Recent content in Performance on To Linux and beyond !</description>
    <generator>Hugo</generator>
    <language>fr</language>
    <lastBuildDate>Mon, 18 Nov 2013 12:59:59 +0000</lastBuildDate>
    <atom:link href="https://home.regit.org/feed/tags/performance/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Using linux perf tools for Suricata performance analysis</title>
      <link>https://home.regit.org/2013/11/using-linux-perf-tools-for-suricata-performance-analysis/</link>
      <pubDate>Mon, 18 Nov 2013 12:59:59 +0000</pubDate>
      <guid>https://home.regit.org/2013/11/using-linux-perf-tools-for-suricata-performance-analysis/</guid>
      <description>&lt;h4 id=&#34;introduction&#34;&gt;Introduction&lt;/h4&gt;
&lt;p&gt;&lt;a href=&#34;https://perf.wiki.kernel.org/index.php/Main_Page&#34;&gt;Perf&lt;/a&gt; is a great tool to analyse performances on Linux boxes. For example, &lt;em&gt;perf top&lt;/em&gt; will give you this type of output on a box running &lt;a href=&#34;http://suricata-ids.org/&#34;&gt;Suricata&lt;/a&gt; on a high speed network:&lt;/p&gt;
&lt;pre&gt;Events: 32K cycles                                                                                                                                                                                                                            
 28.41%  suricata            [.] SCACSearch
 19.86%  libc-2.15.so        [.] tolower
 17.83%  suricata            [.] SigMatchSignaturesBuildMatchArray
  6.11%  suricata            [.] SigMatchSignaturesBuildMatchArrayAddSignature
  2.06%  suricata            [.] tolower@plt
  1.70%  libpthread-2.15.so  [.] pthread_mutex_trylock
  1.17%  suricata            [.] StreamTcpGetFlowState
  1.10%  libc-2.15.so        [.] __memcpy_ssse3_back
  0.90%  libpthread-2.15.so  [.] pthread_mutex_lock&lt;/pre&gt;
&lt;p&gt;The functions are sorted by CPU consumption. Using arrow key it is possible to jump into the annotated code to see where most CPU cycles are used.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Suricata, to 10Gbps and beyond</title>
      <link>https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/</link>
      <pubDate>Mon, 30 Jul 2012 21:03:19 +0000</pubDate>
      <guid>https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/</guid>
      <description>&lt;h4 id=&#34;introduction&#34;&gt;Introduction&lt;/h4&gt;
&lt;p&gt;Since the beginning of July 2012, OISF team is able to access to a server where one interface is receiving&lt;br&gt;
some mirrored real European traffic. When reading &amp;ldquo;some&amp;rdquo;, think between 5Gbps and 9.5Gbps&lt;br&gt;
constant traffic. With that traffic, this is around 1Mpps to 1.5M packet per seconds we have to study.&lt;/p&gt;
&lt;p&gt;The box itself is a standard server with the following characteristics:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CPU: One Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (16 cores counting Hyperthreading)&lt;/li&gt;
&lt;li&gt;Memory: 32Go&lt;/li&gt;
&lt;li&gt;capture NIC: Intel 82599EB 10-Gigabit SFI/SFP+&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The objective is simple: be able to run Suricata on this box and treat the whole&lt;br&gt;
traffic with a decent number of rules. With the constraint not to use any non&lt;br&gt;
official system code (plain system and kernel if we omit a driver).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using AF_PACKET zero copy mode in Suricata</title>
      <link>https://home.regit.org/2012/02/using-af_packet-zero-copy-mode-in-suricata/</link>
      <pubDate>Thu, 23 Feb 2012 18:25:15 +0000</pubDate>
      <guid>https://home.regit.org/2012/02/using-af_packet-zero-copy-mode-in-suricata/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.inliniac.net/blog/&#34;&gt;Victor Julien&lt;/a&gt; has &lt;a href=&#34;http://lists.openinfosecfoundation.org/pipermail/oisf-devel/2012-February/001283.html&#34;&gt;just pushed&lt;/a&gt; a new feature to &lt;a href=&#34;https://redmine.openinfosecfoundation.org/projects/suricata/repository&#34;&gt;suricata’s git tree&lt;/a&gt;. It brings improvements to the AF_PACKET capture mode.&lt;/p&gt;
&lt;p&gt;This capture mode can be used on Linux. It is the native way to capture packet. Suricata is able to use the interesting new multithreading feature provided by AF_PACKET on recent kernels: it is possible to have multiple capture threads receiving the packet of a single interface.&lt;/p&gt;
&lt;p&gt;The commits add mmaped ring buffer support to AF_PACKET capture and also provide a zero copy mode. Mmaped ring buffer is mechanism similar to the one used by PF_RING. The kernel allocates some memory to store the packets and share this memory with the capture process. Instead of sending messages, the kernel just write to the shared memory and the process capture reads it. This is less consuming in term of CPU ressource and helps to increase the capture rate. But the main avantage of this technique is that the capture process can treat the packets without making a copy and this saves a lot of time&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
