scheduled reboots

Not that scheduled, regular reboots aren't necessarily a bad idea, but it would be nice to get to the root of your performance issue.

If swap is getting above 20%, it sounds like there is a memory leak somewhere. If you can find out what processes are using up all that memory, it may help Astaro track down the issue. Have you opened a support ticket as well?

We have a variety of customers running various implementation of the Astaro solution; none of them require regular reboots... so getting to the root of the problem is the real solution.  However, to get by while it's being sorted out, try loading ACC on a system, it can be used to schedule reboots.  You could also try adding a reboot job in CRON from the shell.

Thanks for the replies.

I've seen things like loads of traffic to netscape.com due to non-administrative users downloading the new version of FireFox and not being able to do something with it. As well as Skype users doing requests that the Packet Filter doesn't like. Squid is the usual suspect but nothing out of the ordinary so far. The TOP command can be reconfigured to give some insight into swap usage but it's only a moment-in-time thing and I don't have the time to use that as a cause finder. I need something that tells me what's eating up swap (and/or does all the trashing; e.g., swaps in and out of physical versus virtual memory all of the time) over an x hour period. If someone would be able to give leads on how to dig into such swap usage deeper it would be appreciated.

FYI, I didn't open a ticket because so far every ticket gets closed on account that I need to contact my reseller first. IMHO that's not the way to troubleshoot root cause analysis.

IS your reseller unable to help you? 

run TOP in SSH.
pay particular attention to these processes,

pfilter reporter
websec reporter
mail reporter
check the size of these accounting files, in var/log/reporting
if they are very large, rename them to bak.
restart the logging process.
/etc/init.d/syslogng restart

if http proxy processes are running highest.
the proxy is being reworked in 7.100. however badly written exceptions can throw the http proxy into a tailspin, go over your proxy configuration with a fine tooth comb.


also,
check portscan.
disable it if it is running. portscan is a bit of a hog right now. 
depending on the size of your appliance and what it's load is.
use single scan. 
check the kernel logs for hardware scan errors if you are running an appliance with a hardware scanner on it.

Thanks for the replies.

Spend some time with TOP. Here are the top contenders:

%CPU: mysqld , httpproxy
%MEM: squidf (16), mysqld (14), httpproxy (11)
VIRT: mysqld (189), snort_inline (114), cffd (113), squidf (98)
SWAP: mysqld (117), snort_inline (84), cffd (67), mdw_daemon.plx (50)
RES: squidf (83), mysqld (71), httpproxy (57), cffd (45)

Looks like mysqld, snort_inline and cffd are eating up SWAP.

No problems with e-mail. The smtp.log is fine. Same for the mdw.log

Did find this every 10 minutes or so in the selfmonitoring log:

2007:11:13-09:16:32 (none) selfmonng[3059]: W check Failed increment httpproxy_working counter 1 - 1
2007:11:13-09:16:32 (none) selfmonng[3059]: astaro::logging:checkNotificationID() wrong syntax for level ''
2007:11:13-09:16:32 (none) selfmonng[3059]: W LOGEVENT Name=httpproxy_working Level= Id=
2007:11:13-09:16:32 (none) selfmonng[3059]: W triggerAction: 'cmd'
2007:11:13-09:16:32 (none) selfmonng[3059]: W actionCmd(+):  '/var/mdw/scripts/httpproxy restart'
2007:11:13-09:16:34 (none) selfmonng[3059]: W child returned status: exit='0' signal='0'
2007:11:13-09:16:34 (none) selfmonng[3059]: I check Failed increment httpproxy_running counter 1 - 3

And the fallback log mentions this:

user:err] LCD4Linux[2573]: HD44780: timeout waiting for busy flag on controller 1 (cd)

Size of log files seem to be of no concern either:

mailsec.dbl 4390912
pfilter.dbl 9454592
websec.dbl 25542656

Thanks for your time.

Arthur

...check the size of these accounting files, in var/log/reporting if they are very large, rename them to bak.

Please define "very large" for an Astaro log file.  10MB, 100MB, 1GB, something in between, etc.?

So that system is definitely getting hit with the http proxy restart issue that affects a number of v7 systems at this point. That is due to be addressed once 7.100 comes out of beta. However I've not had to chance to read up on the 7.100 and how it's going yet, so I can't comment on it so far. 

About the only fix you have at the moment is to either not use the proxy, although I have seen instances where also disabling the http cache helps allieve this behaviour as well. 

wait it out til 7.100 is released out of beta- 
or comment out the 'check' for the http proxy in selfmon. not something I recommend since if for some reason your system goes down, the http proxy won't restart at all. So myself I'd stay away from that solution. Howevre here is the how-to


Remove(comment out)  the [httpproxy_working] section from the files
/etc/selfmonng.d/httpproxy.check
/etc/selfmonng.d/httpproxy.check-default
and restart selfmonng

accounting file sizes, all relative/depending on the size of the system.
120 for example, 40MB accounting.dbl is big.

All thanks for the replies.

Did a reboot around 1 o'clock and all was well until 08:43:00.
Swap increased from nothing to 20%+ in a matter of seconds.
At the same time as the first "check Failed increment httpproxy_working counter" entry of the day.

Nothing out of the ordinary, that I could see, in any of the log files.
Users were already active for quite some time also.

Only:
2007:11:14-08:46:48 (none) smtphelper[32054]: id="1005" severity="debug" sys="SecureMail" sub="smtp" name="message status set" msgid="0" status="need_deletion"
but that was minutes later.

Guess I'll do the nightly magic touch and see what the next release will bring.

Cheers.

All thanks for the replies.

Did a reboot around 1 o'clock and all was well until 08:43:00.
Swap increased from nothing to 20%+ in a matter of seconds.
At the same time as the first "check Failed increment httpproxy_working counter" entry of the day.

Nothing out of the ordinary, that I could see, in any of the log files.
Users were already active for quite some time also.

Only:
2007:11:14-08:46:48 (none) smtphelper[32054]: id="1005" severity="debug" sys="SecureMail" sub="smtp" name="message status set" msgid="0" status="need_deletion"
but that was minutes later.

Guess I'll do the nightly magic touch and see what the next release will bring.

Cheers.

Did some tweaking and now swap stays around 12%.

Tweaks used:
- antivirus single scan HTTP traffic rather then dual scan
- HTTP exception for all traffic with destination of Top 5 visited websites and ftp-mozilla.netscape.com
- turned off BATV in SMTP
- IPS exclusion for all traffic with source addres of Internal or Proxy

This on a V7.011 system with less traffic then we had when we were on V6.
Making me think there's an inefficiency somewhere. Looking forward to V7.1xx.

On 7.101 now and restored original settings (no more tweaking). Half a day later CPU was going 60%+. Reinstated antivirus single scan HTTP traffic and CPU dropped below 3%. Happy since.