適当に生きる - つれづれ -

生きる中で思ったことを適当に綴っています。



サーバーのプラン変更(プランアップ)をしても重いから、MySQLを少しチューニングした。

毎度毎度、宣伝するまとめのまとめ  |  アンテナサイト無料作成サービスのまとめのサーバーのプランを変更してサーバーのスペックをアップしました。

 

このサイト自体、insert系の処理が多いのですが、サーバーのスペックを変更してもMySQLの設定を全く変更していないからサーバーが重かったようです。

今回変更したMySQLのバージョンは、5.5なのですが、変更した内容は、

innodb_buffer_pool_size
innodb_log_file_size

の値。

 

これらの設定の値については、

yakst.com

に詳しく書かれているのですが、innodb_buffer_pool_sizeは、

デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。

innodb_log_file_sizeの値は、

デフォルトは48M。書き込みが高負荷なシステムでは、パフォーマンス改善に貢献するよう、バックグラウンドでのディスクへの書き込みまでの時間を延ばすために、値を大きくしてもよい。4G以上の値が安全。歴史的には、大きなログファイルの操作の欠点としてクラッシュリカバリの時間が長くなることが言われてきたが、5.5や5.6でこの点は大幅に改善された。

 とのこと。

サイト自体に色々なブログの記事の情報が沢山あって、毎時3回もinsertの処理をしているため、記事を収集する際にサイトが重くなるため変更しました。実際変更したら、サイトのパフォーマンスがだいぶ良くなりました。

 

で、なんでこの記事を書こうかと思ったかというと、単純にmy.cnfを変更してMySQLを再起動するだけだとエラーになってしまうから。

MySQLのログファイルを大きくすると処理が軽くなる理由は、InnoDBは、ログ先行書き込みをしていて、データベースに対する変更は全て実際の操作の前にログに記録されているのだそうです。

なので、ログを安易に消すと、書き込む予定のデータがなくなったり、ログのサイズが小さいと一時スペースが小さいのと同じでパフォーマンスが悪くなるのだそうです。

 

で、どうしたらいいかというと、このログファイル(ib_logfile0/ib_logfile1)を移動して、MySQLを再起動するとうまく再起動できるようになります。

mv /var/lib/mysql/ib_logfile* /home/

みたいな感じです。このログファイル、起動がうまくいかなかった際に元の場所に戻すので、消さないでください。

復旧できなくなるのでw。

 

このブログ自体何を書くようにしようかと思っているのですが、技術ブログではないので、ここら辺で。

書くことないので、技術ブログにするかアフィリエイトブログにするのか色々と思案しています...。