タグ

ブックマーク / dsas.blog.klab.org (47)

  • Go のライトバリアに関するバグを修正した話 : DSAS開発者の部屋

    Goのランタイムのバグを踏んで解決しました。解決までの過程を記事にします。 同じようなランタイムのバグを踏んで、小さい再現コードを作れない場合の参考にしてください。 自分のプログラムを疑う あるSlackチャンネルで Go で書かれたサーバーのクラッシュが話題になっているのを見つけました。その時に共有してもらったトレースバックです。 runtime: pointer 0xc007b8af97 to unused region of span span.base()=0xc004000000 span.limit=0xc004002000 span.state=1 fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) runtime stack: runtime.throw(0xc046ca,

    Go のライトバリアに関するバグを修正した話 : DSAS開発者の部屋
    peketamin
    peketamin 2018/12/27
    そうか、再現コードと、レビューアーへの説明が必要なんですね…。かつ、マージする人は他箇所への影響も考えられる人じゃないといけないのか…
  • 最近のPython-dev(2018-04) : DSAS開発者の部屋

    バックナンバー: 2018: 1月 2017: 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 8月 | 9月 | 12月 Python 3.7 がベータになり、大きな変更はなく安定期に入りました。 その間、Python の言語自体やエコシステムに関して重要な話題が幾つかありました。 pypi.python.org から pypi.org へ 長年 Python のエコシステムを支えてくれていた PyPI がリニューアルしました。 Python 3 への移行を始めとしてモダン化され、 Markdown で書いた README をレンダリングできるようになるなどの改善も入っています。 IRC から Zulip chat へ freenode に python-dev という IRC チャンネルがあるのですが、新しい貢献者がコミュニケーションを取るのに今更IRCを使うのはハードルが

    最近のPython-dev(2018-04) : DSAS開発者の部屋
    peketamin
    peketamin 2018/04/28
  • Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋

    Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab

    Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋
    peketamin
    peketamin 2018/02/08
  • Pythonアプリの起動を高速化する : DSAS開発者の部屋

    pipenv 9.0.2 のリリースでCLIの大幅な高速化をしたというアナウンスを見かけました。 Just released Pipenv v9.0.2, which includes massive CLI speedups! https://t.co/AGD8Hkq1EG — Kenneth Reitz 🐍 (@kennethreitz) 2018年1月16日 興味を持ってすぐに試してみたのですが、あまり速く感じられませんでした。そこで Python 3.7 の新機能を使って速度を調査することにしました。 この記事ではその新機能と実際の使い方を紹介します。 起動時間 ≒ import時間 pipenv -h のようなコマンドの実行時間は、実際にヘルプメッセージを表示するための時間よりもずっと長くなります。 アプリケーションが起動するときには、設定ファイルの読み込みなど一定の処理が必要

    Pythonアプリの起動を高速化する : DSAS開発者の部屋
    peketamin
    peketamin 2018/01/23
    “dotenv がオンデマンドで IPython を import するような プルリクエスト を送っておきました。 また、 pipenv は dotenv にパッチを当てた独自コピーを埋め込んで利用しているので、そこから dotenv.ipython を取り除く プルリ”
  • mruby を Linux カーネル内で動作させる(2017 ver) : DSAS開発者の部屋

    このエントリは KLab Advent Calendar 2017(兼 mruby Advent Calendar 2017)の 12 日目の記事です。 今年は(前半は)Keepalived にフルタイムでコントリビュートしていたり(後半は)ひたすら mruby をいじっていたりと、実に OSS 充な一年だった @pandax381 です。 タイトルにある試みについては、2015 年の時点で東京大学の品川先生が「mrubyLinux カーネル内で動作させる」という素晴らしい記事を書かれていて、Kernel module に組み込んだ mruby が動作することを実証されています。 mruby をカーネル内で動作させるために大きく問題となるのが、浮動小数点演算です。mruby は Float を標準的なクラスとして提供していると共に VM 内部でも浮動小数点演算を行っている一方で、Ke

    mruby を Linux カーネル内で動作させる(2017 ver) : DSAS開発者の部屋
    peketamin
    peketamin 2017/12/12
  • 「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋

    「推測するな計測せよ」という格言がよく知られています。この格言は(ISUCONに優勝した)Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が

    「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋
    peketamin
    peketamin 2017/12/12
  • 最近のPython-dev(2017-09) : DSAS開発者の部屋

    バックナンバー: 8月号 | 6月号 | 5月号 | 4月号 | 3月号 | 2月号 | 1月号 今月は Sprint がありました。去年の Sprint はベータ版直前だったのでたくさんの実装が入りましたが、次の Python 3.7 のベータは来年のはじめなので、今回は実装よりも提案(PEP)が多めです。とても全部は紹介しきれない(そもそも一部を除いて議論を追えていない)ので、今月からは提案については受理されたものや受理間近のものだけ紹介していきます。 namedtuple 生成の高速化 bpo-28638: Optimize namedtuple() creation time by minimizing use of exec() namedtuple という、タプルの要素に整数の添字ではなく属性名でアクセスできるようにするデータ構造があります。 例えば次のようにして使われます。

    最近のPython-dev(2017-09) : DSAS開発者の部屋
    peketamin
    peketamin 2017/09/28
  • LVSの高負荷対策 その2 ~障害の再現とその原因~ : DSAS開発者の部屋

    こんにちは。インフラ担当の岡村です。 「LVSの高負荷対策 その1 ~障害発生~」の記事で、大量のSYNパケットを受信した際にロードバランサの再起動が発生したことと、その緊急の対策についてご紹介しました。 今回は、再現確認を行い判明した再起動の原因と、LVSに備わっている高負荷対策の機能についてご紹介します。 検証 前回ご紹介した通り、障害発生時のログからメモリ周りが怪しそうでした。 そこで、ロードバランサにSYNパケットを送り、メモリの使用量の推移を観察しながら、再起動が発生するかどうかを確認しました。 検証環境の構成は次のようになります。 検証環境の構成 パケット送信用サーバを複数台、ロードバランサを1台、Webサーバを1台使用し検証を行いました。 ロードバランサの検証を行う上で、番環境と同様にロードバランスの処理をさせたかったため、LVSに振り分け先のWebサーバのIPアドレスを複

    LVSの高負荷対策 その2 ~障害の再現とその原因~ : DSAS開発者の部屋
    peketamin
    peketamin 2017/09/26
  • 最近のPython-dev(2017-08) : DSAS開発者の部屋

    バックナンバー: 6月号 5月号 4月号 3月号 2月号 1月号 https://docs.python.org/ja/3/ docs.python.org に言語スイッチのドロップダウンリストが追加されました。docs.python.org は Fastly を使っているので、 docs.python.jp よりも高速に閲覧できると思います。 docs.python.jp にあるセクション単位での英語ドキュメントへのリンク機能などがまだなくて単純な翻訳でしか無いので、すぐには docs.python.jp を止めるつもりはありませんが、将来的には docs.python.jp は docs.python.org/ja/ にリダイレクトすることを考えています。 PEP 550: Execution Context Flask などのフレームワークではスレッドローカルストレージを利用して「コ

    最近のPython-dev(2017-08) : DSAS開発者の部屋
    peketamin
    peketamin 2017/09/02
    感謝
  • 最近のPython-dev(2017-06) : DSAS開発者の部屋

    バックナンバー: 5月号 4月号 3月号 2月号 1月号 PEP 546 -- Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 2014年に Python 2.7 をセキュアな状態に保つため、過去に PEP 466 でセキュリティ関連の Python 3.4 の機能が Python 2.7 にバックポートされました。これには ssl モジュールも含まれており、 Python 2.7.9 からは TLS のホストを自動で検証するようになったりシステムの証明書ストアを利用できるようになりました。 今回の PEP 546 は、さらに Python 3.5 で追加された ssl.MemoryBIO と ssl.SSLObject も Python 2.7 にバックポートするものです。これらの API を利用すると、 socket をラッ

    最近のPython-dev(2017-06) : DSAS開発者の部屋
    peketamin
    peketamin 2017/06/30
  • Twisted vs Tornado vs Go で非同期Webサーバー対決 : DSAS開発者の部屋

    昨日の takada-at の記事で「サーバー側では単純に100ms待ってからレスポンスを返すだけのページを用意しておき、」とあったのですが、今日はそのサーバー側の話をします。 もともとこのサーバーを作った動機は、takada-at が作成中の負荷試験システムがちゃんと並列に負荷をかけられるかどうかを検証するためでした。 すぐにレスポンスを返してしまうと、負荷試験スクリプトがきちんと並列に負荷をかけられなくても PV/sec が出てしまいます。 そこで、 epoll を使って高速に並列接続を扱えるTwistedフレームワークを使って、100msの遅延をしつつ数千PV/secに耐えるWebサーバーを作ってみました。 さらに、同じく epoll を使っている Tornado や Go にも興味があったので、こちらでも同じものを作成し、パフォーマンスを比較してみました。 コード まずは、コードを

    Twisted vs Tornado vs Go で非同期Webサーバー対決 : DSAS開発者の部屋
    peketamin
    peketamin 2017/06/07
  • 最近のPython-dev(2017-04) : DSAS開発者の部屋

    バックナンバー: 3月号 2月号 1月号 NEWS (changelog) の作り方 Mercurial時代からNEWSファイル (changelog) の扱いは面倒だったのですが、Githubに移行したことでよりコンフリクトが起こりやすくなり面倒さに拍車がかかりました。 また、コンフリクトせずに間違った状態でマージされるというかなり致命的な事故も起こってしまっています。 (ワークフローが cherry-pick になったためにマージ時に履歴が考慮されなくなったのか、それともMercurialよりもGitの方がマージがバカなのか、詳細は把握してません。) それで、1つの大きなNEWSファイルにエントリを追記していく代わりに、1つのエントリだけを含む小さいファイルを追加していき、ツールでそれらのファイルからNEWSファイルを生成する仕組みへの移行が急務となり、ツールの選定のためにコンペが行わ

    最近のPython-dev(2017-04) : DSAS開発者の部屋
    peketamin
    peketamin 2017/04/18
  • 最近の Python-dev (2017-03) : DSAS開発者の部屋

    バックナンバー: 2月号 1月号 Python 3.6.1rc1 Python 3.6.1rc1 がリリースされました。大きな問題がなければ 3.6.1 は 3/20 にリリースされる予定です。 3.6.1 は Github に移行してから初めてのリリースになります。なにか問題がないか確認するために、いつものRC版以上にソース形式・バイナリ形式両方の配布物のテストが必要なので、可能な方は協力をお願いします。 Github 移行後日談 以降から1ヶ月が経ちました。開発者からのフィードバックはおおむね好評です。私は、気軽にプルリクエストをくれた人がCLAにサインしないまま放置して大量のマージできないプルリクエストが貯まることを懸念していたのですが、今までののところそれも大丈夫そうです。 一方で Misc/NEWS といういわゆる changelog にあたるファイルが頻繁にコンフリクトを起こし

    最近の Python-dev (2017-03) : DSAS開発者の部屋
    peketamin
    peketamin 2017/03/17
  • 最近の Python-dev (2017-02) : DSAS開発者の部屋

    バックナンバー: 最近の Python-dev (2017-01) 新しいコア開発者 主にドキュメントの改善について継続的に活動されていることが評価されて、 Mariatta さんがコア開発者に加わりました。 僕は大きなパッチで目立ってコア開発者になってしまったので、このBlogの読者に間違った印象を与えてしまわないように強調しておきたいのですが、コア開発者に重要なのは他のコア開発者と協調してルールを守って貢献することです。 小さい簡単な修正や他人の pull request のレビューなどでも、継続的にコア開発者とやりとりする機会があれば、結構簡単にコア開発者になれるはずです。 後述する Github 移行によって敷居が下がったはずなので、この記事を読んでくださっている方もぜひ狙ってみてください。 Github 移行 2/11 (アメリカ時間なので日では2/12)に、Python のリ

    最近の Python-dev (2017-02) : DSAS開発者の部屋
    peketamin
    peketamin 2017/02/17
    ありがたい文書
  • 最近の Python-dev (2017-01) : DSAS開発者の部屋

    @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 がリリースされ

    最近の Python-dev (2017-01) : DSAS開発者の部屋
    peketamin
    peketamin 2017/01/23
    すごい
  • ISUCON6 で優勝しました : DSAS開発者の部屋

    @methane です。タイトルの通り、 ISUCON でとうとう優勝してきました。 チームメンバーは、(予選と同じく) @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) でした。 私は予選のときはガッツリとアプリを書いていたのですが、戦では netstat -tn (←老害), top, dstat -ai, sudo perf top などをみつつ指示をだしたり、方針を決めたり、完全に未経験だった node.js & react.js 対策をしたりが主な仕事で、あとは序盤のインフラのタスクが大量にあるときに MySQLdocker から外して基的なチューニングを入れたり Go を100行程度書いただけです。 結果的には優勝できましたが、メンバーの2人がよく準備し番でも実力を発揮してくれたのに対して 僕の戦略ミスで中盤から全くスコアを上げられなかったので

    ISUCON6 で優勝しました : DSAS開発者の部屋
    peketamin
    peketamin 2016/10/25
  • ISUCON6予選をトップ通過しました : DSAS開発者の部屋

    @methane です。「この技術部には問題がある!」というチーム名で @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) とともに ISUCON 6 に参戦し、予選をトップスコアで通過しました。 恒例のふりかえり記事を書きます。 ふりかえり 残念ながらスコアは記録してないのですが、時系列順にやったことをまとめます。 アプリのコードは methane/isu6q-app で公開しているので、興味がある方はコードを確認してください。 strings.Replacer を使う 使用言語は最初から Go と決めていたのですが、Goの初期実装は遅すぎてタイムアウトで最初からスコア無しでした。 top でアプリのCPUが支配的なのはすぐ判りましたし、コードを読めばなにが遅いのかも一発で判りました。そんなに長くないので関数全体を張ります。 func htmlify(w http.R

    ISUCON6予選をトップ通過しました : DSAS開発者の部屋
    peketamin
    peketamin 2016/09/20
  • ラズパイで作るネットワークエミュレータ(前編) : DSAS開発者の部屋

    ネットワークが絡んだ通信プログラムを開発していると、テストのために遅延やパケロスを意図的に発生させたくなることがあります。いまどきは IDE にネットワークエミュレーション機能が組み込まれていたり、仮想環境で容易に再現できたりもしますが、箱物のネットワークエミュレータがあるとネットワークの構成を気にせずカンタンに設置できるのですごく便利だったりします。世の中にはそういった製品が沢山あるので安価なものを買ってもいいのですが、新たにラズパイが届いたばかりだったので、これを使って超小型のネットワークエミュレータを自作してみました。前編と後編の二回に分けて紹介します。 最近、社内で「ラズパイおじさん」と呼ばれるようになりました。@pandax381 です。 ラズパイ + Linux = ネットワークエミュレータ 「ネットワークエミュレータを自作」と言うとなんだか凄そうな感じがしますが、実はものすご

    ラズパイで作るネットワークエミュレータ(前編) : DSAS開発者の部屋
    peketamin
    peketamin 2016/04/06
  • Tornado アプリのログファイル書き込みのチューニング : DSAS開発者の部屋

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

    Tornado アプリのログファイル書き込みのチューニング : DSAS開発者の部屋
    peketamin
    peketamin 2016/03/09
  • Python2.x/3.0のunicode内部表現について : DSAS開発者の部屋

    イントロ Python2.6/3.0共にRC版がリリースされ、正式リリースが近づいて来ました。Python3.0の大きな変更の一つが、 Python2.xのstrとunicodeがunicode文字列のstrに統合され、従来のstrの代わりにbytesを導入することで、バイト列と文字列が明確に分けられたことです。 現在、Python2.5では、unicode文字列の内部表現がucs2のものとucs4のものがあり、それぞれの間では拡張 モジュールの互換性がなくなっています。Python2.6/3.0でこの状況がどう変化するのか調べてみました。 Python2.xのunicode内部表現について Python2.5/2.6では、configureオプションに、--enable-unicode=ucs[24] というものがあり、デフォルトでは2になっています。 また、FedoraやUbuntuの

    Python2.x/3.0のunicode内部表現について : DSAS開発者の部屋
    peketamin
    peketamin 2016/01/22