ISUCON6 で優勝しました : DSAS開発者の部屋
@methane です。タイトルの通り、 ISUCON でとうとう優勝してきました。 チームメンバーは、(予選と同じく) @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) でした。 私は予選のときはガッツリとアプリを書いていたのですが、本戦では netstat -tn (←老害), top, dstat -ai, sudo perf top などをみつつ指示をだしたり、方針を決めたり、完全に未経験だった node.js & react.js 対策をしたりが主な仕事で、あとは序盤のインフラのタスクが大量にあるときに MySQL を docker から外して基本的なチューニングを入れたり Go を100行程度書いただけです。 結果的には優勝できましたが、メンバーの2人がよく準備し本番でも実力を発揮してくれたのに対して 僕の戦略ミスで中盤から全くスコアを上げられなかったので
VirtualBoxのファイルシステムを10倍速くする 〜 read ahead編 〜 : DSAS開発者の部屋
vboxsfを速くするために頑張る記事の３本目です。 前回は、vboxsfでpage cacheを使えるようにして高速化を実現しました。 今回は、VirtualBoxのファイルシステムvboxsfと、VM上で使われているファイルシステムext4との違いを調べていきます。 もちろんvboxsfとext4では、ファイルシステムより下の構造が全く違います。 またvboxsfの場合、NFSと同様に複数のクライアント(vboxsfの場合、ホストOSやその他のゲストOS)からアクセスされるため、ext4ほどキャッシュを多用できないかもしれません。 とはいえ、何かしらvboxsfを速くするヒントが見つかるのではないか？と思い調べてみました。 比較してみる とりあえず、vboxsfとext4でどの程度違いが出るのか調べてみました。使っているのは、前回の修正を取り込んだpage cache付きのvboxsf
ISUCON 5 決勝戦で負けてきました : DSAS開発者の部屋
lily white というチームで ISUCON 5 決勝戦に出場してきました。 終盤が、結果 fail でスコアなしに終わってしまいました。 チームメンバーは僕の他に、新人の @gam0022 と、学生の @koki_cheese さんです。 二人とも経験が殆ど無い状態だったので、 @gam0022 には主に MySQL を、 @koki_cheese さんには アプリ側で僕が予選でやったことを練習してもらい、少しでも僕が戦略的に動ける余裕を作るという作戦でした。 結果的に、DB が MySQL でなかった、 @koki_cheese さんが練習時間をあまり取れなかった、 僕が2人を信頼しきれずアプリの実装に回ってしまい、戦略的な所ができなかったために、実力を発揮できずに終わってしまいました。 11:00 ~ 12:00 初回ベンチ実行 下回りは @gam0022 にまかせていたのです
VirtualBoxのファイルシステムを10倍速くする 〜 page cache編 〜 : DSAS開発者の部屋
vboxsfを速くするために頑張る記事の２本目です。 前回は、findコマンドが遅いことを調べ、速くすることができました。 今回は、VirtualBoxのファイルシステムvboxsfと、VMWareのファイルシステムvmhgfsの違いをもっと調べていきます。 vboxsfとvmhgfsの速度を比較している記事としては、Comparing Filesystem Performance in Virtual Machinesが、わかりやすくまとまっていました。 この記事を見ると、 sequential readで、vboxsfでは100MB/s、vmhgfsでは500MB/s random readで、vboxsfでは100MB/s、vmhgfsでは7GB/s と、速度の差が大きいことを指摘され、さらには、 Because the deviation of the VirtualBox thr
ISUCON5 予選通過しました (@methane編) : DSAS開発者の部屋
9/27 の ISUCON 予選2日目に参戦してきました。 KLab から参加した6チームのうち予選通過できたのは私が率いる lily white だけ、それも通過組の中で下から3位とかなり厳しい結果になってしまいました。 本格的な練習は新人が予選で ISUCON の難しさを実感してからにしようと思っていたのですが、今年は予選のレベルが想像以上に上がっていて、 お題のアプリも本戦さながらの規模、複雑さになっていて、もう完全に舐めてましたごめんなさい。出題側本気出しすぎです。本当にお疲れ様でした。 考察と感想戦はベンチマーカーが公開されてからにするとして、当日の流れを覚えているうちに振り返ってみます。 (時間とスコアをメモってなくて集計サイトもクローズしてしまったので、文中の時間とスコアはうろ覚えのものです) 準備 lily white は私以外に新卒の @gam0022, そして Twit
VirtualBoxのファイルシステムを10倍速くする ~ find編 ~ : DSAS開発者の部屋
もう、あって当たり前というところまで浸透してきた仮想環境、みなさまは何をお使いでしょうか? 私の周辺ではVirtualBoxがよく使われています。 典型的な使い方としては、 以下のような感じです。 ホストOSには、mac/windowsをつかう ゲストOSには、Linuxを使う 共有フォルダを使って、ホストとゲストでファイルを共有する その中でも地味に重要なのが共有フォルダ。 共有フォルダとは、ホストOSのファイルシステムをゲストOSからマウントするための、VirtualBoxが提供している仕組みです。 しかし便利な反面、ファイルアクセスが非常に遅いという声をよく聞きます。 findが終わらないとか、git statusが遅すぎるとか... この問題への対策を探してみると、下記のような物がみつかります。 vboxsfでなくNFSなど別のファイルシステムを使う VirtulaboxではなくV
Go ではエラーを文字列比較する？という話について : DSAS開発者の部屋
Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか？ 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の（文字列比較によらない）エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、
Goのdatabase/sql.Stmtのスケーラビリティを改善しました : DSAS開発者の部屋
先日、 Goに初めて私のパッチが取り込まれ 、コントリビュータに仲間入りしました。 このパッチは、 database/sql.Stmt をヘビーに使った時に性能がだいたい16コア以上のコア数にスケールしないという問題を解決するものです。 こういった問題をどうやって調査するのかと、Goにパッチが取り込まれるまでの手順を紹介します。 背景 私は TechEmpower の FrameworkBenchmarks という、いろんな言語/フレームワークで同一のアプリを作ってベンチマークするというプロジェクトで、主にPython関連のメンテナをしています。 Goにも興味があるので、Ginというフレームワークを追加したりコードレビューに参加したりしています。 2014-05-01 に行われた前回のベンチマーク Round 9 では、 PEAK Hosting が実行環境に加わりました。この環境は、デュ
#ISUCON 4 本戦で5位でした (lily white) : DSAS開発者の部屋
結果発表 にある通り、 KLab から参加した3チームは、 2チームが8000点前後の過密地帯で、 lily white だけがほんの少し飛び出て5位でした。 1位、2位が Cache-Control 勢、 3, 4 位が Public/Private ネットワーク束ねた勢だと思われますが、 lily white は API は public, 動画は private と使い分けたため、 片側の帯域を使い切った 過密地帯から少し上に出ることができて5位でした。 以下、時系列でどんな事をやっていたのかを残していきます。 前日: 休み、モニタリング環境準備 実は ISUCON 本戦への参加をカンファレンスでの講演と同じ休出扱いにしてもらって、 前日は振替休日として家族サービスと休息に割り当てました。 おかげで去年や予選時と違って途中で集中力を切らさず最後まで頑張れました。 一応モニタリングツー
ISUCON4で本戦通過できました（Printemps参戦記） : DSAS開発者の部屋
ISUCON4の予選結果が確定しまして、KLabからは3チームが本戦通過するという結果になりました。1チームについては「ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記)」で既にお伝えしていますが、別チームの雰囲気もまとめてみます。 我々はPrintempsというチーム名で予選1日目に参加しました。最終スコアは40418点で、全体16位での通過となりました。参加メンバーは@hnw、@shohei909、@dimoltoの3人、利用言語は全員が確実に読み書きできるPHPでいくことにしました。 ちなみに、我々は1インスタンスで3人が同時に作業する方針でした。@shohei909がアプリの改修、@dimoltoがミドルウェアの設定など、@hnwがstrace職人やその他モニタリング、という役割分担で考えていました。 9時30分 会社に集合。デ
ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
Android/iOS向けテストアプリ配信ツール 「EMLauncher」を公開しました : DSAS開発者の部屋
先日、TestFlightのAndroidサポート終了、Appleによる買収といったニュースが世間を騒がせましたが、皆さんテストアプリの配信はどうしていますか？ KLabでは自社製のテストアプリ配信ツール「EMLauncher」を使用しているのですが、せっかくなのでOSSとして公開することにしました。 https://github.com/KLab/emlauncher 今すぐ試す 今すぐ試したい方のために、セットアップ済みのAWS EC2イメージを用意しました。 ami-9b295f9a EMLauncher Sample インスタンスを起動後、設定ファイルのAWSアカウント情報を編集し、S3のバケットを作成してください。 (設定の詳細はconfigディレクトリのサンプルをご覧ください) /home/ohoflight/emlauncher/config/emlauncher_confi
ISUCON3 で惨敗してきました : DSAS開発者の部屋
KLab からは 「ぜかまし」 が ISUCON 3 の本戦に参加していました。 メンバーは私 (@methane) と、 @tenntenn, @hasi_t です。 結果は順位なし (計測時に fail が多かった) と、惨敗というかそれ以前の問題です。 結果は散々だったものの、設問は非常に完成度が高く、とても楽しめました。 作問してくださった面白法人KAYAC様、主催してくださったLINE株式会社様、 環境と懇親会を提供してくださったデータホテル株式会社様、ありがとうございました。 特に問題作成に関わられた方、本当にお疲れ様でした。 それでは、どうしてこんな結果になったか、当日の様子を振り返ってみます。 10:00 会場着 3人とも開場時間前後には到着して、ホワイトボードがある会議室を抑えました。 (とはいえ、ホワイトボードは同じ会議室の人にも見えてしまうので、結局使いませんでした。
ISUCON 3 予選参戦記 : DSAS開発者の部屋
10/5 土曜日はISUCON 3 の予選一日目に参加していました。 KLab からは 2 チームが、「ぜかまし」は Go, 「真面目系社内ニート 」は PHP での参戦でした。 私は「ぜかまし」で、結果は2位で本戦進出が決まりました。 その時のコードがこちらになります methane/isucon3-qual-go 振り返り まずは、 tmux に残っていたベンチマーク履歴をご覧ください 2013/10/05 17:33:46 Score: 2485.3 2013/10/05 17:35:08 Score: 2021.4 2013/10/05 17:36:24 Score: 1786.6 2013/10/05 17:43:33 Score: 13635.2 2013/10/05 17:46:20 Score: 13882.8 [OK] 結果を管理サーバに送信しました 2013/10/05
負荷試験ツール「グリーン破壊」を公開しました : DSAS開発者の部屋
takada-at 作の インターネット破壊 を Python + Gevent で書きなおした グリーン破壊 を公開しました。 なんで作りなおしたのか インターネット破壊は Ruby + rev 製なのですが、 Ruby のバージョンや gem まわりなどが Ruby に詳しくない人にとっては複雑で、セットアップに数時間かかることがありました。 また、インターネット破壊が使っている rev というライブラリはオワコンらしいです。 さらに、 Rev を使ってイベントドリブンの書き方をしているために複雑で、カスタマイズや デバッグが難しいという問題もありました。 結局、インターネット破壊が期待通りに動かなくて調査していた時に、調査するよりも Gevent で書きなおした方が早い！と思って書き直してしまいました。 パフォーマンス グリーン破壊は内部でコネクションプールを利用しており、 keep
ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋
ちょうど１年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。 ログからは見えてこないもの 「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。 Webアプリケーションの処理に時間が掛かっている DBサーバに投げたクエリーの応答が遅い サーバの処理能力を超えている などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。 一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。 あるサイトのある日の出来事 つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サ
DSAS for Social での MySQL のボトルネックと今後の方針 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の5日目です。 @methane による MySQL を骨までしゃぶるチューニングシリーズ (シリーズ名は今考えました)のまとめとして、現在の DSAS for Social の MySQL のリアルな性能値や直面しているボトルネックを赤裸々に公開 してしまいます。 innodb_io_capacity を増やそう 本題に入る前に、まだ紹介してないけど1記事にするほどではなかった パラメータを紹介しておきます。 innodb_io_capacity は、 InnoDB に教えるヒントで、 Disk の IO/sec を指定します。 デフォルトでは、通常のHDDでも使えるように中途半端な値(バージョンによって100か200) になっているのですが、BBU付きバッファがあるRAIDカードを使うな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
KLab勉強会#6の資料公開 : DSAS開発者の部屋