タグ

ブックマーク / sh2.hatenablog.jp (5)

  • うるう秒のあとにMySQLなどのCPU使用率が高騰する件について - SH2の日記

    2012年7月1日のうるう秒のあとに、MySQLJavaなどのCPU使用率が高騰する事象が報告されています。 CPU %user %nice %system %iowait %steal %idle 08時30分01秒 all 0.02 0.00 0.02 0.04 0.00 99.91 08時40分01秒 all 0.02 0.00 0.02 0.08 0.00 99.88 08時50分01秒 all 0.02 0.00 0.02 0.03 0.00 99.92 09時00分01秒 all 0.11 0.00 0.13 0.04 0.00 99.72 09時10分01秒 all 23.02 0.00 29.09 0.11 0.00 47.78 09時20分01秒 all 23.11 0.00 29.08 0.06 0.00 47.75 09時30分01秒 all 22.85 0.00

    うるう秒のあとにMySQLなどのCPU使用率が高騰する件について - SH2の日記
  • dstat2graphs - dstatのログをグラフ化するツール - SH2の日記

    dstatが便利ですね。 dstat が便利 | Carpe Diem dstatの万能感がハンパない - (ひ)メモ 私は特に--outputオプションでCSV形式のログファイルを出力できるところが気に入っています。番環境ではきちんとした監視ツールを使うと思いますが、開発・検証環境で手早くOSリソース情報を可視化できるので重宝しています。 それでもExcelやCalcでグラフを描くというのは何度も繰り返すと面倒なもので、 探したのですが見つからなかったので、連休を利用して作ってみました。 dstat2graphs - dbstudy.info サンプル1 (前回の負荷テストにおけるクライアントのグラフ) サンプル2 (サーバ) サンプル3 (KVMホスト) いくつか注意点があります。 dstat -tvfn --output log.csv 1しか受け付けないという割り切った作りです。

    dstat2graphs - dstatのログをグラフ化するツール - SH2の日記
  • INDEX FULL SCANを狙う - MySQL Casual Advent Calendar 2011 - SH2の日記

    2011年8月のkazeburoさんのエントリに対する解説記事です。結論から言うとkazeburoさんの案に賛成なのですが、日はどうしてそうなったのかというところを確認していきたいと思います。記事はMySQL Casual Advent Calendar 2011の17日目のエントリです。16日目はakira1908jpさんでした。 当時の内容を覚えていない方は、先にkazeburoさんのエントリをご一読ください。また、テストケースがGitHubに公開されていますのでカジュアルに再現試験をすることも可能です。 Covering Index と self-joinMySQL - blog.nomadscafe.jp kazeburo's gist: 1150842 - Gist 問題のSQLをチューニングするには、MySQLがインデックスに対してどのようにアクセスするかという点につ

    INDEX FULL SCANを狙う - MySQL Casual Advent Calendar 2011 - SH2の日記
    sugyan
    sugyan 2011/12/18
    あとでジックリ、、
  • MySQL innodb_flush_method = O_DIRECTの検討 - SH2の日記

    MySQL InnoDBのパラメータでinnodb_flush_methodというものがあります。これはUNIX/Linuxにおいてデータファイル、ログファイルの読み書き方式を指定するためのもので、マニュアルの13.6.3. InnoDB Startup Options and System Variablesによると以下の3種類の設定が可能とされています。 無指定(fdatasync):デフォルトの設定です。特別なフラグなしでファイルをオープンし、書き込み時にfsync()を行います。 O_DSYNC:データファイルについてはfdatasyncと同じです。ログファイルについてO_SYNCフラグをつけてファイルをオープンします。 O_DIRECT:データファイルについてO_DIRECTフラグをつけてファイルをオープンします。ログファイルについてはfdatasyncと同じです。 今回はこのパ

    sugyan
    sugyan 2011/10/07
  • MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記

    MySQLでテーブルへのカラム追加、インデックス追加やテーブルの再編成などを行うと、その間テーブルに共有ロックがかかってしまいます。そのためこれらのメンテナンス処理は、通常利用者の少ない深夜早朝帯にサービスを止めて実施する必要があります。日はそれを無停止、オンラインのままでできないかという話題です。 基的なアイデア メンテナンス対象の元テーブルをコピーして、作業用の仮テーブルを作ります 仮テーブルに対して、カラム追加などの変更を加えます その間、元テーブルに対して行われる更新処理について差分を記録しておきます 仮テーブルの変更が終わったら、記録しておいた差分データを仮テーブルに反映します 差分データの反映が終わったら、元テーブルと仮テーブルを入れ替えます これと似たようなことを考えた方は結構いらっしゃるのではないでしょうか。ただ、言うは易し、行うは難しです。整合性がきちんと取れるかどう

    MySQLでサービス停止のないALTER TABLEの検討 - SH2の日記
    sugyan
    sugyan 2010/07/04
  • 1