Magento 2.2 often extremely slow, 100% processor usage after setup:upgrade
I'm currently running Magento 2.2, php7, Apache2
on an Amazon AWS EC2 c4.large
instance, but even the t2.micro instances are usually fine when I'm using it as a development server.
For some reason every once in a while when I run setup:upgrade after updating one of the setup files in one of my custom modules or after installing a third party module my server will become extremely slow, staying at 100% cpu usage whenever I try to load a page, the page loading takes 1 minute+, and will stay at 25% cpu usage when not loading pages.
It only affects the magento website where I called setup:upgrade, pages on other magento installs on the same server will still load at normal speed.
Sometimes the problem is fixed by removing the module I just upgraded, restarting the server and then reinstalling the module without any changes to the code, sometimes a second setup:upgrade fixes the problem, and sometimes it seems the only way I can fix it is by completely reinstalling Magento 2
and the modules.
I have had this occur on Magento 2.1.6, 2.1.8, 2.1.9
and 2.2
, all kinds of different combinations of themes and modules that none else seems to have any problems with, on default, developer and production mode.
EDIT: Important note
If you are having this issue and like me are certain you never disabled your caches, there is an acknowledged issue as of right now (Magento 2.3) where running composer update
occasionally disables all of your caches. So even if you think your caches are enabled, it's worth to double-check.
magento2 performance
|
show 1 more comment
I'm currently running Magento 2.2, php7, Apache2
on an Amazon AWS EC2 c4.large
instance, but even the t2.micro instances are usually fine when I'm using it as a development server.
For some reason every once in a while when I run setup:upgrade after updating one of the setup files in one of my custom modules or after installing a third party module my server will become extremely slow, staying at 100% cpu usage whenever I try to load a page, the page loading takes 1 minute+, and will stay at 25% cpu usage when not loading pages.
It only affects the magento website where I called setup:upgrade, pages on other magento installs on the same server will still load at normal speed.
Sometimes the problem is fixed by removing the module I just upgraded, restarting the server and then reinstalling the module without any changes to the code, sometimes a second setup:upgrade fixes the problem, and sometimes it seems the only way I can fix it is by completely reinstalling Magento 2
and the modules.
I have had this occur on Magento 2.1.6, 2.1.8, 2.1.9
and 2.2
, all kinds of different combinations of themes and modules that none else seems to have any problems with, on default, developer and production mode.
EDIT: Important note
If you are having this issue and like me are certain you never disabled your caches, there is an acknowledged issue as of right now (Magento 2.3) where running composer update
occasionally disables all of your caches. So even if you think your caches are enabled, it's worth to double-check.
magento2 performance
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35
|
show 1 more comment
I'm currently running Magento 2.2, php7, Apache2
on an Amazon AWS EC2 c4.large
instance, but even the t2.micro instances are usually fine when I'm using it as a development server.
For some reason every once in a while when I run setup:upgrade after updating one of the setup files in one of my custom modules or after installing a third party module my server will become extremely slow, staying at 100% cpu usage whenever I try to load a page, the page loading takes 1 minute+, and will stay at 25% cpu usage when not loading pages.
It only affects the magento website where I called setup:upgrade, pages on other magento installs on the same server will still load at normal speed.
Sometimes the problem is fixed by removing the module I just upgraded, restarting the server and then reinstalling the module without any changes to the code, sometimes a second setup:upgrade fixes the problem, and sometimes it seems the only way I can fix it is by completely reinstalling Magento 2
and the modules.
I have had this occur on Magento 2.1.6, 2.1.8, 2.1.9
and 2.2
, all kinds of different combinations of themes and modules that none else seems to have any problems with, on default, developer and production mode.
EDIT: Important note
If you are having this issue and like me are certain you never disabled your caches, there is an acknowledged issue as of right now (Magento 2.3) where running composer update
occasionally disables all of your caches. So even if you think your caches are enabled, it's worth to double-check.
magento2 performance
I'm currently running Magento 2.2, php7, Apache2
on an Amazon AWS EC2 c4.large
instance, but even the t2.micro instances are usually fine when I'm using it as a development server.
For some reason every once in a while when I run setup:upgrade after updating one of the setup files in one of my custom modules or after installing a third party module my server will become extremely slow, staying at 100% cpu usage whenever I try to load a page, the page loading takes 1 minute+, and will stay at 25% cpu usage when not loading pages.
It only affects the magento website where I called setup:upgrade, pages on other magento installs on the same server will still load at normal speed.
Sometimes the problem is fixed by removing the module I just upgraded, restarting the server and then reinstalling the module without any changes to the code, sometimes a second setup:upgrade fixes the problem, and sometimes it seems the only way I can fix it is by completely reinstalling Magento 2
and the modules.
I have had this occur on Magento 2.1.6, 2.1.8, 2.1.9
and 2.2
, all kinds of different combinations of themes and modules that none else seems to have any problems with, on default, developer and production mode.
EDIT: Important note
If you are having this issue and like me are certain you never disabled your caches, there is an acknowledged issue as of right now (Magento 2.3) where running composer update
occasionally disables all of your caches. So even if you think your caches are enabled, it's worth to double-check.
magento2 performance
magento2 performance
edited yesterday
asked Oct 22 '17 at 0:14
Kaascroissant
36215
36215
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35
|
show 1 more comment
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35
|
show 1 more comment
2 Answers
2
active
oldest
votes
TL;DR: Just switch on the config caches.
Longer story:
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
- cache:disable
- setup:upgrade
- reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I realized that it must depend on some cache settings. And I started to switch off some of them. After switching off the config caches, the problem re-appeared instantly.
After switching off every cache except the config cache, everything runs fast again.
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
add a comment |
I have the same situation as you, I run:
php bin/magento setup:static-content:deploy -f
to force M2 to deploy the static data in developer mode in order to skip the long wait.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "479"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f198084%2fmagento-2-2-often-extremely-slow-100-processor-usage-after-setupupgrade%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
TL;DR: Just switch on the config caches.
Longer story:
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
- cache:disable
- setup:upgrade
- reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I realized that it must depend on some cache settings. And I started to switch off some of them. After switching off the config caches, the problem re-appeared instantly.
After switching off every cache except the config cache, everything runs fast again.
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
add a comment |
TL;DR: Just switch on the config caches.
Longer story:
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
- cache:disable
- setup:upgrade
- reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I realized that it must depend on some cache settings. And I started to switch off some of them. After switching off the config caches, the problem re-appeared instantly.
After switching off every cache except the config cache, everything runs fast again.
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
add a comment |
TL;DR: Just switch on the config caches.
Longer story:
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
- cache:disable
- setup:upgrade
- reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I realized that it must depend on some cache settings. And I started to switch off some of them. After switching off the config caches, the problem re-appeared instantly.
After switching off every cache except the config cache, everything runs fast again.
TL;DR: Just switch on the config caches.
Longer story:
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
- cache:disable
- setup:upgrade
- reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I realized that it must depend on some cache settings. And I started to switch off some of them. After switching off the config caches, the problem re-appeared instantly.
After switching off every cache except the config cache, everything runs fast again.
answered May 18 '18 at 8:13
BuzzJoe
6612
6612
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
add a comment |
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
1
1
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
I feel extremely stupid right now because I have been struggling with this a very long time, but it never occurred to me to check if the cache was on. I never disable the cache myself, but for some reason all caches were disabled. Thank you!
– Kaascroissant
Jun 15 '18 at 18:46
add a comment |
I have the same situation as you, I run:
php bin/magento setup:static-content:deploy -f
to force M2 to deploy the static data in developer mode in order to skip the long wait.
add a comment |
I have the same situation as you, I run:
php bin/magento setup:static-content:deploy -f
to force M2 to deploy the static data in developer mode in order to skip the long wait.
add a comment |
I have the same situation as you, I run:
php bin/magento setup:static-content:deploy -f
to force M2 to deploy the static data in developer mode in order to skip the long wait.
I have the same situation as you, I run:
php bin/magento setup:static-content:deploy -f
to force M2 to deploy the static data in developer mode in order to skip the long wait.
answered Nov 13 '17 at 22:44
Ethan L.
1117
1117
add a comment |
add a comment |
Thanks for contributing an answer to Magento Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f198084%2fmagento-2-2-often-extremely-slow-100-processor-usage-after-setupupgrade%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
c4.large CPU 2 RAM 3.75 - this is absolutely normal load. if you have some code issues or in developer mode.
– MagenX
Oct 22 '17 at 13:26
My problem is that there are no code issues and even in developer mode I don't think it should take minutes for a single page to load in the exact same configuration that it takes less than half a second to load on a micro server. 99% of the time there are no issues and everything is extremely fast, but seemingly randomly the entire installation breaks down and nothing loads anymore until it's reinstalled with no changes to the code whatsoever.
– Kaascroissant
Oct 22 '17 at 20:35
Check with production mode, in develoeper mode js and css created on the fly so it will take time to load.
– Sunil Patel
Oct 25 '17 at 7:02
I know, but production mode still has the same problem, and when the problem is not occurring developer and default mode are still loading pages very fast, just occasionally after running upgrade the entire server is slowed to a crawl regardless of the mode.
– Kaascroissant
Oct 25 '17 at 9:24
any sollutions? Facing the same...
– Jilco Tigchelaar
Dec 7 '17 at 17:35