Juno Wiki & Help‎ > ‎

Third Party Server Notes

Server: Gold
Interpreter: NginX
WebServer: Apache
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
Gzip: Enabled
FcgidConnectTimeout: 400

Case 1: Sagepay Random Orders Failing

FastCGI PHP processes were experiencing a timeout as follows:

[Wed Feb 26 18:38:08 2014] [warn] [client 81.138.7.236] 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 81.138.7.236] 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


Notes
---

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 backups.

---- 

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.

---

Comments