- Joined
- Apr 24, 2016
- Messages
- 439
- Points
- 18
On a box running both the database and the PHP workers, the two are competing for the same RAM, and I keep discovering I gave one of them too much only when the OOM killer picks a side. It usually picks MySQL, which is the worst available outcome, because the site then serves errors instead of merely being slow.
My rough method is to size the InnoDB buffer pool to fit the working set if it fits at all, then work out how many PHP-FPM workers the remainder allows using the memory those workers actually use rather than the limit in php.ini. Measured, not configured, since the configured limit is a ceiling almost nothing reaches and sizing off it wastes half the box.
Where I am less sure is headroom. I have seen anything from ten to twenty five percent suggested for the OS and page cache, and on a small VPS that gap is the difference between two workers and five. I leave more than feels necessary, mostly because I would rather waste a bit of RAM than tune this at 2am.
For anyone running both on one box, do you cap PHP-FPM workers and let requests queue, or let it scale and rely on swap to absorb the overshoot? And has anyone had decent results setting cgroup memory limits per service instead of tuning the config values against each other?
My rough method is to size the InnoDB buffer pool to fit the working set if it fits at all, then work out how many PHP-FPM workers the remainder allows using the memory those workers actually use rather than the limit in php.ini. Measured, not configured, since the configured limit is a ceiling almost nothing reaches and sizing off it wastes half the box.
Where I am less sure is headroom. I have seen anything from ten to twenty five percent suggested for the OS and page cache, and on a small VPS that gap is the difference between two workers and five. I leave more than feels necessary, mostly because I would rather waste a bit of RAM than tune this at 2am.
For anyone running both on one box, do you cap PHP-FPM workers and let requests queue, or let it scale and rely on swap to absorb the overshoot? And has anyone had decent results setting cgroup memory limits per service instead of tuning the config values against each other?







