Hello Paolo, thank you for the tips, more inline
On 05/10/2013 08:02 AM, Paolo Lucente wrote: > Hi Vito, > > On Thu, May 09, 2013 at 11:36:21AM +0200, [email protected] wrote: > >> So now, my concerns are about multiple connection with the same key that >> I've reduced to >> PRIMARY KEY (vlan, ip_src, ip_dst, src_port, dst_port, ip_proto) >> what happens if two connections with the same key set are opened in the >> same sql_hystory period? > They will be aggregated in a single row, their counters (bytes, packets) > will be summed. Is this the desired behaviour? Otherwise you can disable > temporal aggregation (comment out sql_history) and enable logging, ie. > append timestamp_start, timestamp_end to your 'aggregate' configuration > directive. Interesting, I missed this feature out as I'm actually using the debian packet (version 0.14.0.1) and if I'm right it's was introduces in the last version of your software, specifically 0.14.3. How would this impact on the DB schema, pls can you point me out to a correct usage of these "new" parameters as the use case I need to handle is accounting the start and the end of a flow. Related to this, is there an appropriated way to setup the timeout values for the L4 connections (tcp and udp). >From what I've understood pmacct doesn't have a protocol machine (FSM) to handle the connection states, do it? Should I work with the netflow collector instead? >> From the Wiki page it appears to be that VLAN_ID=0 is a valid value for >> tagged ethernet packet. see >> http://en.wikipedia.org/wiki/IEEE_802.1Q#Frame_format > OK, put on the todo list. Just let me know how much this is important > to you, ie. you actually running into the case of VLAN 0 being used?, > so that i can assign a priority. no, not actually but in my use case it's been expected.. I'm working on a patch, it looks very easy but maybe I've underestimated it > >>>> 6) can you suggest me keys to improve general performances >> [ .. ] >> >> I ment about pmacct config keys, like the ones related to the plugin >> buffer size, etc > I see. Two that i would recommend are: 1) enable sql_multi_values and > 2) enable sql_dont_try_update to prevent using UPDATE queries (which > are expensive). For both i suggest to have a look to CONFIG-KEYS for > more information. > ok, I'll try them >> Last thing, is it possible to write in the DB the timestamp as integer? > Yes. Set sql_history_since_epoch to true. It applies to stamp_inserted > and stamp_updated if sql_history is enabled; and to timestamp_start and > timestamp_end aggregation primitives. in the light of this timestamp_start/end usage can you suggest me a correct aggregation line? thank you and best regards, vito > Cheers, > Paolo > > > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists > > _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
