I'm using MySQL 4.1.14 Standard. This is the default v2 table schema. I will try to downgrade and see if it makes any difference. Here is the full config: --begin-- debug: false daemonize: false plugins: mysql[inbound], mysql[outbound] aggregate[inbound]: tag,dst_host aggregate[outbound]: tag,src_host aggregate_filter[inbound]: dst net 209.97.32.0/20 and src net not 209.97.32.0/20 aggregate_filter[outbound]: src net 209.97.32.0/20 and dst net not 209.97.32.0/20 interface: eth0 interface_wait: true promisc: true syslog: local0 networks_file: /app/pmCollector/etc/networks.lst sql_host: <snip> sql_user: <snip> sql_passwd: <snip> sql_db: pmacct sql_table: acct_v2 sql_table_version: 2 sql_refresh_time: 300 sql_optimize_clauses: true sql_history: 5m sql_history_roundoff: m sql_dont_try_update: true sql_recovery_logfile: /app/pmacct-0.8.2/var/log/recover post_tag: 1 sampling_rate: 1 --end--
Thanks,
Dave
On Wed, 2005-10-26 at 02:42 +0200, Paolo Lucente wrote:
Hello Dave, On Tue, Oct 25, 2005 at 05:26:33PM -0400, David C. Maple wrote: > We are using pmacctd to collect throughput in and out of our IPs. The data is > aggregated into 5 minute periods. The first FULL 5 minute period is about > right: 5.6mb out, 400kb in. The rest of the periods are up to 100 times the > first. I've tried different configurations and included the relevant parts > of the latest here. (I left out the database name and username/password stuff.) I've compiled pmacct 0.9.3 with the --enable-mysql and --enable-64bit options on a Fedora Core 3 and a RedHat 9. Both run a MySQL 4.0.14 standard. I've tested your fragment of configuration (successfully) while backgrounding a download of a 650Mb ISO from a RedHat server (with an almost constant transfer rate around 1.5Mbit/s): mysql> select ip_src, ip_dst, stamp_inserted, stamp_updated, (bytes*8)/300 from acct_v4 where ip_src='150.145.84.133' or ip_dst='150.145.84.133'; ----------------+----------------+---------------------+---------------------+---------------+ | ip_src | ip_dst | stamp_inserted | stamp_updated | (bytes*8)/300 | +----------------+----------------+---------------------+---------------------+---------------+ | | 150.145.84.133 | 2005-10-26 02:10:00 | 2005-10-26 02:15:01 | 324629.04 | | 150.145.84.133 | | 2005-10-26 02:10:00 | 2005-10-26 02:15:01 | 9868.64 | | | 150.145.84.133 | 2005-10-26 02:15:00 | 2005-10-26 02:20:01 | 1667962.88 | | 150.145.84.133 | | 2005-10-26 02:15:00 | 2005-10-26 02:20:01 | 33202.13 | | | 150.145.84.133 | 2005-10-26 02:20:00 | 2005-10-26 02:25:01 | 1483734.61 | | 150.145.84.133 | | 2005-10-26 02:20:00 | 2005-10-26 02:25:01 | 29866.13 | | | 150.145.84.133 | 2005-10-26 02:25:00 | 2005-10-26 02:30:01 | 1574592.00 | | 150.145.84.133 | | 2005-10-26 02:25:00 | 2005-10-26 02:30:01 | 31127.57 | | | 150.145.84.133 | 2005-10-26 02:30:00 | 2005-10-26 02:35:01 | 1889721.60 | | 150.145.84.133 | | 2005-10-26 02:30:00 | 2005-10-26 02:35:01 | 36796.69 | | | 150.145.84.133 | 2005-10-26 02:35:00 | 2005-10-26 02:40:01 | 1658758.93 | | 150.145.84.133 | | 2005-10-26 02:35:00 | 2005-10-26 02:40:01 | 32058.56 | +----------------+----------------+---------------------+---------------------+---------------+ In the end, i'm able to compare the size reported by pmacct with the partial size effectively downloaded on the disk. I'll leave it testing for the rest of the file just to see how things get evolved (and will let you know). Few questions for you: did you use the default (v2) table schema ? Are you sure you have included all relevant parts of your configuration in the previous post (eg. any 'sql_preprocess' line) ? If you try to downgrade to 0.9.2 or 0.9.1, are you still able to notice such odd behaviour ? Which version of MySQL server are you actually running ? Is the server running a plain (SMP) x86 architecture ? Cheers, Paolo _______________________________________________ pmacct-discussion mailing list [email protected] http://muffin.area.ba.cnr.it/mailman/listinfo/pmacct-discussion
