13 instances of nacctdreport.pl running

nacctreport.pl reads your network accounting data and creates network accounting reports. Those reporters always work on the log data of a whole day. I'd bet that one reporter could not finish it's work in 24 hours, the next one was started (on the next day's data), slowing the whole process, so this reporter coul d not finish in 24 hours, too. Then, the next one was started, ..., ...
How big are your accounting log files? How fast is your processor?

Hi Andreas,

CPU is PIII 500

/var/log/nacctddata is at 1.9GB

/var/log/nacctddata # du -sh *
1.2G    2004
339M    2005
371M    net-acct
788K    net-acct-dump
0       net-acct-dump.o

The only thing in 2004 is December; I deleted the other stuff a few weeks ago.

Is there a fullyear process that is trying to run?

I was having trouble before with nacctd taking all day to do the accounting reports, but after setting it to the SMALL reports, it usually is done before noon.

BTW, last night it was down to 12 processes, now it's at 14.
ISTM that it should only be running 1 per day.
Also, as I said before, it did finish all the reports through Dec 31, so I don't understand why there would now be 14 processes.

I'd expect it to be trying to finish Dec fullmonth, & Jan 1,2,3,4, so that seems like it should be 5 processes.

Should I kill some/all of the processes? reboot?

The firewall is still otherwise working OK so I can be a little patient, although it does look like it is swapping a lot more than normal.

Code:

---

# free
             total       used       free     shared    buffers     cached
Mem:        256360     248400       7960          0      14336      74088
-/+ buffers/cache:     159976      96384
Swap:      1052248      98788     953460

---

Thanks,
Barry

Hi Barry,
your assumptions are mostly correct, but:
- there is no "yearly" naccdt report (this would be suicide for _many_ machines out there)
- there are three different network accounting report processes:
One process doing the "daily" reports (started at 00:20, working on yesterday's accounting data), one doing the "ThisMonth" reports (started at 02:30, working on all days of this month), and one doing the "LastMonth" report (started at 01:30 at every first of the month, working on the complete last month). 

If the "yesterday" process can not be finished in 24 hours, it is more than likely that the "ThisMonth" process can't be finished in 24 hours, either, which leads to processes stacking up. This often happens when the "yesterday" processes get slowed down by a running "LastMonth" process. Normally, the stack gets worked down as soon as the LastMonth is finished. For most customers this is not a problem, since the reporters run with the lowest possible priority. The downside of this is that they run for a long time and need tons of RAM when stacking up.

You could terminate those processes manually by sending a kill signal, but that would mean that you will not get a report for that day (d'oh). A reboot would terminate all reporters, but in my opinion that would be going over the top. 
If you really want to do something: I'd terminate the "LastMonth" and "ThisMonth" processes first and wait for the reporters to settle down.

Hope that helps,
andreas

I've had to delete Nov & Dec's logs to free up disk space.
I also killed all the nacctdreport.pl processes at that time.

Now, a few days later, I've got 5 nacctdata.pl processes running for THISMONTH, and 2 running for YESTERDAY.

ISTM that if there is a THISMONTH process already running, it shouldn't start more of them.

Also, I haven't had any trouble with accounting since I switched to the SMALL reports a couple months ago.
I haven't changed anything other than upgrading to 5.100, so I'm not sure why it's not working as well now.

My traffic is about the same as always, and I have already throttled traffic as of today to see if that helps.

I will kill all the .pl processes right now (11:30 pm my time), and see what happens again.

Thanks,
Barry

BTW, should I delete 
/var/log/nacctddata/net-acct  (253MB)
or 
/var/log/nacctddata/net-acct-dump  (230KB)
?

Thanks,
Barry

No. These files contain the captured network accounting data for today. The dump file is written regularly and gets appended to the net-acct file. On midnight, it is rotated and renamed to our standard naming scheme, and during the night the nacctdreport script works on them.

As long as you have the network accounting logs, you can always re-create accounting reports (either using our tool manually, or using external accounting tools). If you are sure you don't need them, you can delete the log files, but I'd recommend to do so only after having been processed by the nacctreport script ;-)

Regards,
andreas

[ QUOTE ]

Now, a few days later, I've got 5 nacctdata.pl processes running for THISMONTH, and 2 running for YESTERDAY.


[/ QUOTE ]
It is not a good sign that you already have multpile processes running at the beginning of the month (where the data which has to be processed for THISMONTH is not even half of the data anticipated for the 31.st of this month). As far as I know, there have been no changes in 5.100 which could influence the nacctd reporting in this manner. How big do your accounting log files get on a whole day? 

What you might try to do is to change the priority of the accounting processes by changing the nice level in /usr/local/bin/nacctddispatcher.sh, but be conservative, increase it step by step to not disrupt normal behaviour.

[ QUOTE ]

ISTM that if there is a THISMONTH process already running, it shouldn't start more of them.

[/ QUOTE ]
This would be possible, but before making this change I have to evaluate the drawbacks and consequences. I agree that having an old report is better than having none, but you should at least be able to see that creating the report took more than one day and that it is possibly out-dated.

Cheers,
andreas

Here's my (compressed) log file sizes for this month:
Code:

---

/var/log/nacctddata/2005/01 # ls -sh
total 922M
 76M nacctddata-2005-01-01.log.gz  105M nacctddata-2005-01-07.log.gz
 83M nacctddata-2005-01-02.log.gz  111M nacctddata-2005-01-08.log.gz
 88M nacctddata-2005-01-03.log.gz  116M nacctddata-2005-01-09.log.gz
 92M nacctddata-2005-01-04.log.gz  118M nacctddata-2005-01-10.log.gz
 98M nacctddata-2005-01-05.log.gz   32M nacctddata-2005-01-11.log.gz
7.1M nacctddata-2005-01-06.log.gz

# gunzip -l *.gz
         compressed        uncompressed  ratio uncompressed_name
           78623781           711246015  88.9% nacctddata-2005-01-01.log
           86936140           790762762  89.0% nacctddata-2005-01-02.log
           92180282           838688997  89.0% nacctddata-2005-01-03.log
           96325620           877429221  89.0% nacctddata-2005-01-04.log
          102263930           925346756  88.9% nacctddata-2005-01-05.log
            7368278            66037401  88.8% nacctddata-2005-01-06.log
          109038050           997875650  89.0% nacctddata-2005-01-07.log
          115407335          1060063505  89.1% nacctddata-2005-01-08.log
          120913062          1110863370  89.1% nacctddata-2005-01-09.log
          122798203          1125121946  89.0% nacctddata-2005-01-10.log
           33145492           268670502  87.6% nacctddata-2005-01-11.log
          965000173          8772106125  88.9% (totals)

---

So up to 1.1GB per day.

Thinking about NICE... 
confd, selfmong.pl, nacctd, and alicd are using the most CPU (based on the cumulative TIME+ in TOP). They're all running at priority 0. 
I guess I can try changing the NICE level.

FWIW, as I programmer, one thing I have found in the past with perl scripts is you need to do buffered IO, otherwise it's about 20X slower for large data. Unfortunately, I can't examine nacctdreport.pl as it is binary.

Thanks,
Barry

Hi Barry,
thanks for your thoughts.  Since the nacctdreport program is not one of mine I had to check first, but now I can say for sure that  there is no problem regarding the I/O buffering. I tried a few tricks to improve the performance, but there is not much to do. Most of the time the program works on matching or transforming IP addresses and netmasks, utilizing the Net::Netmask module. We know that on the long run  we need to come up with another solution for this, but we are lacking the time for that. Put the other way: other things were more important since this can be easily avoided by using better hardware. :-)

The only short hand solution would be to either decrease the amount of your log data or to invest in faster hardware; in my opinion, an average of about 900MB of accounting data per day just puts too much strain on a 500 MHz machine (monthly that makes about 27 GB of data with app. 4.9 billion lines, if I calculated that correctly...)

Regards,
andreas

OK, thanks for the feedback.

I was worried about upgrading our production server (PIII 800) to 5.x but now I realize it has a lot less average traffic than I'm doing at home so hopefully it will still be able to do accounting and IPS as well.

Also, I may be getting a Dual PIII for home, so perhaps I will try that, or an Athlon 700 or something like that.

Thanks!
Barry

The fix containing the nacctd directory check and a check  for multiple THISMONTH processes is comitted and scheduled for the next up2date.
Cheers,
andreas

The fix containing the nacctd directory check and a check  for multiple THISMONTH processes is comitted and scheduled for the next up2date.
Cheers,
andreas