Re: [Sguil-users] compressing pcap packet data and/or mysql merge tables
Status: Beta
Brought to you by:
bamm
From: Barry G. <mai...@pe...> - 2008-08-01 17:19:09
|
> Barry Gould wrote: >> Hi, >> >> Which merge tables are safe to compress in sguil? >> e.g., if I try to change the category of an old event, or add a comment, >> which tables are updated? Just 'history'? >> > > This is just a guess, since I never tried using table compression, but > I'd say you'd be pretty safe in compressing sancp, data, tcphdr, iphdr, > udphdr. Both event and history can be updated at any time the analyst > chooses, but you cannot change the packet header or payload information > through the Sguil interface, so those will never be updated again. Ditto > for the sancp table. OK... I actually compressed the event merge tables too, but I _think_ the history table is the only one that gets updated when an event is changed. I'll do some more testing. >> FYIs, I've just run the MySQL table compression commands on my July >> sguil >> tables... >> before the compression, >> I had 7.3GB in /var/lib/mysql; >> afterwards, 3.4GB. >> > > Have you tried any performance benchmarking? Honestly, the storage space > isn't as much of an issue as performance for most people, and I'm > curious to know if the compression is slower (more CPU) or faster (less > disk I/O). Nothing formal... queries still seem to take about the same amount of time. >> I also had to restart the mysql daemon afterwards as it was getting >> index >> errors on queries. >> >> Restarting mysql seems to tick off sguild, so I have to restart it too, >> Is that normal? >> > > Yes. Sguild doesn't like it when MySQL goes away. It's probably > something > we could handle a lot more gracefully, at least trying to reconnect or > something. I also found that barnyard was crashed; had to restart it too. Thanks, Barry |