On Tue 12 Jun 2007, Ruben Laban wrote: > On Tuesday 12 June 2007, Ruben Laban wrote: > > On Monday 11 June 2007, Paolo Lucente wrote: > > > On Fri, Jun 08, 2007 at 01:12:22PM +0200, Ruben Laban wrote: > > > > On a more detailed side (and I admit I'm still reading the docs), I > > > > am wondering about some specific configuration issues. The memory > > > > size of various pools/buffers/etc in particular. One location has an > > > > 100Mbit/s uplink and the other 1Gbit/s uplink which is currently > > > > throttled to about 150-200Mbit/s. I don't have any actual numbers of > > > > packets/s, but only bytes/s and the fact that most traffic is HTTP. > > > > The average usage of both lines fluctuates between 20-40 Mbit/s with > > > > peaks upto 150Mbit/s for one location. > > > > > > > > Related to the above is also the performance of pmacct and the load > > > > it imposes on the machine. The firewalls in question are Dell PE860 > > > > machines with dual core Xeon's at 3GHz, 1 or 2GB of ram and running > > > > Suse Linux Enterprise Server 9. > > > > > > I see your boxes are pretty beefy, you should not encounter issues of > > > any sort with it. If you are going the promiscuous mode way, would > > > suggest you to take a close look to Q5 of FAQS document - which > > > encompasses some tips both about bufferization and how you can > > > optimize CPU usage while getting packets off the wire > > > PF_RING/libpcap-mmap/etc. > > > > I will be using it inline (monitoring will be done on our border > > firewalls), but concerning memory/cpu load I doubt that that would make > > much of a difference. I'll take another look at the sections concerning > > the buffering, though last time I had some troubles translating the > > various tips to actual numbers suited for our scenario. Then again, I > > guess it pretty much always will require a bit trial and error to find > > the optimal settings. > > I did a little bit of testing just now. I noticed that with the default > buffer settings that the load was higher than I had expected (taken from > 'top'): > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 21300 root 15 0 28808 6160 5664 S 9.3 0.3 55:23.08 pmacctd: Core > Process [default] > 21302 root 15 0 34752 11m 10m S 2.3 0.6 20:01.15 pmacctd: IMT > Plugin [out] > 21301 root 15 0 34752 11m 10m S 1.7 0.6 14:12.08 pmacctd: IMT > Plugin [in] > > After changing the buffer settings to 10240 / 10240000, the load > drastically reduced: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 1332 root 15 0 44712 21m 21m S 1.7 1.1 0:19.97 pmacctd: Core > Process [default] > 1333 root 15 0 42704 19m 18m S 0.0 1.0 0:00.70 pmacctd: IMT > Plugin [in] > 1334 root 15 0 42704 19m 18m S 0.3 1.0 0:01.00 pmacctd: IMT > Plugin [out] > > These numbers are with a load of about 12MB/s, which isn't all that much. > Especially since we're expecting to see load of more than 10 times this > ammount occasionally. > > I am still researching further optimizations. PF_RING sounds promising but > since it requires a kernel rebuild I'd very much like to avoid that road. > Being able to run stock SuSE kernels surely has my preference. Using > libpcap-mmap seems to be way to go. I'll have to investigate how I can > install this version of libpcap alongside the 'normal' libpcap and have > only pmacctd use it (again to stay as close as possible to a clean SuSE > install).
Hi Ruben I maintain the pmacct packages for SUSE (and some other distros) and run pmacct myself in production on SLES10. I would be happy to assist you in building (if possible) libpcap-mmap packages for SUSE. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
