私はWordPressサイトに1万以上の投稿があり、投稿を追加したり編集したりしていると常に遅くなっています。管理者の投稿リストに加えて、ページはユーザーにとっては素晴らしく高速ですが、書き込みや更新が行われるとサーバーのCPU使用率が100%になり、時間がかかります(PHPのタイムアウトの60秒より長い場合があります)。
私はこれがMyISAMのテーブルレベルロックと関係があると考えており、これをInnoDBに切り替えることを考えています。これを行うことの影響は何ですか?
いくつかの統計:
select - per hour ~22k
update - per hour ~7.6k
set option - per hour ~7k
他にも最適化ができることはたくさんありますが、これが最大の影響を与える可能性があるというのが私の気持ちです。
ありがとう
編集 :遅くなる原因となっている大きな問題の1つを見つけました。毎回 "関連性"を再生成していたのはYARPP(Yet Another Related Posts Plugin)でした。 。私は「タグを考慮する」オプションをオフにしました、そしてそれはかなりスピードアップしました。
また、XMLサイトマッププラグインなど、物事を再生成する他のプラグインがこの種の問題を引き起こす可能性があります。
それで、私の差し迫った問題は解決しました、けれども私はまだWordpressのためのInnoDB対MyISAMへの良い答えを聞きたいです!
私は確かにInnoDBに切り替えるでしょう。テーブルロック/行ロックは長い間議論されてきました。私はいつもInnoDBを選びます。しかし、 InnoDBを選択するもう1つの大きな理由があります...キャッシング 。
ほとんどの人はMyISAMの方が読み込みが速いと自慢していますが、MyISAMの多数キャッシュ(キーキャッシュ(key_buffer_sizeで設定)と呼ばれる)は.MYIファイルのインデックスページのみをキャッシュすることを忘れています。データページをキャッシュすることはありません。 32ビットシステムでは公式に最大4GBです。 8GBは64ビットに最適です。
InnoDBバッファープールはデータとインデックスページをキャッシュします。お持ちのサーバーによっては、データセット全体をRAMにキャッシュできます。 InnoDBは最大80%RAM、DB Conenctionsは10%、OSは10%に調整できます。 これは異なるオペレーティングシステムにも当てはまります 。
Drupalのお客様にこれらのことをお勧めしました 素晴らしい成功を収めて Wordpressにも適用されます まさに同じです。私はWordPressを使ってクライアントにDBサポートを提供しました。同じ改善.
あなたはいつでも InnoDBのためにメモリを設定することができます より効果的にあなたはより多くのMyISAMをすることができます。 InnoDBをパフォーマンスのニーズに合わせて微調整する方法は常にあります 。あなたのデータが大きくなるにつれて、それは最終的に 要件になる になります。
InnoDBはおそらく役に立ちません - ページ/行レベルのロックは競合を軽減するのに役立ちますが、それがあなたの問題のようには感じません。
平均的なブログのシナリオでは、MyISAMがInnoDBよりも遅いことを示唆しているものがたくさんあります(書き込みより読み取りが多い)。
切り替える前に、少なくとも次のことをしてください。
個人的な経験から、wp_commentsのインデックスのないフィールドにインデックスを追加することは私の特定の状況(10人程度の人々が同時にコメントしようとしている可能性があるバースト的なコメントの期間)で大いに役立ちました。どのようなクエリがゆっくり実行されているのか、そしてなぜ問題の理解を深めるために、そして本当の解決策になるのか!