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
> 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