タグ

ブックマーク / hirose31.hatenablog.jp (8)

  • 実録MySQLのチューニング 春の陣 - (ひ)メモ

    long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです! 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソースい潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,

    実録MySQLのチューニング 春の陣 - (ひ)メモ
  • IPアドレスブロックを集中管理する方法と、その活用法 - (ひ)メモ

    やりたいこと 携帯3キャリアのIPアドレスブロックは比較的頻繁に変わるので自動更新したい 自宅やオフィスその他のIPアドレスは、変わることがあまりないので手動管理でいい これらIPアドレスブロックの情報は、後述する通りいろいろなところで使いたい 即ち、いろいろな形式で表現したい このように、頻度の差こそあれ、IPアドレスブロックは増減したり新しいブロックが追加したりするので、簡素な機構で包括的な管理をしたい。 実現方法 スクリプトを2つ書きました。いずれもgithubにあります。 http://github.com/hirose31/cidr-manager 図も用意しました。 update-mobilejp-cidr キャリアのサイトをスクレイピングして、指定されたディレクトリにその情報を書き出します。 その形式は、1行1アドレスブロック、コメントは "#" です。 $ cat plai

    IPアドレスブロックを集中管理する方法と、その活用法 - (ひ)メモ
  • 実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - (ひ)メモ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901db902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n

    実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - (ひ)メモ
  • YAPC::Asia 2009で「『Ficia』インフラとPerlにまつわるエトセトラ」というタイトルでしゃべってきました - (ひ)メモ

    YAPC::Asia 2009 第一日目で「『Ficia』インフラとPerlにまつわるエトセトラ」というタイトルでしゃべってきましたのでその資料を公開します。 『Ficia』インフラとPerlにまつわるエトセトラView more documents from Masaaki HIROSE. 他の方のスライドも http://www.slideshare.net/event/yapcasia-2009 から参照できるようでっす。 以下、今回のトークの内容で参考にさせてもらったURLのリストです。 Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる - naoyaのはてなダイアリー http://d.hatena.ne.jp/naoya/20080212/1202830671 mod_perl における C10K Problem, 竹迫 良範 http

    YAPC::Asia 2009で「『Ficia』インフラとPerlにまつわるエトセトラ」というタイトルでしゃべってきました - (ひ)メモ
  • 安全に一気にファイルの内容を書き換える - (ひ)メモ

    ファイルを書き換えるときに、単純に open, write, close だと、そのファイルの性格にもよりますが、問題になるケースがあります。 書き込み処理中に異常終了しちゃった 例えば open my $fh, '>', '/foo/bar'; print $fh gen_header(); print $fh gen_section_1(); print $fh gen_section_2(); # ← die print $fh "# EOF\n"; close $fh な処理で、get_section_2 が異常終了してしまうと、その後書き込まれるはずのものが書き込まれずファイルの内容が中途半端になってしまいます。(まぁでもこのケースはエラー処理をちゃんとやれば回避できますね) 書いている途中で読まれちゃった サーバ名一覧のような定義ファイルや、毎回読まれるタイプの設定ファイルの場

    安全に一気にファイルの内容を書き換える - (ひ)メモ
  • コードポケット - アプリケーションをささっと作るコツ - (ひ)メモ

    誰に教えられたのでもないのですが、ぼくは冬眠前のリスのようにコード片を溜め込んでいます。 コード片とは、ライブラリにするほどまとまった大きさではない、数行〜十数行のコードのことで、溜め込んだコード片は、アプリケーションやツールを作るときに使っています。 例えば「Perlでメール送るのどう書くんだっけかな」とか「Pythonでファイル開いて全部読むのどう書くんだっけかな」とかというときに、溜め込んだ中からコード片をさっと取り出してコピペした後、なじむようにちょっと修正して使っています。 コードポケット コードを溜め込んでいるディレクトリをぼくは「コードポケット」と名付けていて、コード片を取り出すことを「ポケットからコードを取り出す」と呼んでいます。先日、知り合いが似たようなことを実践していて、その人は「コードスケッチ」と呼んでました。いい名前ですね。 ぼくの場合、コードポケットは ~/lan

    コードポケット - アプリケーションをささっと作るコツ - (ひ)メモ
  • 慣習を気にせずsyslog-ngの設定をしてみた - (ひ)メモ

    たいていのsyslogのデフォルトの設定だと、 同じログが結構な量、複数のファイルに記録されて(IO負荷的、ディスクサイズ的に)無駄だなぁ 日付のフォーマットが機械処理しづらいなぁ ローテートがめんどいなぁ と思ってたので、今つくってる環境では慣習を気にせずに syslog-ng (v2.0.9) の設定をしてみたのでそのメモです。 不要なログは記録しない options { ... mark_freq(0); stats_freq(0); ... } 日付の形式を変える options { ... ts_format(iso); ... }これで、こんなの Dec 19 16:44:20 HOST ...から、こんなの 2008-12-19T14:07:52+09:00 HOST ...に変わります。 facilityごとにわける facilityごとのfilterを作る。 destic

    慣習を気にせずsyslog-ngの設定をしてみた - (ひ)メモ
  • (ひ)メモ - そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか

    チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか つっこみどころが満載スギなのは脇においておいて、金をかけないなら、DNSラウンドロビンじゃなくて、せめて、件の記事でも紹介されている Apache 2.2のmod_proxy_balancer か、Apache 2.2じゃなくても使えるreverse proxy系の実装たち、 POUND mod_backhand Perlbal を使うべきでしょう。 んで、「L7ロードバランサ(要はreverse proxy)なんていらねっす。セッション? んなのmemcachedでシェアすりゃいいんじゃん。その方がスケールアウトしやすいしー」という向きには、LinuxでL4のロードバランサするのをオススメでします。まともなL4ロードバランサが手に入るのに、金銭的コストはゼロですってよ、オクサン! Linux Virtual Serve

    (ひ)メモ - そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか
  • 1