On Mon 05 Jun 2006 17:39, Wim Kerkhoff wrote: > Peter Nixon wrote: > > As you can see the machine is not waiting on disk, but rather on the > > locks. Before I go about trying to optimise this any further, is there > > something basic I have wrong that can speed this up? > > The configuration looks fine. It seems like there's no indexes or > something, causing the UPDATEs to take forever.
Yep. I am optimizing the indexes as we speak. I now have the following indexes on both tables, and it has made a significant difference to system load. "acct_combo" btree (stamp_inserted, vlan, ip_src, ip_dst, port_src, port_dst) "acct_datetime" btree (stamp_inserted) "acct_dst" btree (port_dst, ip_dst) "acct_src" btree (port_src, ip_src) I have also deleted all unnecessary fields from the schemas (Mac Address etc). > It could also be that there are a lot of counters. Calculate 500 hosts, > 2 directions, 3 protocols (ICMP/TCP/UDP), server ports (10 ish), client > ports (hundreds), and you could easily be trying to update hundreds of > thousands of records every 10 minutes. Sure. I am aware of the scope of the data. I was just wondering if there were any obvious nfacctd options I should have turned on that I didn't. As I am monitoring a GPRS network and 99% of my clients are HP Ipaqs the port range is fairly limited by the type of applications that can run on an Ipaq :-) > Turn on debug, redirect the output of nfacctd to a file, and watch to > see how many updates are actually being done. Thanks -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
pgp8oJ8pM5Oyt.pgp
Description: PGP signature
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
