@methane です。 compact dict が Python 3.6 が9月（ベータになる直前）にマージされ、それのおかげで推薦をもらい 10月ごろから Python の Core Developer になりました。 「PythonのフルタイムコミッタとしてKLabに雇われている」という訳ではないのですが、 もともと自己裁量で業務時間の大半をOSSへの貢献やコードを読むことに費やし、特にこの3ヶ月位は Python ばかり触っていたので、実質的には近い状態です。 そちらでの活動をあまり日本で共有する機会がないので、 Money Forward の卜部さんが書かれている 最近の ruby-core という記事をリスペクトして、 最近の Python の開発状況を紹介する記事を書いてみたいと思います。 Python 3.6 リリース 12/23 に Python 3.6 がリリースされ

背景 2015年1月に、 PyPy の開発者Blogにこんな記事がポストされました。 Faster, more memory efficient and more ordered dictionaries on PyPy その後リリースされた PyPy 2.5.1 から dict は挿入順を維持するようになり、メモリ使用量も削減されました。 一方 CPython では、 PEP 468 で、キーワード引数を **kwargs という形式の仮引数で受け取るときに、引数の順序を保存しようという提案がされました。 例えば、 SQLAlchemy のクエリーで .filter_by(name="methane", age=32) と書いたときに生成されるクエリーが WHERE name = "methane" AND age = 32 になるか WHERE age = 32 AND name="m

@methane です。 最近 Python の dict をハックしているので、その紹介をしたいと思います。 ですが、まずこの記事では現在 (Python 3.6a2) の dict の実装を詳解します。 データ構造 基本となる構造体は3つです。(Python 3.6a2 のソースより引用) typedef struct _dictkeysobject PyDictKeysObject; typedef struct { PyObject_HEAD Py_ssize_t ma_used; PyDictKeysObject *ma_keys; PyObject **ma_values; } PyDictObject; typedef struct { /* Cached hash code of me_key. */ Py_hash_t me_hash; PyObject *me_key;

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

最近は協力プレイやPvPなどの「リアルタイムサーバー」を書くときは Go が主流になっているのですが、 Tornado を使ったシステムも健在です。 (以前の記事) 数人〜十数人程度の「部屋」を、1つの Tornado プロセスに複数もたせ、さらに一台のサーバーにその Tornado プロセスを複数置くことでCPUのマルチコアを活用する構成になっているのですが、最近各プロセスがログファイルを書く部分でブロックして応答性能が悪化するケースがあったので対策しました。 この記事ではその対策で行ったチューニングや、行わなかったチューニングについても紹介します。 ※なお、この記事は Tornado を題材にしていますが、似たような仕組みになっている node.js などの他の言語のフレームワークでも同じ事が言えるはずです。 前提知識 Tornado は epoll や select などのIO多重化

MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス

もう、あって当たり前というところまで浸透してきた仮想環境、みなさまは何をお使いでしょうか? 私の周辺ではVirtualBoxがよく使われています。 典型的な使い方としては、 以下のような感じです。 ホストOSには、mac/windowsをつかう ゲストOSには、Linuxを使う 共有フォルダを使って、ホストとゲストでファイルを共有する その中でも地味に重要なのが共有フォルダ。 共有フォルダとは、ホストOSのファイルシステムをゲストOSからマウントするための、VirtualBoxが提供している仕組みです。 しかし便利な反面、ファイルアクセスが非常に遅いという声をよく聞きます。 findが終わらないとか、git statusが遅すぎるとか... この問題への対策を探してみると、下記のような物がみつかります。 vboxsfでなくNFSなど別のファイルシステムを使う VirtulaboxではなくV

9/27 の ISUCON 予選2日目に参戦してきました。 KLab から参加した6チームのうち予選通過できたのは私が率いる lily white だけ、それも通過組の中で下から3位とかなり厳しい結果になってしまいました。 本格的な練習は新人が予選で ISUCON の難しさを実感してからにしようと思っていたのですが、今年は予選のレベルが想像以上に上がっていて、 お題のアプリも本戦さながらの規模、複雑さになっていて、もう完全に舐めてましたごめんなさい。出題側本気出しすぎです。本当にお疲れ様でした。 考察と感想戦はベンチマーカーが公開されてからにするとして、当日の流れを覚えているうちに振り返ってみます。 (時間とスコアをメモってなくて集計サイトもクローズしてしまったので、文中の時間とスコアはうろ覚えのものです) 準備 lily white は私以外に新卒の @gam0022, そして Twit

ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア

簡単なチャットプログラムは、ネットワークプログラミング用のフレームワークでは定番のサンプルプログラムです。 echo サーバーが Hello World とするなら、チャットは FizzBuzz といったところでしょう。 とりあえず動くだけのチャットならだれでもすぐに作れるようになりますが、まじめにチャットを作ることで、 ネットワークプログラミングで考えないといけない点やエラー処理の重要な基礎を学ぶことができます。 ということで、 Go でシンプルなチャットを実装してみました。 (ソースコード) 以降、何を考えてどういう設計を採用したのかを解説していきます。 考慮すべきポイント 特定のクライアントへの送信に長時間待たされた場合に、他のクライアントへの送信が遅れないようにする。 クライアントを切断するのは、 (1)ルーム側から kick する場合, (2)受信エラー, (3)送信エラー の3

KLab からは 「ぜかまし」 が ISUCON 3 の本戦に参加していました。 メンバーは私 (@methane) と、 @tenntenn, @hasi_t です。 結果は順位なし (計測時に fail が多かった) と、惨敗というかそれ以前の問題です。 結果は散々だったものの、設問は非常に完成度が高く、とても楽しめました。 作問してくださった面白法人KAYAC様、主催してくださったLINE株式会社様、 環境と懇親会を提供してくださったデータホテル株式会社様、ありがとうございました。 特に問題作成に関わられた方、本当にお疲れ様でした。 それでは、どうしてこんな結果になったか、当日の様子を振り返ってみます。 10:00 会場着 3人とも開場時間前後には到着して、ホワイトボードがある会議室を抑えました。 (とはいえ、ホワイトボードは同じ会議室の人にも見えてしまうので、結局使いませんでした。

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

KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。 標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。 まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。 RedisSentinelとは Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。 詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。 http://redis.io/topics/sentinel RedisSentinel導入前の構成 特に何の変哲も無い構成です。 Redisサ