MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
第101回 InnoDBバッファプールの状態を確認するさまざまな方法 | gihyo.jp
InnoDBをチューニングする際に、真っ先に確認するものといえばInnoDBバッファプールがあります。これは頻繁にアクセスされたテーブルデータやインデックスデータをキャッシュし、リクエストを高速に処理するための重要な機構です。基本的にはバッファプールは大きな値を設定するようにガイドされています。データサイズがすべてバッファプールサイズに収まるように設定すると安定したサービスの提供が可能です。 バッファプールサイズよりもデータサイズが大きい場合は、ディスクへのアクセスが頻発して運用しているサービスに影響があることもあります。しかし、サービスが頻繁にアクセスするデータは決まっていて（過去のデータにはほとんどアクセスしない）、そのデータがすべてバッファプール上にあるために問題なくサービスを運用できることもあります。このように、サービスの特性によるワーキングセットが重要になります。 今回は、バ
Innodb Deep Talk #2 でお話したスライド
5. 2006年 2006.8 Peter Zaitsev、Vadim Tkachenko が MySQL AB(High Performance Group)離籍して Percona 設立 ※当時、S商情報システムのS原さんがMySQLの性能の将来を危惧していた。 ※S原さんは日本に有力なハッカーが居ないことも当時危惧していたと思う。 （世界のMySQLコミュニティにおける日本ユーザーのプレゼンスが低くなってしまうから） 多少影響を受けた。 2006.8 Bug#15815: Very poor performance with multiple queries running concurrently (http://www.mysqlperformanceblog.com/2006/07/28/returning-to-innodb-scalability/) の議論に参加 ※これが
MySQL関連のパラメータ(主にInnoDB)について - hiroi10のブログ
このエントリはMySQL Casual Advent Calendar 2015の10日目のエントリです。 先日のMySQL Casual Talks Vol8で@karupaneruraさんがパラメータの振り返りのような発表をされていたので、昨今あまり書かれなくなったMySQLに絡む設定パラメータについて書きます。それなりのメモリ(32GBとか)やSSDとか使ってる事を前提にしたような内容となります。 依存して変更した方が良いパラメータもあるので内容が前後に飛びますがご容赦下さい。またソースコードをがっつり読んだわけではなく、ベンチマーク中の挙動から推測している箇所が多分にあります。MyISAMのテーブルがサービス用データベースに同居する事を考慮していません。 結構突貫で書いているので後から微妙に修正する可能性があります。 InnoDBのパラメータ innodb_buffer_pool_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
さいきんの InnoDB Adaptive Flushing （仮）