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

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