Hi Andrey,


On Fri, Mar 02, 2018 at 02:06:30PM +0200, Andrey Koblyuk wrote:

> 1) sql_startup_delay does not work for me . I would like to postpone the 
> first data processing/cache purging before BGP peering is up. otherwise the 
> table contains data without information from BGP daemon.

Correlation happens when flow data is received - not upon purge. So
simply delaying the purge is not going to benefit. I wonder, is it such
a big deal though? How often are you restarting the collector and why?

> 2) is it possible to rotate tables, for example, once a week, simply by 
> creating a new one with a new name (example all_traffic_%m) ? In this case, 
> no aggregation should occur - therefore the parameters are not suitable
> sql_history: 1h
> sql_history_roundoff: h
> sql_table: acct_v4_%w
> for me if I correctly understood their purpose.

Please elaborate more. 'sql_table: acct_v4_%w' should achieve you the
rotation behaviour you desire. I loose you on the aggregation point you

> 3) I also noticed a "strange" delay between "Purging cache - END" and psql 
> "select * from all_traffic;". about a minute.. O_O this is a question for 
> nfacctd or postgresql?

I'd definitely need more info on this as it's too generic description.
If you suspect a bug and can provide more info, please follow-up by
unicast email.

> 4) Interested in your recommendations  - what parameters should be changed 
> with a large flow of ipfix data, taking into account the fact that I plan to 
> add plug-ins for aggregating this data to the existing pgsql[storage].

Mainly buffers (ie. plugin_pipe_szie, plugin_buffer_size or as an
alternative plugin_pipe_zmq along with plugin_pipe_zmq_profile) and, 
depending on your aggregation method, the amount of cache entries (ie.
sql_cache_entries). On the buffering part you can read the following:



pmacct-discussion mailing list

Reply via email to