Magento 2.2は非常に遅いことが多く、セットアップ後のプロセッサ使用率は100％です：アップグレード

私は現在インスタンスで実行Magento 2.2, php7, Apache2していAmazon AWS EC2 c4.largeますが、開発サーバーとして使用している場合、t2.microインスタンスでさえ通常は問題ありません。

何らかの理由で、たまにsetup：upgradeを実行すると、カスタムモジュールの1つでセットアップファイルを更新した後、またはサードパーティのモジュールをインストールした後、サーバーが非常に遅くなり、試行するたびにCPU使用率が100％のままになりますページをロードするには、ページのロードに1分以上かかり、ページをロードしない場合はCPU使用率が25％のままになります。これは、私がsetup：upgradeを呼び出したmagento Webサイトにのみ影響します。同じサーバー上の他のmagentoインストールのページは、通常の速度でロードされます。

アップグレードしたばかりのモジュールを削除してサーバーを再起動し、コードを変更せずにモジュールを再インストールすることで問題が解決する場合があります。2番目のセットアップ：アップグレードで問題が修正され、場合によっては修正できる唯一の方法と思われます。Magento 2モジュールを完全に再インストールすることにより。

私はこれが上で発生持っていたMagento 2.1.6, 2.1.8, 2.1.9し、2.2どれも他には、デフォルトで、開発者や生産モードの問題を持っているようだしないことを、テーマやモジュールの異なる組み合わせのすべての種類を。

編集：重要な注意
この問題が発生していて、私と同じようにキャッシュを無効にしていないことが確かである場合、現時点で確認済みの問題（Magento 2.3）があり、実行composer updateするとすべてのキャッシュが無効になることがあります。したがって、キャッシュが有効になっていると思われる場合でも、再確認することをお勧めします。

TL; DR：設定キャッシュをオンにするだけです。

長い話：

私は同じ問題を抱えており、少し遊んでいます。

再現する手順（開発者モード）：

1. キャッシュ：無効化
2. セットアップ：アップグレード
3. ブラウザでフロントエンドまたはバックエンドをリロードします

リロードしてhtopで監視すると、システムは一部のPHPプロセスを「スパム」し、すべてのCPUを完全に利用します。これは、いくつかのキャッシュ設定に依存する必要があることに気付いたときです。そして、私はそれらのいくつかをオフに切り替え始めました。設定キャッシュをオフにした後、問題はすぐに再現されました。

構成キャッシュ以外のすべてのキャッシュをオフにした後、すべてが再び高速で実行されます。

composerを使用して更新した場合、キャッシュが無効になっている可能性があります。これは、2.3.1までのバージョンに適用されます。Magentoのルートフォルダーにある次のコードを使用して、単に有効にします。

php bin/magento cache:enable

私はあなたと同じ状況です、私は走ります：

php bin/magento setup:static-content:deploy -f

長い待機をスキップするために、M2に静的データを開発者モードでデプロイするように強制します。

bin / magentoキャッシュ：bin / magentoキャッシュをフラッシュ：有効

アップグレードが完了したらすぐに、これら2つのステップを一緒に実行します。システムはまだ何百万ものcronジョブによってスパムされており、私は彼らが何をしているのか私にはわかりません。しかし、キャッシュが有効になった後、世界は平和に戻りました。Magentoがまだ未成熟であるのは、すでに2020年です。