The high cpu usage issue that appeared in V7 and it _still_ present in 7.2 is causing a good few problems for users.
Here's how I'm handling it until Astaro fix it or I replace Astaro with something else.
I should point out that I know my way around astaro and linux and it took a considered examination of the problem and the system to discover all of this.
The purpose of this is to share my experience so that it'll keep you CPU under control.
IMHO it's part of the reporting process that is the culprit, specifically the scripts that update the database tables that the "pretty" reports are generated from.
Initially, as there isn't very much data, the tables update quickly but as the database grows, it takes longer and the cpu time creeps up.
Probably because the database becomes I/O bound (a classic symptom of high cpu on a db system)
One post suggested commenting out the relevant line in
/etc/syslog-ng.conf.template
this didn't work out well for me. It didn't stop the processes from starting and a restart of syslogng bitched about unresolved entries and became flaky.
I changed my attention from killing pfilter-reporter.pl to preventing the db update from happening at all.
So, in /usr/local/bin/reportcontrol.sh I commented out pfilter-report.pl - this stopped that process from chewing cpu, only to be replaced by admin-reporter.pl :-/
I then commented reportcontrol.sh like this :
(with line numbers & this shows only the lines I commented)
22 #admin-reporter.pl
23 #ips-reporter.pl
24 #mailsec-reporter.pl
25 #pfilter-reporter.pl
26 #vpn-reporter.pl
27 #websec-reporter.pl
This almost did it.. but every 15 minutes gen_inline_reporting_data.pl runs and shows the same symptoms. This is called from 2 places in cron, namely
/etc/crontab and /etc/crontab.reporting - I commented these out and I've had normal cpu usage for 24 hours. (No reports obviously but I've got logfiles..)
What does this mean then ? FWIW here's my summary:
Firstly, I tested this with 2 different 220's with different V7 releases and was able to replicate the issue across both boxes and at every sw revision.
This led me to think it was a hardware scaling issue. In my setup I was genning traffic both ways on a 10 mbit pipe while causing plenty of violations in the packet filter and ips.
I also ran some vpn tunnels.
All of the UTM (mail, web etc.. I've never rated that stuff much in astaro anyway) was off.
I was genning approx 400 packets per second. This is probably more than you'd see on your average LAN but I was pushing this stuff deliberately to test the tin and to get lot's of data into the reports.
I know astaro well - a 220 should _absolutely_ be able to cope with this.
I briefly wondered whether some creative scaling had crept in with V7 - forcing upgrades for everybody that's been getting better performance out of a 220 than they should.
I don't credit Astaro with level of organisation and joined up thinking these days - more Jerry Lewis than Steve Jobs - so I dropped the conspiracy theory and got back to it.
I grabbed a big box with a beast of a cpu and 4gb - a box made by nexcom - www.nexcom.com.tw (do they look familiar?).
I used the software version of astaro - which isn't quite the same but for my purposes it's close enough. (Friendly partner helped with demo keys)
Guess what - exactly the same! Upscaling the hardware makes a slight difference but the issue is still there.
In summary, if you are on a small LAN your not likely to be affected but if you have a bit of traffic, say a 2mbit pipe and some deflected traffic then you will see high cpu load.
I reckon you'd see it on all but the biggest of boxes. DO anything like http proxy or IM and you _are_ going to see high cpu usage. Like wise if you get scanned or attacked - if you get more than a little data to be written in to reports.
Caveats :
This will temporarily solve the problem but you will lose your reports (not your logs)
If in doubt about this then don't attempt the changes.
This worked for me, it might not work for you.
Don't blame me if you bork your box.
Backup.
This WILL invalidate your support. (rightly)
Astaro:
This is a DOS risk, ther's no excuse for this.
I have seen others affected by this over the years - they admitted it and eventually fixed it, get a grip.
If you want management reports, offload it into a "management server" like an improved ARM. That's what everybody else does.
Enterprise customers will buy it anyway. Everybody else will downgrade their expectations.
It is not good enough that support can't even find this let alone acknowledge it.
I've seen cheapo webhosters that outsource tickets with better support than this. You should be embarrased.
-Bingo
This thread was automatically locked due to age.