Server performance a bit sluggish after re-running apt-get install virtualmin-base

Submitted by austinfwd on Thu, 06/28/2012 - 14:57

As I reinstalled virtulmin-base this past week to fix issues with fcgi/suexec not working (later I realized i probably just could have installed your single apache2-suexec-custom package to completely resolve my issue.... :-(), I think there were several daemon & system configs reset to defaults.

Since then, we think our website performance has seemed a bit sluggish. Not major. Just enough that we notice it & think we're not as fast as we were, and want to get that speed back.

I had previously upgraded from Debian 5 to 6 (3-6 weeks back). No noticeable issues or slowdowns occurred at that time. So I don't think it's related to the OS upgrade. I think if anything, it is related to the configs & such changed by the virtulmin-base package.

Most of the websites we host (60 on this box) run Joomla. So I think our main daemons & system configs we should be looking at are for: apache2 php5 suexec mysql

Do you have any recommendations on what parameters we should be checking to confirm we are configured optimally for our environment?

I have been watching top & htop to try to pin down causes of slowness, but with kind of mixed findings. So I thought it would be worth bouncing the question off of you guys.

Thanks,

Doug

Status: 
Closed (fixed)

Comments

Submitted by andreychek on Thu, 06/28/2012 - 21:59

Howdy -- well, we're not aware of any common issues that might have been changed in Apache, PHP, or MySQL to cause slowness in web page loads.

We're also not aware of anything virtualmin-base does that might cause any slowness -- anything it does is run on every system that runs Virtualmin.

Out of curiosity though, what does "uptime" show when you're experiencing this slowness?

Also, what is the output of "mailq | tail -1"?

Submitted by austinfwd on Thu, 06/28/2012 - 22:17

Currently no slowness. We'll have to check the 'uptime' output next time it happens & look at the load averages.

webhost3:~# mailq | tail -1
Mail queue is empty

I guess we'll just have to watch it & if we notice more slowness I'll come back to this discussion.

I did disable aw-stats. I think that may help. Yesterday running "htop", I kept seeing the aw-stats jobs for different domains spiking out 1 CPU core repeatedly for at least several minutes. So I'm thinking its schedule must have been during the daytime instead of evening. It may have been contributing to some slowness & the timing was just coincidental. Since we don't even use it, I disabled it for all 60 domains, then disabled the feature in Virtualmin. Hopefully that will help.

Thanks for your help.

by the way, are you saying that things like memory limits, timeouts, etc. for PHP & mysql shouldn't have been touched when I ran install virtualmin-base? I only suspected this because it obviously did alter other configuration files on the system for some packages (such as dovecot).

Thanks,

Doug

Submitted by andreychek on Thu, 06/28/2012 - 22:39

Ah, what are the contents of your /etc/cron.d/awstats file? If there's anything in there, you could comment it out -- that doesn't need to be there.

The virtualmin-base package doesn't change anything relating to performance. We prefer to leave settings at their default values, unless a setting needs to be changed in order to get something to work with Virtualmin.

For example, in some circumstances it'll set the directory in dovecot where control/index files are stored -- but it wouldn't change limits or timeouts for Apache/MySQL/PHP, as we feel defaults like those are there for a reason, and we wouldn't want to make unexpected changes.

If we're in doubt, we'd ask during the post-install wizard if a user wants to make a particular change.

Submitted by austinfwd on Thu, 06/28/2012 - 22:42

/etc/cron.d/awstats:

*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh

# Generate static reports:
10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

OK. I'll clear out the contents of the awstats cron.d file. Sounds like that may help.

Thanks,

Doug

Submitted by austinfwd on Tue, 07/03/2012 - 13:42

I'm going to close this ticket. Thanks for your help. I think disabling awstats made a difference. I also think that we have some very complex MySQL queries in one of our Joomla plug-ins which is probably the main culprit for slowness with that one particular site. That obviously is not your problem. :-)

- Doug