Hi Sergio, On Fri, May 14, 2010 at 10:58:00AM -0300, Sergio Charpinel Jr. wrote:
> I couldnt get any useful information from this command. > I get no erros in postgresql, nfacctd and pmacctd log files. I would expect you to see a "Maximum number of SQL writer processes reached" message in the logs. I will do some checks and let you know. > Data is still being written in DB, but I'm suspecting that some are being > lost. Because my database grew just 5G/day after that. If there is some loss due to SQL writers queuing, you should verify some missing time-bins in your dataset. stamp_inserted is the field to check: can you spot any "jumps"? > Why the process are being accumulated just when my database is about 15G? Is > it possible that I'm losing data, even with no errors? Can suggest to verify the basic things, ie. is there enough disk space, can you verify shortage of memory, is CPU running 100%, is any maintenance scripts locking the SQL table up? But i'm pretty sure you have already done all of this. I can essentially see two possible reasons: * this is related to the data-set itself (too large, too complex, etc.); I know you already not make use of UPDATE queries and leverage the COPY statement instead. Can suggest to a) optimize indexing and b) split data in different tables on, say, an hourly basis posed that you are currently doing that more coarse grained, ie. daily/weekly/monthly. The b) should be easy enough to test. * this is strictly related to PostgreSQL. For example, you restart the database (this should drop the writers queued; or indeed you can kill them manually); rename the table currently in use to something else, create an empty table for pmacct to write to and the behaviour persists. In such a case perhaps it's best to turn the issue to a PostgreSQL forum. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
