<br>I might have eliminated the disk from the picture.  I realized that I have a 12GB ram disk at /dev/shm so I copied my 6GB pcap file and ran it from there.  The thought was that if I was reading the pcap from RAM and not disk I could eliminate the disk IO issue.  Well it took Suricata 170 sec to process the file.  Recall it took 170 sec when it was reading from disk too.  So unless I'm wrong about /dev/shm being a RAM disk (which is not unlikely) it looks like my bottleneck is not the disk IO.<br>
<br>Gene<br><br><br><div class="gmail_quote">On Tue, Aug 2, 2011 at 9:33 PM, Dave Remien <span dir="ltr"><<a href="mailto:dave.remien@gmail.com">dave.remien@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Gene,<div><br></div><div>How much memory is in your new box? You can test how fast the disk can deliver the 6GB file by dumping the caches (sysctl -w  vm.drop_caches=3) then </div><div><br></div><div> time dd if=file of=/dev/null bs=128k</div>

<div><br></div><div>(among many other possibilities).  I've seen the same thing (suricata performance flattening out on boxes with many CPUs). Your I/O should be much faster than suricata can run though a pcap (I typically benchmark on boxes with RAID controllers that can run 400-500MBytes/sec) to make sure that I'm not benchmarking the disk. I also use large pcaps (750GB has been a useful size). Suricata has tuning parameters for the threading operation; I'd recommend reading up on 'em (Will? Wanna jump in here, since Victor's on vacation?).</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Dave<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Tue, Aug 2, 2011 at 9:20 PM, Gene Albin <span dir="ltr"><<a href="mailto:gene.albin@gmail.com" target="_blank">gene.albin@gmail.com</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">So I just installed Suricata on one of our research computers with lots of cores available.  I'm looking to see what kind of performance boost I get as I bump up the CPU's. After my first run I was surprised to see that I didn't get much of a boost when going from 8 to 32 CPUs.  I was running a 6GB pcap file with a about 17k rules loaded.  The first run on 8 cores took 190sec.  The second run on 32 cores took 170 sec.  Looks like something other than CPU is the bottle neck.  <br>


<br>My first guess is Disk IO.  Any recommendations on how I could check/verify that guess?<br><br>Gene<br><font color="#888888"><br>-- <br>Gene Albin<br><a href="mailto:gene.albin@gmail.com" target="_blank">gene.albin@gmail.com</a><br>

<br>
</font><br></div></div>_______________________________________________<br>
Oisf-users mailing list<br>
<a href="mailto:Oisf-users@openinfosecfoundation.org" target="_blank">Oisf-users@openinfosecfoundation.org</a><br>
<a href="http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>"Of course, someone who knows more about this will correct me if I'm<br>wrong, and someone who knows less will correct me if I'm right." <br>David Palmer (<a href="mailto:palmer@tybalt.caltech.edu" target="_blank">palmer@tybalt.caltech.edu</a>)<br>

<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Gene Albin<br><a href="mailto:gene.albin@gmail.com" target="_blank">gene.albin@gmail.com</a><br><br>