Hi Simo, if the problem is with an high volume of data, i think just switching to PostgreSQL would not be the ideal solution. At some stage, it will sink as well. The solution should be in handling meaningfully the data:
- you can "partition" data. pmacct allows you to "partition" data basing over time. It supports dynamic SQL tables (ie. table's name is computed when pmacct is about to purge its data into the DB - thus you can have daily, weekly, mothly tables, etc). It would solve your problem because what kills the engine is the number of rows inside single tables and not the overral number of tuples (in all the tables). You can refer to sql_table_schema directive in CONFIG-KEYS document for an example and further details. - If not required, you can avoid intersections. Ie. if you are aggregating for src_host, dst_host in a single table, you can try to have two tables, one for src_host, the other for dst_host. - you can account data in multiple tables at different "data resolutions". ie. very detailed data go in a table that contains only traffic for last week; then, less detailed data go in another table that has longer life. - If you don't require one month old data, you can start deleting them and keep the table healthy. Hope this helps. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
