PHP handler: FastCGI
Memory Limit: 512MB
Innodb: Utilize an InnoDB option to store "per table files"
Additional Backup: SQL Backups to file
Additional Monitoring: Munin
Timeout: increased wait_timeout in mysql to 600Secs
Connections: adjust max_user_connections to 100
Case 1: Sagepay Random Orders Failing
FastCGI PHP processes were experiencing a timeout as follows:
[Wed Feb 26 18:38:08 2014] [warn] [client 188.8.131.52] mod_fcgid: read data timeout in 40 seconds, referer: https://exampledomain.com/index.php/admin/catalog_category/index/key/880f33bb774ad7951251738ac8eb1ca2/
[Wed Feb 26 18:38:08 2014] [error] [client 184.108.40.206] Premature end of script headers: index.php, referer: https://www.exampledomain.com/index.php/admin/catalog_category/index/key/880f33bb774ad7951251738ac8eb1ca2/adjusted the timeout variables to prevent this from occurring.
Case 2: Speed Issues
A site was running slower than expected.
Changed KeepAlive to On (from Off)
Changed KeepAliveTimeout to 5 (from 1)
Killed Apache and started it.
Checklist For Server Upgrade Keeping the Same IP (only if same IP Upgrade is requested)
- Confirm IP+SSL certificates to remain the same or changes
- Check that server installed modules are to be moved to the new server e.g. Sphinx search
- Check that sufficient memory is available (PHP Memory)
- Test site on live server and confirm it is fully functional.
- Confirm the date/Time of the move
- Check the critical path once site has been moved
- Check Magento admin that server IP has been corrected e.g. Sagepay/Paypal
The way InnoDB data is
stored in on disk and pretty the usual setup, the memory part is buffers
and cache though the write buffer part does pose some risk in an
unclean shutdown such as a crash of the server or if MySQL is killed.
There is however transaction logging that ensures that in such case, the
transaction log is processed when MySQL is started again (such as after
a reboot) to recreate data/changes that were lost in the write buffer.
The "on disk" mysql dumps are primarily as backup in case corruption in
the data causes an inability in restoring properly from the off-site
The issue about the lare memory footprint is that InnoDB table data from
all databases is by default stored in one central file and when data is
deleted from the tables, the large central file is not cleaned to
reclaim the used disk space.
To avoid this being a major issue, we utilize an InnoDB option to store
"per table files". However a central file is still used for some
transactional/meta data and this has grown very large (27gb) so needs to
be cleaned up manually as not only is it wasting disk space, but the
MySQL server has to waste memory and CPU on reading through it.