web-dev-qa-db-ja.com

断片化されたMySQLinnodbテーブルはI / Oの問題を引き起こす可能性がありますか？ 「タスクが120秒間ハングしました」がクラッシュしますか？

負荷が急上昇する大規模なinnodbデータベースは、コンソールで「タスクが120秒間ハング」するランダムなクラッシュを引き起こしているようです。これらのクラッシュ中にシステムに書き込まれるログはありません。 innodbテーブルはかなり大きく、ストレージには20ギガ以上あります。

カーネル2.6.36および2.6.38-1564ビットを搭載したUbuntu10.04でI/Oの負荷が高いテーブルの断片化により、ランダムなシステムクラッシュが発生する可能性がありますか？

「専用ベアメタル」vpsホストサーバーでホストされている大きなinnodbテーブルで実行されるランダムなシステムクラッシュの問題を調査しています。

MySQLのバージョンは5.1です。

結果は次のとおりです。 "SELECT data_length、index_length、（data_length + index_length）/ power（1024,3）GB FROM information_schema.tables WHERE ENGINE = 'InnoDB' ORDER BY data_length + index_length DESC LIMIT 10;"：

+-------------+--------------+-------------------+
| data_length | index_length | GB                |
+-------------+--------------+-------------------+
| 14758707200 |  17220501504 |   29.782958984375 |
|  9456762880 |  16465543168 |  24.1420288085938 |
| 16983785472 |   6954041344 |  22.2938385009766 |
|  5625610240 |   2997813248 |  8.03118896484375 |
|  3694133248 |   1730150400 |      5.0517578125 |
|  2031091712 |     35209216 |  1.92439270019531 |
|  1357905920 |    706740224 |      1.9228515625 |
|  1107312640 |    320356352 |  1.32962036132812 |
|   637534208 |    760889344 |  1.30238342285156 |
|   488636416 |    260620288 | 0.697799682617188 |
+-------------+--------------+-------------------+

開くファイル= 300。

tia

ubuntumysqlxeninnodbio
3
Tom G

巨大なテーブルがあるようです

InnoDBテーブルmydb.mytableを最適化する場合は、次を実行するだけです。

ALTER TABLE mydb.mytable ENGINE=InnoDB;

ホッドの下で、それは以下を行います：

CREATE TABLE mydb.mytablenew LIKE mydb.mytable;
INSERT INTO mydb.mytablenew SELECT * mydb.mytable;
ALTER TABLE mydb.mytable RENAME mydb.mytableold;
ALTER TABLE mydb.mytablenew RENAME mydb.mytable;
DROP TABLE mydb.mytableold;

すべてのInnoDBテーブルを一括デフラグする場合は、次のコマンドを実行します。

echo "SET SQL_LOG_BIN = 0;" > /root/DefragInnoDB.sql
MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
SQL="SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')"
SQL="${SQL} FROM information_schema.tables WHERE engine='InnoDB'"
mysql ${MYSQL_CONN} -ANe"${SQL}" >> /root/DefragInnoDB.sql
mysql ${MYSQL_CONN} -A < /root/DefragInnoDB.sql

InnoDBをそれほど頻繁にデフラグする必要はないかもしれません。 DBA StackExchangeの私の投稿をチェックして、1つのInnoDBテーブルを最適化する必要があるかどうかを判断します 。

ちなみに、一部のテーブルは、データよりもインデックスによって消費されるスペースが多いように見えます。これらのテーブルでデフラグを実行した後、戻って各テーブルのインデックスを確認します。 未使用のインデックス があるかどうかを判断し、それらを削除してみてください。

innodb_open_files として300があります。あなたはそれをより高く上げることができますが、それを高く設定しすぎないでください

Innodb_open_filesの次の投稿を参照してください

また、MySQL 5.5をアップグレードして、InnoDBストレージエンジンによるCPU使用率を向上させるために innodb_read_io_threadsとinnodb_write_io_threadsを上げることができるようにすることをお勧めします 。

1
RolandoMySQLDBA

そのデータベースにアクセスするクライアントがたくさんありますか、それとも同時接続がいくつかありますか？十分なRAMがありますか、それともサーバーがスワップしますか？

あなたが絶対に説明することはcan起こりますが、それは非常に忙しいワークロードまたは非常に遅い/信頼性の低いI/Oサブシステムのいずれかを意味します。

どんなパフォーマンスを試しましたかbonnie++、iozoneまたは他のベンチマークツールがサーバーに提供されますか？

2
Janne Pikkarainen