Thundering herd 対策の本命、 EPOLLEXCLUSIVE を試してみた : DSAS開発者の部屋
epoll を使った prefork 型アプリケーションサーバーにおける Thundering herd 対策の決定版として注目されていた EPOLLEXCLUSIVE が、 3/13 にリリースされた Linux 4.5 で導入されました。 昨年 SO_REUSEPORT というソケットオプションが登場して、 Thundering herd 対策として話題になったものの、ワーカーごとに listen キューが作られるため graceful restart するときに listen キューに入ってるリクエストを取りこぼす可能性があり利用するのが難しい状況でした。 参考: epoll の thundering herd 問題について解説しているサイト http://tech.geniee.co.jp/entry/so_reuseport http://uwsgi-docs.readthedo
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
innodb_support_xa と binlog の危ない関係 : DSAS開発者の部屋
昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる（コミットする順序が前後する）可能性があることを指摘していただきました。 innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな？ DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108… — ts. yokuさん (@yoku0825) 2013年4月24日 実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明に
gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体から
SHOW PROCESSLIST を使ったカジュアルなプロファイラを強化しました : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の11日目です。 「SHOW FULL PROCESSLIST を使った MySQL のプロファイリング」 で紹介したプロファイラですが、 id:sh2 さんからはてブで 秒間10回叩く例も http://developer.cybozu.co.jp/kazuho/2009/07/mysql-539d.html 。変数ぽい部分をカットする処理はmysqldumpslowのコードを移植するといいかも というコメントをいただきました。 そろそろネタに困っていたので、 せっかくなので、多くのユースケースで 便利に使えるように改良しました。ぜひご活用ください。 myprofiler.py (gist) github 解説 クエリのサマライズ 前のバージョンでは = 以降をバッサリとカットしてしまって
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
MySQL を PDO で使うときは ATTR_EMULATE_PREPARES を設定しよう : DSAS開発者の部屋
「DSAS for Social を支える技術」 というネタでadvent calendar に挑戦します。 methane です。 PDOで MySQL を使うときは、みなさん $stmt = $con->prepare("..."); して $stmt->execute($values); とかしてプリペアドステートメントを利用されていると思います。 実は、このプリペアドステートメント、パフォーマンス的にはあまり良くありません。1つのクエリを実行するために、プレースホルダ付きのクエリを投げた後に、それに値をバインドして実行するコマンドを投げるので、1回のクエリを実行するのに2往復の通信が必要になるのです。 プリペアドステートメントにはパフォーマンスの利点（同じクエリを何度も発行するときにDBサーバーがクエリの解析を繰り返さないでもすむ）というものと、SQLインジェクション対策になる（正
チューニンガソンで優勝してきました : DSAS開発者の部屋
7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用
MessagePackのPython Bindingをリリースしました : DSAS開発者の部屋
MessagePack とは、古橋(id:viver)さんが開発された高速・高効率なバイナリシリアライズフォーマットです。詳しくは 古橋さんの日記 やプロジェクトサイト を見てください。 PythonからMessagePackフォーマットでSerialize/DeserializeするためのPythonパッケージを作ったので、取得方法と使い方について簡単に紹介します。 1. インストール msgpackという名前でPython Package Index (PyPI)に登録してあります。 <http://pypi.python.org/pypi/msgpack/> setuptoolsをインストールしている環境では、 $ easy_install msgpack でインストールすることができます。 Windowsでインストールする場合は、PyPIのパッケージサイト からインストーラをダウン
社内コードコンペ - お題：最速なCIDRブロックマッチ判定 〜 稲田の場合: hamanoが倒せない 〜 : DSAS開発者の部屋
おさらい #1 ひろせの場合 - IP::CountryとAPRを使ってみた #2 安井の場合: バイナリサーチのあれとこれ #3 hamanoの場合: あ ありのまま 今 起こった事を話すぜ!『コードコンペだと思ったらゴルフコンペだった』な(ry #4 稲田の場合: hamanoが倒せない ← 今回 このコードのウリ 安井さんが２分探索で実装しているという話を聞いて、「それ、TRIE(トライ)で書いた方が速いしシンプルに 書けるんじゃね？」と思って、コードコンペに参加しました。 TRIEそのもの解説は、先日の濱野さんの物と同じなので省略します。 ２分探索等だとO(log n) (nは登録されているcidrの数)の計算量になりますが、TRIEを使うと計算量はO(m) (mはアドレスの長さ) となり、登録するcidrの数が増えてもほとんど遅くなりません。 また、２分探索に比べると、探索部分の
並列プログラミング（その２） : DSAS開発者の部屋
3.Memory Ordering シングルプロセッサのマルチスレッドでは、volatile変数をフラグにして簡単な同期を書くことができました。 例えば、次のような感じです。（コンパイラはvolatile変数へのアクセスの順序を入れ替えないものとします） volatile int done = 0; volatile struct { int foo; int bar; } foobar; void writer(void) { foobar.foo = fizz(); foobar.bar = bazz(); done = 1; } void reader(void) { int foo, bar; while (!done) sleep(1); foo = foobar.foo; bar = foobar.bar; } これは、マルチプロセッサ環境では上手くいかないことがあります。今時
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
OpenSSH クライアントの proxy -- 踏み台サーバを経由しての ssh : DSAS開発者の部屋
DSAS のメンテナンスは，基本的に ssh を使ったリモートメンテナンスで済んでしまいます．夜中や休日に非常事態が起こったとしても，ネットワーク接続さえ確保できればその場で対応できます．ただ，さすがにインターネットから DSAS に直接 ssh できる様にしておくのは一抹の不安があります．ですので，DSAS への ssh 接続は社内のサーバからのみ許すようにしておいて，外からログインする必要があるときは一旦社内のサーバを経由することにしています． このような形にしている場合，DSAS にログインしようとする際は，一旦社内のサーバに ssh 接続する必要があって，小さなことですが一手間かかってしまいます．できればワンステップで接続できる方法が無いかと思って色々検索してみた(※)ところ，このページで ProxyCommand という設定項目を見つけました(見つけたのがボスの個人サイトなのは本
DSAS開発者の部屋:こんなに簡単！ Linuxでロードバランサ (1)
DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
