[Snort-users] Performance Issues, disk io? SOLVED!
jason.weir at ...14916...
Thu Aug 28 10:50:49 EDT 2014
Looks like it was a filesystem problem.
My older systems were using ext3 and the new test box ext4
Per this thread http://forums.mysql.com/read.php?11,589554,589554 I added the barrier=0 option to /etc/fstab and restarted the system
Just deleted 4000+ alerts in less than 10 seconds.
I may have been able to go back to ext3, I didn't try it, but it was my next step if this didn't work.
Hopefully this will help someone else
From: Weir, Jason [mailto:jason.weir at ...14916...]
Sent: Wednesday, August 27, 2014 2:28 PM
To: snort-users at lists.sourceforge.net
Subject: [Snort-users] Performance Issues, disk io?
I've been updating my docs to use the latest versions of Snort 18.104.22.168, Barnyard2-1.13, Pulled Pork 0.7.0, libpcap 1.6.1, daq 2.0.2 and mysql 5.6.19 on the latest Debian 7.6 version.
Base is stuck on 1.4.5 and libdnet at 1.12 seemingly forever....
Anyways, I've got everything installed and working without error but I seem to have what looks like a huge performance issue centered around disk io on the mysql drive. I have the database on it's own drive with nothing else.
I first noticed it on startup - snort would take 100% cpu for 30 seconds to a minute, the barnyard2 would go 100% for 2-4 minutes, both with almost no disk usage, after that mysql goes 100% for a minute or 2 and the disk %utilization goes to 90%+
After that things seem to settle down and I start seeing events show up in the Base console, cpu and memory usage are minimal, disk usage stays under 20%. I'm on minimal hardware so I'm happy with what I'm seeing.
Now if I go into Base and try to delete events, disk utilization goes to 100% and stays there until the alerts are deleted.
Deleting 100 events just took 30 seconds, and 650 events took 90 seconds where under previous versions it would happen almost instantly.
Any idea where to start?
More information about the Snort-users