<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 10/20/2010 04:16 PM, Michael Altizer wrote:
    <blockquote cite="mid:4CBF4E1A.4090702@...1935..." type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      On 10/20/2010 03:14 PM, Michael Altizer wrote:
      <blockquote cite="mid:4CBF3F86.6060805@...1935..." type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        On 10/20/2010 02:59 PM, Rich Graves wrote:
        <blockquote
          cite="mid:AANLkTi=z8COMh8GNSkvVX5kizricFaJU2i2aFHL9ACDg@...11828..."
          type="cite">On Wed, Oct 20, 2010 at 1:12 PM, Jeff Kell<span
            dir="ltr"></span> wrote:<br>
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;"> <br>
              I had rebuilt snort 2.8.6 with libpcap 1.1.1 and  had some
              worse performance than before, but then there was a
              discussion on one of the snort lists regarding sids 4676
              and 4677 in the oracle-rules being a pcre "hog".<br>
              <br>
              Disabling those two sids dropped my average CPU over
              half...<br>
            </blockquote>
            <div><br>
              Wow. Mine dropped over 2/3. <br>
              <br>
              sid 4676 is limited to POSTs, so if you have a requirement
              to detect ancient oracle attacks, keep that one and drop
              just 4677.<br>
              <br>
              The problem of the maximum 49MB buffer on RHEL5 64-bit
              remains (does not affect Ubuntu 64-bit or RHEL5 32-bit;
              I'd expect it to effect CentOS and other rebuilds as
              well), but since I'm no longer regularly filling the
              buffer, my 2.9.0 installation is now stable enough that I
              can start looking at the new rule options, and hope the
              buffer issue gets addressed in 2.9.1.<br>
            </div>
          </div>
          <br>
        </blockquote>
        I've replicated the issue on a 64-bit CentOS 5.5 VM.  It's going
        to take some investigation from the kernel side of af_packet to
        figure out the issue since it appears to be limited to 64-bit
        CentOS/RHEL as you indicated.  Unfortunately, they really don't
        make building a custom kernel with their source easy, but I'm
        getting there...<br>
        <br>
        -Michael<br>
      </blockquote>
      The problem is that we're running into the old kmalloc limit of
      128k on the 2.6.18 kernel supplied with RHEL5/CentOS5.  The
      difference between 49mb and 50mb is the difference between 16218
      blocks and 16549 blocks, which the kernel attempts to kmalloc a
      pointer array for to keep track of the allocated pages.  On a
      64-bit system:<br>
      16218 * sizeof(char *) = 129744 (< 128k)<br>
      16549 * sizeof(char *) = 132392 (> 128k)<br>
      <br>
      The Linux kernel started defaulting to supporting kmallocs of
      significantly larger sizes (2mb) in 2.6.22.  See the AFPacket
      section of the DAQ README if you're curious as to the math
      involved with determining the number of blocks (pages) requested.<br>
      <br>
      There are a few avenues that can be explored:<br>
      1. Change the AFPacket DAQ module to attempt to use initially use
      multi-page blocks and scale back the block size on subsequent
      allocation failures.<br>
      2. Upgrade your kernel to something a bit more recent (2.6.22 came
      out almost 3 and a half years ago).<br>
      3. Change the af_packet.c on your RHEL kernel to use vmalloc
      instead of kmalloc for the page vector and recompile, but that
      will have an unknown impact on performance.<br>
      <br>
      I'll start looking into option 1 (probably the best option
      overall) when I get some time.<br>
      <br>
      -Michael<br>
    </blockquote>
    I've attached an updated version of my previous patch which
    incorporates item 1.  I've tested it on CentOS 5.5 (where the
    problem was reproduced and debugged) and have not had any issues.<br>
    <br>
    -Michael<br>
  </body>
</html>