Tweaking cPanel For Lower Memory Consumption
Do you find that your VPS or dedicated machine is regularly running out of memory because of cPanel? The following tutorial will help you overcome this, and help you to make your machine run faster.
Stopping SpamAssassin
This program isn’t overly important to the stopping of spam. To turn it off do the following:
Go to WHM > Server Configuration > Tweak Settings > Disable Spamd
And:
Go to WHM > Service Manager > Disable Spamd
Stopping Mailman
If you or none of your customers aren’t running any mail listings through cPanel, it would be a good idea to disable Mailman.
Go to WHM > Server Configuration > Tweak Settings > Disable Mailman
Never Use Tomcat on a VPS
Never run TomCat on a VPS because of it’s high RAM needs.
Disable CatchAll
If you’re undergoing a mail attack, catch all can use up many resources + storage. To disable do the following:
Go to WHM > Server Configuration > Tweak Settings > Change to :fail:
Tweak Apache
Apache can be quite a memory consuming monster on it’s own. To tweak, do the following:
vi /etc/httpd/conf/httpd.conf
(Press ’shift’ and ‘i’ to enable inserting/editing.)
Change the following settings:
MinSpareServers 2
MaxSpareServers 5
StartServers 3
Save the file by pressing ‘esc’, then type ‘:wq:’, then hit return.
After that, restart Apache: /etc/init.d/httpd restart
All that should reduce your memory useage by a large amount.
Fidget said,
October 4, 2007 @ 11:58 am
In addition to the section “Disable Catchall” …
If you’re undergoing a mail attack - the attacks that can be detered by setting an appropriate catchall (default) address as said, and for information purposes these attacks usually take the form of ‘dictionary’ attacks - that is random strings of letters representing the usernames (such as dkfjg@thedomain.com or abcdef@thedaomin.com).
In such cirumstances it is obviously preferable to set the catchall (default) address to :fail: as this causes the MTA (mail transfer agent - usually Exim) to reject the email at SMTP time - this means that the mail server will refuse to accept and process the email. Many users set the catchall/default address to :blackhole: but the MTA will handle this by accepting the message and then deleting it and this uses resources to do so, whereas using :fail will not use such resources. Other users set the default/catchall address to another email address, either in their account or a remote address but either also uses resources.
So, if you are under such an attack it is obviously preferrable to change the default/catchall addresses very quickly to preserve resources and prevent your MTA from going down.
To be sure that you need to make any changes its best to see if anyone is using anything other than the desired :fail: setting. You can find this out by running this command in SSH …
grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’
… if you see no results then all accounts are using :fail: but otherwise you will see a list of all domains which use :blackhole: or have an address set for the default/catchall setting.
You can change all settings to :fail: that do not have it already set, but maybe it would be a good idea to backup the valiases before doing so, so that you can return the settings when the attack subdues. So copy the entire valiases folder to a backup folder for later retrieval - to do this run these two commands in SSH …
mkdir /etc/valiasesbackup
… this creates the backup folder, and …
cp -p /etc/valiases/* /etc/valiasesbackup
… this copies all files in the valiases folder to the backup folder.
Then to change all default addresses to :fail: we’ll need to run two commands, one to change any :blackhole: settings and the other to change any default addresses that forward to another email address. First run this command in SSH …
replace ‘:blackhole:’ ‘:fail:’ — /etc/valiases/*
… this will change any :blackhole: setting to the desired :fail: setting.
Then the second command …
sed -i ’s/^\*: [^ ]*$/*: :fail: ADDRESS DOES NOT EXIST/g’ /etc/valiases/*
… this will change any setting which sends the unrouted mail to another email address to the desired :fail: setting.
Now, running this command again should reveal no results because we have just changed all settings to :fail: …
grep ‘*:’ /etc/valiases/* | egrep -v ‘:fail:’
Once the attack is over, you can then copy the backed up valiases files to their usual place, run this command from SSH …
cp -p –reply=yes /etc/valiasesbackup/* /etc/valiases
… all done.