残念ながら、パフォーマンスの低下の主な原因はMySQLであり、私はDBに精通していません。これまでのところ、私のサーバーでmysqlの構成を最適化するのにほとんど運がありません。サーバーには、16 GBのRAMを備えたSandy Bridgeプロセッサと、Ubuntuの上で実行されているDrupal 6サイトを提供するSSDディスクがあります。読み取り/書き込み比率が80/20の約1300qpsです。MyISAMは私が使用する唯一のエンジンです(MyISAMより優れているとの噂はありますが、InnoDBでの私の経験はひどいものでした)。
MySQL 5.1に同梱されている元のmy.cnfはひどいものであり、Debianが推奨する「巨大な」サーバーの構成は、私の場合には最適ではないようです。多くの実験と調整を行った結果、 tuning-primer スクリプトは一般的すぎて賢明なアドバイスを提供できないことがわかりました(完全に誤解を招くようなものでなければ!)。したがって、最適なmysql構成に関連する多数のパラメーターに関して、DBに情報を与えられた一部のdrupalerがmy.cnfを同様のサーバー/ケースで共有できればすばらしいと思います。
そのハードウェアでその負荷で実行している場合は、本当にこれを行う必要があります。 PythianとPerconaは、私が考えることができる2つのコンサルタント/サポート組織です:BTWのどちらにもリンクしていません。
インストールとロードごとに必要な微調整が異なります。私が見たmy.cnfファイルの「巨大な」ケースは、数年前または今日の携帯電話で使用するものです...
デフォルト設定は驚くほど低いので、一度も変更したことがない場合は問題があります。
編集:my.cnfをすでにハッキングしましたか? https://drupal.stackexchange.com/questions/12085/default-to-myisam-instead-of-innodb-in-drupal-7
とにかく、テーブルロックの問題を防ぐために、すべてをInnoDBに変換することを検討する必要があります。ただし、次の点を考慮してください。
現在、MyISAMのみがFULLTEXTインデックスをサポートしています。 InnoDBでのFULLTEXTインデックス作成は現在MySQL 5.6で機能していますが、本番環境では使用できません 。 FULLTEXTインデックスを使用するDrupalテーブルがある場合、それらはInnoDBに変換できません。
FULLTEXTインデックスを持つテーブルを見つけるには、次のクエリを実行します。
SELECT table_schema,table_name FROM information_schema.statistics WHERE index_type='FULLTEXT';
行が戻らない場合は、すべてのInnoDBテーブルを心ゆくまで変換します。 mysqlのみを使用してすべてのMyISAMテーブルをInnoDBに変換する方法についての以前の投稿を書いた 。
読み取りが多い環境の場合、次の操作を行うと、MyISAMで読み取りが速くなります。
--skip-innodb
を追加します(スレーブにデータをロードするときにテーブルをMyISAMに変換します)ALTER TABLE tblname ROW_FORMAT=FIXED;
ROW_FORMAT=FIXED
の使用を推奨しています。これにより、すべてのVARCHARフィールドが内部的にCHARに変換されます。 MyISAMテーブルは大きくなりますが、それに対して実行されたSELECTははるかに高速になります。私はこれを個人的に証明することができます。私はかつて1.9GBのテーブルを持っていました。 ALTER TABLE tblname ROW_FORMAT=FIXED
でフォーマットを変更しました。テーブルは最終的に3.7GBになりました。それに対するSELECTの速度は、他に何も改善または変更することなく20〜25%速くなりました。十分な量を割り当てる必要がありますRAM InnoDBデータ、InnoDBインデックス、およびMyISAMインデックス(MySQLはMyISAMデータをキャッシュしません)。 innodb_buffer_pool_sizeのサイズを増やすには、InnoDBデータページとインデックスページの合計を計算する必要があります。また、key_buffer_sizeのサイズを増やすには、MyISAMインデックスページの合計を計算する必要があります。
メインデータがInnoDBになったら、MySQL 5.5にアップグレードして、新しい設定を利用して InnoDBデータへのアクセスに複数のCPUを使用できるようにする必要があります 。 MySQLのバージョンに関係なく、MySQLのどのバージョンが実行されていても、まったく問題はありませんInnoDBを適切に構成していない場合。 同じレベルのプレイフィールドが与えられた新しいバージョンよりも、MySQLの古いバージョンがうまく実行されているケースが文書化されています 。
裁量に委ねられている唯一のことは、InnoDBベースのレプリケーションマスターでアプリケーションに個別の読み取りスレーブを認識させ、すべての書き込み(INSERT、UPDATE、DELETE)を実行させることです。
すべてのMyISAMテーブルを一括変換してROW_FORMAT='Fixed'
を作成するには、次の手順に従います
mysql -uroot -ppassword -AN -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ROW_FORMAT=Fixed;') FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine = 'MyISAM' ORDER BY data_length" > MyISAMRowFormatConversionToFixed.sql
mysql -uroot -ppassword -A < MyISAMRowFormatConversionToFixed.sql
最小の5つのテーブルを変換してこれを試す場合は、LIMIT 5
をクエリに追加します。
mysql -uroot -ppassword -AN -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ROW_FORMAT=Fixed;') FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine = 'MyISAM' ORDER BY data_length LIMIT 5" > MyISAMRowFormatConversionToFixed.sql
mysql -uroot -ppassword -A < MyISAMRowFormatConversionToFixed.sql
ボトルネックが何であるかを確認するには、さらにデバッグを行う必要があります。これを行うためのいくつかのヒント:
高負荷の期間中に、SHOW FULL PROCESSLIST
何が起こっているかを確認します。私の推測では、いくつかのテーブルロックが実行されています。
slow query log を有効にして、インデックスを使用しないクエリをログに記録するオプションをオンにします。
スロークエリログに書き込まれるステートメントの行ルックアップにインデックスを使用しないクエリを含めるには、
log_queries_not_using_indexes
システム変数。
それらはあなたを正しい方向に向けるべきです。テーブルのインデックスが不適切な場合、問題が発生します。
PerconaのMySQL設定ウィザードをチェックしてみてください-これらの人たちは彼らが何を話しているのかを本当に知っています... :(
http://www.mysqlperformanceblog.com/2011/12/23/online-mysql-configuration-wizard-from-percona/
私はそれが本当の「答え」ではないことを知っていますが、ウィザードを実行すると、さまざまな領域すべてのテストに多大な労力を費やすことなく、パフォーマンスチューニングの改善を得ることができる場所を理解するのに役立つ場合があります。ウィザードを実行し、出力を独自のmy.cnfと比較します。
それが役に立てば幸い:)
デイブ