On 2012-06-20 1126, Paolo Lucente wrote: > Hi Tiernan, > > On Tue, Jun 12, 2012 at 05:18:36PM +1000, Tiernan Messmer wrote: > >> If you think the exact filter may be contributing, I can send those >> privately if you'd like. On an unrelated note, is it possible to filter >> based on traffic direction in/out of an interface rather than relying on >> matching based on network? May simplify the filters slightly if that's >> what the bottleneck is. > > Yes, long filters can be the culprit - can you experiment ie. removing > filters (and optionally defining 'none' aggregation method to plugins) ?
Removing the filters reduced cpu usage to below 1%, I'd say we've found a cause. Is there a more efficient way of defining filters? At present the filters are used to categorise if it's traffic going in or out by matching dst/src to be a local address (checks if it matches one public IPv4 address, one private range IP net, or one public IPv6 net) for in/out respectively and matching if it's 'free' traffic or not by matching if it's talking to a machine mentioned here: https://customer-webtools-api.internode.on.net/unmetered_ip_address_list.txt aggregate_filter[in]: dst net 10.190.38.0/24 or dst net 2001:range::/56 or dst host publicip or dst host 10.190.205.38 and src net not 10.190.38.0/24 and src net not 2001:range::/56 and not (net <ip> and net <ip> ...) For the infree filter it would be the same except without the last 'not' just before the open bracket and out is the same, except with dst replaced with src. Is there a more efficient way of doing this? > Given your capturing framework, can you rely on MAC addresses to simplify > the filtering? libpcap does not provide an indication of direction of the > traffic. Unfortunately not, it is on a PPPoE interface, so no MACs. > Cheers, > Paolo Cheers, Tiernan _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
