Fixing 502 Error on Magento Cloud
502 Bad Gateway error might be an error that could happen especially, in a particular Integration (Development) environment. This error could be very hard to analyze if after checking the Magento Cloud configuration and Internet speed, the Engineering team is still not able to determine the root cause of this error.
This article is intended to briefly summarize the possible root cause of error 502 and the recommended solutions to mitigate it.
Most of the time, and in some particular Magento Cloud Integration/Development environments, error 502 is caused by the following reasons.
- Overloaded database.
- Too many cron jobs running simultaneously.
Overloaded database
Integration and other environments than Production and Staging, are supposed to be used for developing and/or testing, so a database trim might (products deletion mostly) might be necessary in order to have only a representative sample for developing/testing.
Too many cron jobs running simultaneously
Cron jobs might reduce memory performance in an environment that is not fully optimized to be used for production. So the best idea here would be to run them in groups in order to avoid missed or pending jobs.
A database check would be necessary in advance for getting a clearer idea on the current cron jobs status. For example:
MariaDB [main]> select status, count(*) from cron_schedule group by status;
+———+———-+
| status | count(*) |
+———+———-+
| error | 535 |
| missed | 5392 |
| pending | 574 |
| running | 1 |
| success | 852 |
+———+———-+
MariaDB [main]> select job_code, status, count(*) from cron_schedule where date(created_at) = CURDATE() and status = ‘missed’ group by job_code, status;
+———————————————–+——–+———-+
| job_code | status | count(*) |
+———————————————–+——–+———-+
| catalog_event_status_checker | missed | 107 |
| catalog_product_frontend_actions_flush | missed | 6 |
| catalog_product_outdated_price_values_cleanup | missed | 5 |
| consumers_runner | missed | 75 |
…
| indexer_reindex_all_invalid | missed | 130 |
| indexer_update_all_views | missed | 138 |
+———————————————–+——–+———-+
As seen in these examples, many cron jobs are not being executed, so splitting the cron jobs and running them in groups can be done by updating in .magento.app.yaml. This is to avoid serial execution and to further reduce memory consumption. An splitting example would be as follows:
First identify the current groups that can be utilized in the system:
[email protected]:~$ find . -name cron_groups.xml
./vendor/amasty/base/etc/cron_groups.xml
…
./vendor/magento/module-message-queue/etc/cron_groups.xml
./vendor/magento/module-staging/etc/cron_groups.xml
./vendor/mailchimp/mc-magento2/etc/cron_groups.xml
Based on the output above, the cron jobs can easily splitted into groups:
# Default Magento 2 cron jobs
default:
spec: “*/10 * * * *”
cmd: “php bin/magento cron:run –group=default”
…
consumers:
spec: “*/19 * * * *”
cmd: “php bin/magento cron:run –group=consumers”
staging:
spec: “*/21 * * * *”
cmd: “php bin/magento cron:run –group=staging”
The above suggestion is only for some particular Integration/Development environments. How granulated the jobs group should be splitted is up to every scenario and environment.
In this particular example, after grouping the cron jobs, pushing the changes and clearing out the cron job tables, the changes will be reflected in the database.
MariaDB [main]> select status, count(*) from cron_schedule group by status;
| Before | After |
| +———+———-+| status | count(*) |+———+———-+| error | 535 || missed | 5392 || pending | 574 || running | 1 || success | 852 |+———+———-+ | +———+———-+| status | count(*) |+———+———-+| error | 0 || missed | 0 || pending | 0 || running | 12 || success | 24 |+———+———-+ |
Note: The database info is accumulative over the time.
And finally, it is worth mentioning that this configuration is defined at the file app/etc/env.php, and each environment can have its own env.php with its own configuration.
