Hi Karl, On Sat, Jun 13, 2009 at 03:03:04PM -0500, Karl O. Pinc wrote:
> What really is the constrained resource here? Is it the number > of transactions the database supports or is it something more > fundamental to the pmacct performance like cpu or memory > constraints? What I'm thinking is that past a certain > point having the system do more work to detect that it's > under load becomes counter-productive. Is that why > you've not implemented such a feature for the in-memory > tables or is it simply because it's up to the pmacct > command to determine sample frequency? > > Just curious. The constrained resource is the SQL database; not pmacct itself, the cache size, either CPU or memory usage. This is because the database performance is sensitive to rate of insertion, number of tuples, index performance, etc. A fundmental difference between the two backends is that the SQL database is conceived to keep historical data (by featuring timestamps) whereas memory tables typical usage sees them being saved somewhere persistently (RRD files, fed into 3rd party scripts/applications, etc.) and being wiped out at regular intervals. That is why such a thing was not really implemented for in-memory tables: after understanding the footprint of the memory table in, say, a lab environment, it's not a great deal to keep it healthy: it simply keeps working smoothly as long as the hashing algorithm is able to disperse data through the available buckets. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
