muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
Linuxシステム構築Tips - HDDベンチマーク手順＋性能測定結果一覧（hdparm,dd,bonnie++）
ハードディスクのIO性能を左右する要素 システムのパフォーマンスが思うように上がらない場合、ハードディスクのIO性能がボトルネックになっているケースが多々あります。下記の項目によってハードディスクのIO性能は左右されますので、性能面の問題が発生することを未然に防ぐという観点では、サーバ環境の設計段階でこららの項目を必ず計画、確認しておきたいところです。 ハードウェアRAID構成 ソフトウェアRAID構成 HDDの性能 （スピンドル回転数、シーク時間等） パーティションの位置 （内周部/外周部） チップセットの性能 RAIDコントローラー、SCSI／IDEアダプターの性能 BIOS設定 Linuxカーネル ドライバーのバージョン ファームウェアのバージョン ファイルシステム NFS設定 （NFSマウント領域の場合） HDDベンチマーク手順 システムの環境構築が完了した
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
LinuxのファイルI/Oチューニングに使える「Iotop」 - GIGAZINE
ファイルI/Oがパフォーマンスのボトルネックになっていることはなんとなくわかるが、具体的にはどうなっているのかを知りたい場合、通常はvmstatやiostatなどを使うわけですが、この「Iotop」を使うと、いわゆるtopコマンドのような感じで表示してくれるので、ケースによってはかなり状況を把握しやすくなり、非常に役立ちます。 詳細は以下。 Iotop's homepage http://guichaz.free.fr/iotop/ 中身はPythonで書かれており、Python2.5以上とLinuxのカーネル2.6.20以上で動作します。 画面はこんな感じ あと、ディスクI/O関連は以下のページも参考になります。 Linux I/O のお話 write 編 - naoyaのはてなダイアリー Linuxチューニング 第2部第3回 ハード・ディスクをチューニング（その1）：ITpro
MySQL 高速化メモ
●はじめに MySQLでSELECT文が遅いと感じたり、INSERT処理だけで１日かかった！なんて事ありませんか？ そんな時は本ページのメモを参考に高速化してみてください。 ちょっとした設定だけで１日かかる処理が数分で終わる（！？）なんて事も。 ぜひお試しあれ。 ●SELECT文の高速化 １．テーブルを分ける。 同じ構造のテーブルをいくつかに分割する。例えば、wordというテーブルがあるとすると、 ja_word,en_wordなど国別に分割したり、word2005,word2006など年月日で分割してみる。 ２．テーブルにインデックスを設定する。 create index インデックス名 on テーブル名 (フィールド名); 文字列の場合はインデックスに設定する文字数を指定可能。 create index インデックス名 on テーブル名(フィールド名(要素数)); 私がやってみた感じで
cles::blogのチューニング
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 偽装ロボット来襲 :: やっと採録に » 2004/11/03 cles::blogのチューニング mysql tuning 39 8へぇ さすがに昨日の一件には参ってしまったのですが、最近MySQLの負荷が高すぎることは確かなので少しチューニングをしてみることにしました。 その昔、Oracleバリバリだったときにはチューニングばかり勉強したりしていた時期もあったので、チューニングで何をしなければならないかというのは大体わかっているつもりです。今回はそのときの経験を生かして、MySQLのチューニングに挑戦してみます。 † まずはボトルネック解析から まずはなぜ遅いのかという原因を絞り込みます。これはDBのチューニングに限らず全てのチューニングという作業に共通したものですよね。これをやらずにチュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kndb.jp
[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)