「drush cc all」コマンドに時間がかかりすぎます。どうすればよいですか？

私のサイトではdrush cc all、実行に4分以上かかります。サイトデータベースは数GBです。しかし、なぜ時間がかかりすぎるのか明確な理由はわかりません。ボトルネックを見つけるにはどうすればよいですか？

キャッシュ自体のクリアは、キャッシュテーブルを切り捨てるだけなので、長時間かかりません。最も時間がかかるのは、その後キャッシュレジストリを再構築することです。通常、すべての新しいフックとすべてのDrupalフォルダーで新しいテンプレートファイルをスキャンするテーマレジストリ、新しいモジュールとクラスファイルのファイルをスキャンするシステムなどです。

drush cc theme-registryまたはその他を指定することにより、特定のキャッシュをいつでもクリアできます。

PHPキャッシュメカニズム（OPCache、XCacheなど）を使用して処理を高速化することを強くお勧めします。また、メモリテーブルキャッシュは、SQLテーブル（memcachedやredisなど）の使用量を置き換えるため、キャッシュをクリアするだけでキャッシュをクリアできます（echo flush_all > /dev/tcp/127.0.0.1/11211Bashなど）。

または、次の方法で、常に手動でキャッシュをクリアできます。

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

デバッグ

特に最も時間がかかっているものを確認するには、/ profile をデバッグする必要があります（XDebug、XHProf、phpdbg、dtraceなど）。

OS X / Unixでは、これはdtrace（を実行した後drush）によって実現できます。

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

Linuxではstrace、たとえば

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

いくつかの特定のものを探すには、例えば：を追加してみてくださいstrace ... 2>&1 | grep -C5 UPDATE。

本当に大きなデータベースがあり、キャッシュクリアを実行していないときにシステムが正常に動作している場合、セットアップを完全にサポートするのに十分なメモリがない可能性があります。

サイトがLinuxボックスで実行されている場合は、（シェルから） 'top'を実行し、shift-Mを押して、使用されているメモリでプロセスリストをソートします。次に、別の端末からcache-clear操作を実行します。mysqlとapacheがリストの一番上に表示されるはずです。これらの各プロセスが使用している合計メモリの割合と、使用されている空きRAMの量を確認できます。大量の仮想スペースがあり、物理RAMがすべて使い果たされている場合、この操作によりVMメモリがスラッシングし、実行時間が通常よりもわずかに短縮される可能性があります。

かつて、セットアップをサポートするのに十分なメモリを備えていないボックスで、トラフィックの多いDrupalサイトを実行していました。関連性の低いトラフィックの少ないサイトでキャッシュクリアを実行すると、キャッシュの再構築によりシステムが制限を超えてしまい、すべてがロックされました。したがって、ここではシステム全体の動作が重要です。これが、「トップ」などのシンプルなツールを開始するのに便利な場所である理由です。

ここで@ greg_1_andersonに（多少）反対します。

システムがの​​間に完全にクラッシュcc allしない場合、一般的なメモリの問題があるとは思わない。LAMPサーバーのメモリが不足すると、スワップが発生します。アクティブなサーバーがスワップにヒットすると、不良の評価が発生します。httpdプロセスは、システムのスローダウン（スワップによりシステムの動作が非常に遅くなる）によりスタックを開始し、これにより、より多くのスワップが使用されるようになります。これが発生したサイトでは、プロセスの負荷が100に達し、そして、多数のアクティブなhttpdプロセス。

最終的にシステムが復旧した場合、チューニングが不十分だと思います。 drush cc all多くのデータベースアクセスが発生するため、問題をより多く示していると思います。私の提案は、サイトでmysqltunerを実行することです。あなたはマルチGBのデータベースを持っている場合は、私の推測では、あなたのことであるinnodb_buffer_pool_sizeにもリモートで適切なサイズではなく、あなたのMySQLインスタンスはスラッシングです。また、代替のキャッシュバックエンドを調査して、データベースのフットプリントを小さく保つようにします。

それはあなたのウェブホスティング環境かもしれません。ローカル設定、または共有ホスティングまたはVPS /サーバーでホスティングしているものを参照していますか？

• ホスティング環境 -共有Webホスティングを使用している場合、Drupal / drushが使用できるメモリ量は制限されます。https：//drupal.org/node/207036を参照して ください
• 最大実行時間 -増やす必要があります

これは完全なソリューションではなく、遅延の原因を特定するためのもう1つのツールです。

topプロセスの監視に使用するだけでなく、mytop有益な出力が見つかる場合があります。（上記の他の回答ではMySQLを想定していますが、別のDBバックエンドを使用している場合は、mytopを同等のツールに交換する必要があります。）

mytopMySQL SHOW FULL PROCESSLISTをループで単純に実行し、どのクエリが実行されているかを示します（そのため、多くの時間がかかります）。キャッシュクリアでこのテーブルまたはそのテーブルをクリーンアップするのに時間がかかっている場合、ここで何が起きているのかを正確に確認できます。install mytopにアクセスできない場合は、シェルで粗いバージョンを実行してください-

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

遅延がMySQLクエリに起因していない場合、このツールは少なくともそれを確認できます。

Drupal 7のSpeed Up Cache Clearingというブログ投稿は、キャッシュクリアプロセスのどの部分が速度を落としているかを正確に絞り込むのに非常に役立つことがわかりました。機能モジュールとエンティティAPIモジュールで特定された問題は私のサイトに影響を及ぼしていましたが、投稿で詳しく説明したプロセスは、Drupalコアおよびブレークポイントモジュールで発生した問題を追跡するのにも役立ちました。

プロセスを完了するには時間がかかりますが、キャッシュのクリアを数分から1分未満に減らすのに役立ちました。