[Closed] When ever we doing page transaltions hostinger server cpu and memory hitting 100% usage throwing db ...

Thanks for sharing the details. I tested translating the homepage as well as another page, but I'm not seeing slow performance. Are you able to reproduce the issue on the staging site? if so please let me know which page to test.

If the issue is not happening on the staging site, and we have not deactivated any plugins or made changes, this indicates the issue is server side, since the only difference between the live site and this copy should be the server environment.

Please let me know if you are seeing the issue on the staging site as well and I can further troubleshoot there.

Also, have you tested this under higher visitor loads? Since it is a staging site, there are not high visitor loads. We are unable to test that. To better understand the reported high CPU usage during translations, I ran controlled benchmarks under different configurations. The Cloudways test server is a 1-core virtual machine (so a CPU load of 1.0 = 100% capacity). I have attached the test results in a screenshot.

Key Takeaways

-WPML alone does not max out CPU. In isolation, WPML runs well under capacity.

-The custom/child theme and plugin stack drive the high baseline load, even with WPML disabled.

-Translations cause short spikes (e.g., 2.0 on a 1-core server), which is expected because translations are compute-intensive. On multi-core servers, the same spike would be distributed and appear lower.

-The sustained overload we observed (300–460%) was not caused by WPML, but by the combination of custom/child theme + plugins running on limited resources.

Next Steps

1. Could you please confirm the hosting specifications (CPU cores, RAM) of your live site’s server? This will help us gauge whether it has enough resources to handle translations smoothly.

2. If the live server is also 1-core, upgrading to a 2–4 core plan would provide the headroom needed.

3. We also recommend an audit of the custom theme and plugins to identify additional performance bottlenecks. This means you should set up a copy of your site on your same server and deactivate non WPML plugins and switch to a default theme to see if the translations are spiking the CPU in that environment. if not, activate plugins a few at a time and check to see when the issue returns.

1. I measured server load with a lightweight snippet (sys_getloadavg) and ran A/B tests:
1. default theme + no plugins,
2. default theme + WPML only,
3. custom theme + WPML only,
4. custom theme + all plugins, and

Result: WPML alone didn’t saturate CPU;

Here are some tools that you can use to test theme/plugin issues

1. Query Monitor: find slow DB queries, hooks, AJAX requests while loading key pages and during WPML actions.
2. Health Check & Troubleshooting: per-session safe mode to toggle plugins/themes without affecting visitors.
3. WP Crontrol (and Action Scheduler screen if WooCommerce/others are installed): inspect/kill noisy cron queues.
4. Object cache + inspector: enable Redis/Memcached; use your host’s object-cache dashboard or Query Monitor’s “Object Cache” panel to confirm hits/misses.

2. I'm not sure what you mean by sync - can you tell me in more detail what issues you are having with these particular plugins?

3. Use WP Crontrol → “Cron Events” and look for common WPML events, e.g.:
wpml-tm-ate-jobs-sync, wpml-tm-ate-pull, wpml-tm-ate-push (sync with Advanced Translation Editor)
wpml-tm-cleanup-* (translation tables cleanup)
wpml-st-* (String Translation maintenance)
wpml-translation-feedback-*, wpml-update-translation-status
If you see very frequent runs or big backlogs, that’s a flag.

Clear orphaned/failed jobs in WPML → Support → Troubleshooting (run the maintenance actions one by one).

4. Autoload bloat can slow every request. Check the size of autoloaded options and large entries:

Query Monitor shows total autoload size on the Environment panel.

WP-CLI quick check:

wp option list --autoload=on --fields=option_name,size_bytes --format=table | sort -nr -k2 | head -20

WPML’s core settings (e.g., _icl_sitepress_settings) are usually modest; huge rows typically come from caches, transients, or plugins storing large blobs in autoload.