Hi Paolo Using '-l' didn't seem to make a difference. Here's a sample of the zeros I'm getting right now. It's 37 entries out of around 16000.
Thanks! Ty IN_IFACE SRC_IP PACKETS BYTES 578 0 103 94643 570 0 107 11102 684 0 132 130725 612 0 14 1925 682 0 15056 1989976 660 0 155 22052 583 0 1 64 586 0 1 72 579 0 176 19879 557 0 1844 408425 693 0 186 10732 601 0 1 94 558 0 194 104518 671 0 2 128 668 0 26372 15966015 563 0 28 1989 568 0 3 184 561 0 38 2288 669 0 39 15463 659 0 4119 3665486 569 0 42 2768 581 0 433890 149214184 551 0 44888 18523992 501 0 46 8521 672 0 519 555902 600 0 51 9872 609 0 52 10036 565 0 52 3919 584 0 5 312 683 0 57 3539 610 0 6 291 670 0 63794 25129504 571 0 70416 20213140 687 0 7 280 587 0 90683 47095634 607 0 91410 63346242 661 0 9 1556 Re: [pmacct-discussion] nfacctd random zero aggregates Paolo Lucente Sat, 17 Mar 2012 06:09:39 -0700 Hi Ty, I wonder if it could be locking is necessary when reading from the memory table due to the sustained amount of inserts in your deployment. Can you try to append to your pmacct client command line a '-l' - and see if it makes any difference? Let me know. Cheers, Paolo On Fri, Mar 16, 2012 at 05:37:04PM -0400, Ty Bell wrote: > Hi all, > > I'm running into an issue with nfacctd where random aggregate information > will be zero (specifically src and dst as, mask and net). Clearing the > statistics a few minutes after starting nfacctd only temporarily eliminates > the zeros. The zero entries are most obvious when using multiple aggregates, > but for testing purposes I've been using one aggregate at a time to see if it > was an issue with multiples. src_host, dst_host, src_port, dst_port, > in_iface, and out_iface all appear to be unaffected and always contain data > even when as mask and net do not. > > When using src_as, src_net and src_mask together, all fields would randomly > be zero. I ran tcpdump and I've been able to correlate the flows and verify > that as mask and net are all being received by the host, but are for some > reason not making it to the memory tables. > > I'm getting the following in the nfacctd.log, is this just a case of needing > additional memory (only 512MB on the host)? I briefly experimented setting > imt_mem_pools_number: 0 which drastically increased the number of records but > still did not eliminate the zero entry. > Mar 16 21:22:17 WARN ( in/memory ): Unable to allocate more memory pools, > clear stats manually! > > > Any input would be appreciated, my config is below. > > Thank you, > Ty Bell > > ---nfacctd config--- > > daemonize: true > pidfile: /var/run/nfacctd.pid > logfile: /usr/local/etc/nfacctd.log > nfacctd_disable_checks: true > nfacctd_ip: 140.182.44.155 > nfacctd_port: 2100 > nfacctd_as_new: bgp > nfacctd_net: bgp > > plugin_pipe_size: 10240000 > plugin_buffer_size: 10240 > > bgp_daemon: true > bgp_daemon_ip: 140.182.44.155 > bgp_daemon_max_peers: 10 > bgp_aspath_radius: 10 > bgp_follow_default: 10 > bgp_peer_src_as_type: bgp > !bgp_daemon_msglog: true > bgp_agent_map: /usr/local/etc/bgp_agent.map > > plugins: memory[in] > !, memory[out] > aggregate[in]: src_net > imt_path[in]: /tmp/nfacct_in.pipe > !aggregate[out]: dst_net, dst_mask, out_iface > !imt_path[out]: /tmp/nfacct_out.pipe > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
