Magento 2.2 often extremely slow, 100% processor usage after setup:upgrade












4














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.










share|improve this question
























  • 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
















4














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.










share|improve this question
























  • 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














4












4








4


2





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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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


















  • 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










2 Answers
2






active

oldest

votes


















5














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):




  1. cache:disable

  2. setup:upgrade

  3. 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.






share|improve this answer

















  • 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



















0














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.






share|improve this answer





















    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    5














    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):




    1. cache:disable

    2. setup:upgrade

    3. 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.






    share|improve this answer

















    • 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
















    5














    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):




    1. cache:disable

    2. setup:upgrade

    3. 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.






    share|improve this answer

















    • 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














    5












    5








    5






    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):




    1. cache:disable

    2. setup:upgrade

    3. 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.






    share|improve this answer












    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):




    1. cache:disable

    2. setup:upgrade

    3. 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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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














    • 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













    0














    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.






    share|improve this answer


























      0














      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.






      share|improve this answer
























        0












        0








        0






        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 13 '17 at 22:44









        Ethan L.

        1117




        1117






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            An IMO inspired problem

            Management

            Investment