[Wordpress] oom-killer killing mysql #927
Comments
marianopeck
added
the
tech-issues
|
Hi @marianopeck, Thanks for using Bitnami. According to the bndiagnostic information you shared, your server hasn't been under heavy load (providing your server size), nor has run short of memory (from the I also see you are still using the |
|
Hi @gongomgra Thanks for your feedback. I agree with you that this server didn't have much load. In fact, this is a "staging" or "dev" site where we do the development before making it public. So yeah, little load. And as you said, plenty of available memory. Yes, by the time the bndiagnostic run (hence the information you have), was all with the default settings according to my server site. That is, Thanks for the tip of BTW, so this "dev" server is now running with the "small" version of those 2 files. Let's see how it behaves for the next couple of days. My gut feeling is that those default "medium" is a bit too much for the server size. Mostly on php-fpm. Did you see the difference on the amount of php-fpm processes that I reported previously? In addition, I can provide even more info. The old Bitnami image where everything is working fine (the production site): In the new bitbami image, where I see this crashes: Doesn't that look like a huge difference??? Thanks in advance, Mariano |
|
Hi @marianopeck, Thanks for your message and for sharing your findings. It is true that the values have been bumped a lot from one image to another. I will double-check the reasons behind this with our engineering team. |
|
Hi @gongomgra You are welcome. Yes, please let me know what you find out with the engineering team. I also found there is a Thanks! |
|
Hi @marianopeck, I hope that using smaller values for the PHP-FPM configuration solves your issue. I've filled the internal task for the engineering team. I will mark the ticket as 'on hold' until we have any update. The 'on hold' status will prevent the stale bot to close the ticket due to inactivity. |
gongomgra
added
on-hold
|
I was also experiencing this challenge. I remapped to the small version and my used memory instantly was cut by more than half from 2.7 GiB to 1.0 GiB. It is a wordpress multisite deployment on azure, defaulted to the medium size config file. It doesn't get traffic really, it is more an internal office tool. After a week out of office, the medium config seemed to balloon many useless instances of php-fpm for what amounts to our default cronjobs, eating up tons of memory of a 2vCPU and 4GB instance. if we were active in the office making some site edits, it probably would have crashed because it had a free amount of <350 MiB this morning when we came back. We were getting nightly OOM kills to mariadb leading into our office closure, the only changes we made were site edits like adding new pages and such. |
github-actions
bot
added
triage
|
Hi @savionlee |
|
Hi @marianopeck, @savionlee, Thanks for your updates. Our engineering team didn't have time to check this yet, but I'm sure this will be a very helpful information for them. |
|
after switching, it seems that php-fpm continues to keep spawning extra things. here's the config that is active from what settings do i change to timeout these unused threads or choose not to spin up 42 of them? when i restart php-fpm with the ctlscript.sh, my memory goes from 2.7 down to 1. I definitely don't need all this extra power and would rather use it in my mariadb. |
|
apologies, i was changing out apache's config file. found the right one, now i'm monitoring it some more for its consumption of resources |
|
Updated WordPress Multisite images have been released as well. |
|
Thanks! Are the values in #927 (comment) also appropriate for a singlesite WordPress image? |
|
HI @olof-dev, Thanks for your message. Yes, the updated values should work fine for a regular WordPress server. Just remember to pick the values matching your instance site and restarting the services for changes to take effect. |
|
I'm running into a similar issue with a functional memory leak on the latest version (or latest as of yesterday) of Bitnami & WordPress. We migrated because of php 8, but now I'm starting to regret it. No matter how many php-fpm processes our config allows, our wordpress site seems to crash spectacularly every few hours. For reference, this is just over the last half an hour: Any help with the status of this issue would be appreciated. |
|
@eiiot Is your php - fpm configuration matching the recommendations above? |
|
Yes, I've tried multiple configurations with no luck. Ended up moving away from bitnami last night, but I still have the old server up if there's anything else I can try. |
|
@eiiot have you tried switching out your apache memory configs? |
|
@eiiot please double-check both memory settings (apache & php-fpm) match the updated one (or manually update them if required), and restart the services to ensure new settings take effect. Can it also be related to plugins/custom-theme not properly working with php 8? |
|
If there are some updated apache settings, I'd love for those to be posted too so that I can make sure my machine won't go down again. (Unless it's trivial to launch a new machine with the new image and get all the existing custom configuration from the old machine moved over? I haven't seen anything about that.) [I'm running the single-site WP image.] |
|
Hi @olof-dev, Sorry, my fault. There shouldn't be any updated settings for Apache, we only updated PHP-FPM configuration. Did you update PHP-FPM settings manually on your instance? Remember to restart services for changes to take effect. |
|
No worries, good to have that confirmed. I updated the values manually and rebooted the machine. I haven't had any crashes since! (But I'd want to give it another week or so to make sure.) |
|
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
|
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary. |
Platform
AWS
bndiagnostic ID know more about bndiagnostic ID
307e09bd-5c59-eba7-92e5-403e0088aba8
bndiagnostic output
===== Begin of bndiagnostic tool output =====
[Connectivity]
Server ports 22, 80 and/or 443 are not publicly accessible. Please check the
following guide to open server ports for remote access:
https://docs.bitnami.com/general/faq/administration/use-firewall/
===== End of bndiagnostic tool output =====
bndiagnostic was not useful. Could you please tell us why?
I reviewed everything found by the tool but nothing was useful
Describe your issue as much as you can
Every couple of days/weeks I find out that my Wordpress stack is not responding. After some investigation, I found out in
/var/log/messages.1the following:As you can see, the OOM Killer is killing MySQL. Notice that I did not change anything from the default bitnami wordpress configuration.
It caught my attention the amount of php-fpm processes running by the time of the kill. So I tried to change the system to use
memory-small.confinstead ofmemory-medium.conf. But other than this, I don't have any other clue.The output of
freeis:Also, I have another server with the same exact hardware (memory reporting the same, same wordpress site, etc) but with an older bitnami image and there is no problem there. It's only happening on this "newer" bitnami image.
Notice the php-fpm processes in the "old" bitnami image that works perfectly:
And now notice in the "new" bitnami image:
Maybe this is related to this other case? or this? or this? There seem to be many cases reported.... see also this.
Any ideas?
Thanks in advance,
The text was updated successfully, but these errors were encountered: