Hi Paolo,
On Fri, 29 Jun 2012, Paolo Lucente wrote:
On Tue, Jun 26, 2012 at 10:13:30AM +0100, Chris Wilson wrote:
OK, testing now. Would it be possible for pmacctd to log a warning if
it exceeds any of these thresholds, to help with tuning without wasting
memory?
In a way you reckon things
Hi Chris,
On Wed, Jul 18, 2012 at 12:45:34PM +0100, Chris Wilson wrote:
Thanks for doing that :) I'm testing the latest CVS now.
OK, keep me posted.
I did notice that restarting the daemon generates these duplicate key
errors. Restarting isn't completely compatible with an always insert
Hi Paolo,
On Wed, 18 Jul 2012, Paolo Lucente wrote:
On an unrelated note, how hard would it be to get the log message from
ULOG stored in the database, for example in the classification field? I
had a look through the code but I couldn't see any way to store this
field from the received
Hi Chris,
On Tue, Jun 26, 2012 at 10:13:30AM +0100, Chris Wilson wrote:
OK, testing now. Would it be possible for pmacctd to log a warning if it
exceeds any of these thresholds, to help with tuning without wasting
memory?
In a way you reckon things go wrong from the process list: the
Hi Paolo,
On Wed, 20 Jun 2012, Paolo Lucente wrote:
I'm thinking to the possibility that given the aggregation method the
SQL cache configured by default is not sufficient to keep all the
aggregates over the time period - although the time period is very
short. Can you as matter of test add
Hi Chris,
I'm thinking to the possibility that given the aggregation method
the SQL cache configured by default is not sufficient to keep all
the aggregates over the time period - although the time period is
very short. Can you as matter of test add the following line to
your config and see if it
Hi all,
We get many of these errors in our system logs:
Jun 12 10:01:01 fen-fw2 pmacctd[2153]: ERROR ( short/mysql ): Duplicate
entry '72.232.223.58-82.68.244.70-80-46802-tcp-2012-06-12 09:56:00' for
key 1
They usually happen in batches. E.g. we had a few hundred at 07:27, then
another few
