New Relic Now+ New Relic’s most transformative platform update yet with 20+ product launches.
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
挿入の速度を最適化するには、多くの小さな操作を 1 つの大きな操作に組み合わせます。理想的には、単一の接続を作成し、多くの新しい行のデータを一度に送信し、すべてのインデックスの更新と一貫性チェックを最後まで延期します。 行の挿入に必要な時間は、次の要因によって決まります。ここでの数はおよその割合を示しています。 接続: (3) サーバーへのクエリーの送信: (2) クエリーの解析: (2) 行の挿入: (1 ×行サイズ) インデックスの挿入: (1 ×インデックス数) クローズ: (1) これには、テーブルを開く初期オーバーヘッドを考慮に入れていません。これは同時実行クエリーごとに 1 回実行されます。 テーブルのサイズによって、log N だけインデックスの挿入が遅くなります (B ツリーインデックスであるとして)。 次の方法を使用して、挿入を高速化できます。 同じクライアントから同時に
https://github.com/rackerhacker/MySQLTuner-perl MySQLTunerはMySQLのチューニングを診断してくれるアプリケーションです。 基本的なパフォーマンスチューニングのヒントをわかりやすく表示してくれます。 MySQLのチューニング設定に不安な方や、はじめてMySQLをさわる方は試してみると良いでしょう。 ライセンスはGNU GPLで無料で使えます。 検証環境 CentOS 6.3(64bit) MySQL 5.5.28 MySQL 5.5をインストール MySQL 5.5をインストールします。 # wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm # wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86
1,164,127件のdatetime型のカラムに対してインデックスを張った。（所要時間2時間5分） インデックス前のSELECT: 68.9秒 インデックス後のSELECT: 1.5秒 Fedora4/Celeron 2.2GHz/512MB mysql> desc table_hoge; +--------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------------+--------------+------+-----+---------+-------+ ************************************************************** | date | dat
週に一度か二度、Bacteriaが管理するサイトは大規模なプロモーションをすることがある。 140万通ものメール広告でもってやるわけだけど、そのレスポンスが強烈に重い。 サーバが悲鳴を上げているのがわかる。 ちょっと重すぎるよこれどうなってんのってことで、MySQLのslow_queryで分析をはじめることにした。 すると一番最初に引っかかったのが下記の事例だった。 MySQLにクエリを投げる場合、Explainして最も見たくないのがUsing file sortの文字だ。 file sortは負荷がかかると、Using Temporaryまで出てき始める。 こうなるともうお手上げで、クエリは結果を表示するためにディスクアクセスを繰り返し、速度は低下の一途をたどることになる。 file sortが発生するときは、たいてい決まっているがorder byを使うときだろう。 そりゃそ
バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く