Archive for the ‘linux’ Category

    はてなブックマーク - ITインフラ勉強会@福岡でISUCONの予習をしてきました
    このエントリーをはてなブックマークに追加

    Fusic 平田です。
    会社で「ISUCONがんばる」って言っちゃったので、仕事の合間をぬってITインフラ勉強会に参加してきました。
    fukinfra.doorkeeper.jp/events/5367

    他の方のエントリは以下。
    第6回ITインフラ勉強会@福岡に参加してきました。 – 肉まん始めました
    【福岡】インフラ勉強会で ISUCON を疑似体験してきました。 – komiyakの通り道
    第6回 ITインフラ勉強会@福岡 (ISUCON夏期講習のAMIで、もくもくチューニング)を開催しました – まつざきの技術メモ

    1時間ほど遅刻して着いてみたら既に2チームのvsが進行していたので、ひとりチームでもくもくチューニングしてましたすみませんすみませんすみません。

    以下ざっくりやったこと。
    HeigiSQLでexplain結果眺めながら、MySQLのインデックスをぺたぺた
    ・ログとdstatの結果を流しつつ各ページの動きを確認
    ・/ticket/の描画とソースみてこりゃ重いなーと思って、普段使ってるとおりvarnishを突っ込む
    vclは↓くらいで、単にpost来たらキャッシュ消すくらいで。
    ※ リクエスト眺めていたらpostが連続で来てたりもしていたので、キャッシュの運用についてはもっと賢いやり方があるだろうなーと思いつつ。

    backend default {
      .host = "127.0.0.1";
      .port = "6000";
    }
    sub vcl_recv {
        if (req.request == "POST") {
            ban("req.url ~ /");
            return (pass);
        }
        elseif (req.request != "GET") {
            return (pass);
        } else {
            return (lookup);
        }
    }

    ・dstatで見る限りアプリ側に余裕が見られたので、starmanのworkerを30まで増やす
    ・メモリよりI/Oのほうがきつそうだったので、varnishのキャッシュ先をファイルからメモリに変更
    → /etc/sysconfig/varnish内で「VARNISH_STORAGE=”malloc,4G”」と変更
    ・たまに計測がこけて、理由が/admin/order.csvのデータの中身の不整合だったので、order.csvへのリクエストはキャッシュしないよう変更
    ・POSTをもっとさばくために、/admin/set_cacheという別アクションでキャッシュ作ったのち、/buyの処理をキャッシュで軽減できるように修正
    → の途上で時間切れ
    とあいなりました。

    で、結果としては

    とスコア11万程度までは減りました。
    計測具合からvarnish導入で一気にスコア減るだろうなーというのは予測通りでしたが、DBのチューニング具合やアプリ改修具合については全然足りていなかったですね。
    計測する→どうする、の「どうする」武器をいろいろ持っておかねば、というのが喫緊の課題です。

    参加していた方々の話を聞いていると
    ・MySQLのチューニングをカリカリやっていた方
    ・カーネルパラメータなど見直していた方
    ・Webサーバの入れ替え検討とか、検討はともかくApache入れるぜ!とか
    などと、やっぱり人によって狙いが違うなーというのが面白かったです。

    で、第3回ISUCONの予選が10/5,10/6と決まりまして。
    さっそくFulab(Fusic x nulab)なチームで登録しております。
    isucon2013.kayac.com/qualifier_round/2
    参加される方々が(自チームの他お二人含め)非常に強力でどうしたもんかとプルプルしておりますが、どうか皆様お手柔らかにお願いいたします。。。

      はてなブックマーク - インフラ勉強会@福岡でWakameについて話してきました
      このエントリーをはてなブックマークに追加

      Fusic 平田です。
      インフラ勉強会@福岡に参加してきました。
      で、行くなら喋ろうってことでWakameのお話。

      ※ Ustの録画をしそこねておりました。大変申し訳ありません。。。
      補足情報は、以下のような感じです。
      ・OpenFlow対応が追加されている
      # 参考: www.slideshare.net/yasuhiro_yamazaki/openflow-in-iaas-wakame
      ・対応ハイパーバイザにESXiとOpenVZが追加された
      ・Gentooへのインストールスクリプトが追加された

      Wakameいいよーいいよーってのをもっとわかりやすく説明するために、いろいろ実験中です。
      これについてはまた別途エントリ書くようにします。

      他の方の発表は以下の通り。

      Spring_MTさん: MySQL Casual Talks Vol.3の話、など
      # 参考: spring-mt.tumblr.com/post/21638089137/mysql-casual-talks-vol-3-lt
      参加しましたって話と、それに絡んでMySQLやRailsの話。
      いろいろ勉強会やりたい!と画策してらっしゃるようで、楽しみにしております。

      take_3さん: 東京こわいいろいろ勉強会に参加した話などなど
      特に場が騒然としたのが、x86/x64最適化勉強会の話。
      最近のCPUだと、慣例どおりのコード書いてたら分岐予測でコスト浪費するんだよってなにそれこわいすごいってな雰囲気でした。
      あとは、「などなど」とまとめましたが多方面にわたるいろいろなお話。

      あとはバックアップの話とか冗長化の話とか、あれこれいろいろ話してそのまま懇親会に移動。
      技術の話やらそうでもない話やらで大いに盛り上がりました。Excelは言語だよね、とか。
      次回もぜひ参加させていただきたいですね。

        はてなブックマーク - RAID5がiowait出まくりで遅いので、stripe_cache_sizeを増やした話
        このエントリーをはてなブックマークに追加

        あけましておめでとうございます。
        Fusic 平田です。
        新年気分とは何の関係もない、RAIDのお話です。

        年末にXenサーバのディスクがお亡くなりになったので、ディスク換装してCentOS6.2でKVMサーバを再構築。
        で、ディスク4本なのでどうしようかなーと思いつつRAID5を組んではみたのですが、iowaitが収まらない。
        特に書き込みのほうが苦戦しているようで、仮想サーバがちょっと頑張るたびにロードアベレージが10越えたり。
        これじゃ使い物にならんなあ最悪RAID10で組み直したほうがいいかなあ。。。とか悩んでいる時に以下の記事を発見。
        peterkieser.com/2009/11/29/raid-mdraid-stripe_cache_size-vs-write-transfer/
        ※ 記事中のスクリプトまでは試していません。
        書き込みで苦しんでいるならstripe_cache_size増やすと捗るよ!ってことでやってみました。

        サーバスペック:
        Xeon X3230 (4コア) メモリ8GB HDD1TB*4(RAID5, software raid)

        対象のRAIDアレイ(今回はmd3)に対して

        # echo 8192 > /sys/block/md3/md/stripe_cache_size

        と実行して値を書き換えます。
        resyncがかかってしばらくしたら完了したので、あとはtopでだらだら流して様子見。
        仮想サーバ側で何度か負荷の高い処理をしてみてもロードアベレージがさほど上がらなくなったので、とりあえずはよし。

        あとはOS再起動しても動くように、ruleを追加。

        # cat <<EOS > /etc/udev/rules.d/80-md-stripe-cache.rules
        SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"
        EOS

        今のところ、これで快適に動作しています。
        問題が起きないか、最大限の関心を持って注視を続けることが当面の隠れ業務です。

        ・・・ていうか、そもそもRAID5使わないとかsoftware raid使わないとか別の方策あった気もします。

        追記:
        8192でも微妙につっかえる場面が見受けられたので、結局32768(最大)まで増やしています。
        ページサイズ(=4KB)×stripe_cache_size×ディスク数分のメモリ使うので、あんまし増やしすぎるのも嫌だなーと思ったんですが。
        メモリで困る前にCPU数で困りそうな気がしたのと、メモリは最悪増設できるしなーってことで、とりあえずはこのままで。