はてなブックマーク

どんなに軽いクエリでも、たとえばWebサーバーとMySQLの間のRTTが5msあって20クエリを実行したらRTTだけで100msかかってしまいます。 たくさんのデータをinsertするときは bulk insert (VALUES の後に複数の行を書くクエリ) を使うテクニックは有名です。しかしこのテクニックは次のような場合に使えません。 複数のテーブルに1行ずつINSERTしたい 複数のUPDATEやSELECTをまとめたい たとえば弊社のある案件で次のような場面がありました。 新規ユーザー作成時に大量のテーブルにINSERTしたい ログイン時に大量のテーブルにSELECTしたい こういった場面を高速化するために multiple statements と multiple result sets を利用しました。 Multiple Statements 複数のクエリを ; で区切って一

Microsoft の mimalloc は面白い割り切り方で、小さいソースコードで高速なアロケータを実装しています。 確保するメモリブロックのサイズを、 Small (~8KiB), Large (~512KiB), Huge (512KiB~) の3つに分類し、 Small と Large は同じアルゴリズムで管理し、 Huge は OS 任せにして、 Small と Large は同じアルゴリズムをうまく利用しています。 基礎 OSはpage (x86では基本 4KiB) ごとにメモリをプロセスに割り当てています。 しかしアプリケーションではずっと小さいメモリブロックが必要になることが多くあります。また、必要になるたびに毎回OSからメモリを割り当ててもらうのはパフォーマンスも悪いです。 mimalloc やその他の malloc 実装 (以降 malloc と呼びます) は OS か

Microsoft が microsoft/mimalloc という新しいアロケータを公開しました。 https://www.microsoft.com/en-us/research/publication/mimalloc-free-list-sharding-in-action/ によると、 One increasing use-case for allocators is as back-end implementations of languages, such as Swift and Python, that use reference counting to automatically deallocate objects. We present mimalloc, a memory allocator that effectively balances these dema

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

TL;DR: UTF-8をデフォルトで使いたい人は環境変数に PYTHONUTF8=1 を設定しよう Python は文字列が unicode なので、あちこちで「適切」なエンコーディングを選択する必要があります。残念ながら後方互換性やWindows固有の事情によりまだ ANSI Code Page (日本語なら cp932) がデフォルトで使われる場面があります。 ざっと Python と外の世界との入出力をあげてみます。 テキストファイルを読み書きする時のデフォルトのエンコーディング = ACP 標準入出力のエンコーディング 標準入出力がコンソールのとき = UTF-16 で WriteConsoleW 等を呼ぶ 標準入出力がコンソールでない時 = ACP 子プロセスとのPIPE = ACP 最近 chcp 65001 を使って UTF-8 を使う方法が広まっているように思います。これ

はじめに zstd コマンド(zstdless, zstdcat, unzstd なども)は gzip にも対応しています。特にデコードは拡張子を見て自動で gzip と zstd を切り替えてくれるので、 gzip 圧縮されたログと zstd 圧縮されたログが混在している環境でも透過的に扱うことができます。 なので gzip から zstd への切り替えは次のように段階的に進めることができます。 zstd コマンドツール群のインストール 圧縮されたログを扱うときに zstd を使い始める 圧縮フォーマットを zstd に切り替える 性能比較 Debian 9.3 で gzip 1.6 (aptでインストールしたもの) と zstd (1.4.0) を比べてみます。 対象となるファイルは ltsv でゴチャゴチャとアプリの情報を混ぜた重めの apache のアクセスログです。 (5,367

http.ListenAndServe() を使ったサーバーをプロダクションに投入していたのですが、海外からのアクセスが多くなったころにリソースリークが発覚しました。 ListenAndServeのドキュメント ListenAndServeのソースを見るとこうなっています。 func ListenAndServe(addr string, handler Handler) error { server := &Server{Addr: addr, Handler: handler} return server.ListenAndServe() } addr, handler 以外は http.Server のnil値がそのまま使われている事がわかります。この構造体にはいくつかのタイムアウト値がありまが、nil値で初期化されるとタイムアウトなしの状態になってしまいます。 Server型のドキ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Python はデフォルトで多くの警告を表示しません。これはPython開発者ではないエンドユーザーが警告を見た時に混乱するのを防ぐためです。 デフォルトで ignore される Warning は次のとおりです。 (ref: https://docs.python.org/3/library/warnings.html#default-warning-filters) DeprecationWarning PendingDeprecationWarning ImportWarning BytesWarning ResourceWarning これらの warning を Python 開発者が表示しないと、せっかく使っているライブラリが長期間 Deprecation 期間を設けていてもその Warning に気づかないとかいう事が起きます。 また、 warning システムは同じ場所から

$ pip install -r requirements.txt $ pip install flask Collecting flask Downloading Flask-0.12.2-py2.py3-none-any.whl (83kB) 100% |████████████████████████████████| 92kB 3.7MB/s Collecting Jinja2>=2.4 (from flask) Using cached Jinja2-2.10-py2.py3-none-any.whl Collecting click>=2.0 (from flask) Downloading click-6.7-py2.py3-none-any.whl (71kB) 100% |████████████████████████████████| 71kB 3.8MB/s ...

ISUCON7 の本戦では、更新処理の直後に、その更新操作を反映したデータを返さないといけない、しかもそのデータの計算がとても重いという問題を出題しました。 もともと ISUCON では「POSTが200を返したら、それ以降のGETリクエストにはその結果が反映されてなければいけない」というルールが課されることが多いのですが、今回の問題もそのバリエーションの一つといえます。 さて、今年になって singleflight を知り、この種の課題にも使えそうだと思っていました。 (参考 golang.org/x/sync/singleflightで重複呼び出しを排除する) そこで今年の問題を事前に Go でチューニングして見るときに試してみたのですが、普通に適用しただけでは整合性が取れずに失敗してしまいました。そこで調べた singleflight の注意点とワークアラウンドを紹介しておきます。

EC2 の c5 インスタンスタイプが発表されました。 参考: https://dev.classmethod.jp/cloud/aws/ec2-c5-instance/ 個人的に今までのGCEやEC2の不満は PMU が使えないことです。例えば perf コマンドでキャッシュミスや分岐ミスをプロファイリングできません。 C5インスタンスではハイパーバイザーがKVMに変更されたということで、この点に変化が無いか調べてみました。結果、 9xlarge (1ソケット専有) と 18xlarge (ホスト＝2ソケット専有) では Hardware PMU Event を見ることができました。（テナンシーは通常の「共有」のまま、AMI は Amazon Linux 2017.9） 結果: https://gist.github.com/methane/3c523b7bc8e99508a90ca06

Rubyist が pyenv を使うときに知っておいてほしいこと で、 「pyenv を Python をビルドするためだけに利用する方法」について紹介しました。 そこで「シェルを軽量化し、 shims も利用しないようにする事ができます。」と書いたのですが、具体的にコマンドを shims 経由で起動するオーバーヘッドについて紹介しておきます。 $ type python3 python3 は /Users/inada-n/pyenv/shims/python3 です $ pyenv shell 3.6.1 $ python3 -VV Python 3.6.1 (default, May 18 2017, 16:23:51) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] $ time python3 -S -c 42

はじめに 機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python には pyenv に否定的な意見が多いんですよね。 私は pyenv を使っていますし、便利だと思っています。また、 Ruby は殆ど使わないのですが、RubyとPythonのツールスタックの違いについても調べました。 (参考: gem, bundler と pip, venv の比較) その視点から、 Rubyユーザーが自分でpyenvの使い方を自分で決める上で知っておいた方が良いだろうなと思う Ruby と Python の環境の違いをまとめてみます。 tl;dr 丁寧に解説しても、「Python使うにはこんな長い記事を読まないといけないの」とすぐに否

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 非同期プログラミングと呼んでいるのは、ノンブロッキングIOと select, poll, epoll, kqueue のようなIO多重化を利用したネットワークアプリケーションを書くことです。 node.js で websocket 使ったチャットを書くとかそういうのです。 「他の多くの言語」とは、 Python (asyncio), node.js, C# などを想定しています。 Erlang や GHC なんかは Go に近いかも知れません。 async / await がない言語では、「コールバック地獄」や「deferre

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? (この記事は Dave Cheney さんの Why Go? の翻訳です。) 数週間前、友人に「Goに注目に値するのはなんで？」と聞かれました。 彼は私がGoに情熱を注いでいることを知っていましたが、なぜ私が他の人もGoを気にするべきだと思っているのかを知りたいようでした。 この記事は、私がGoを重要なプログラミング言語だと考える、3つの大きな理由を紹介します。 メモリ安全 個人としては、私もあなたもC言語でメモリリークも危険なメモリの再利用もしないプログラムを書く事ができるでしょう。しかし、40年以上の経験から、集団としてのプログラマ

普段は mac で ja_JP.UTF-8 を使ってるけど、 Linux では予想しない挙動の変化が起きるのを嫌って C locale を使う人、いますよね。僕も常にではないけれど結構 C locale 好きです。 でも、 C locale を使うと、 vim が (set encoding=utf-8 を書いていないと) デフォルトで latin1 になって文字化けしまくったり、 Python が (export PYTHONIOENCODING=utf-8 しておかないと) 標準入出力がasciiになって UnicodeError になったりしてツラい気持ちになることもあります。 そんなときは、 LANG=C, LC_CTYPE=en_US.UTF-8 で LC_ALL は設定しないようにするのがただしい locale の設定方法なんですが、最近のモダンな Linux に搭載されてる

Python 2 に比べるとずっと楽になったものの、環境によっては Python 3 で予期せぬ UnicodeError に遭遇することがあります。 Python 3.6 時点での、 Python の各種エンコーディングの扱いを整理してみます。 Python のエンコーディング filesystem encoding (sys.getfilesystemencoding()) 主にファイルパスに使うエンコーディングですが、コマンドライン引数にも使われます。 (そうでないとファイルパスをコマンドライン引数に渡したときに困る) また locale が関連するので、実際にはそれ以外にも glibc とかと連携するときに使われます。 Python 2 時代の名残りでしょうが、今では filesystem encoding というより system encoding と呼んだほうが実態を表している

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Ruby や Python でできたツールの README には、よくインストール方法として gem install redcarpet とか pip install pygments どとシンプルなコマンドが書かれています。 ですが、このインストール方法をみたときに、Rubyに慣れてない人は「どうせ gem install してもなんかよくわからないエラーがでて、愚痴ったら bundler 使わないほうが悪いみたいに言われるんだろ」とか、Pythonに慣れてない人は「これどこにインストールするの？ bundler みたいなのないの？」

# ordersreport.py from collections import namedtuple Order = namedtuple("Order", "amount placed_at") class OrdersReport: def __init__(self, orders, start_date, end_date): self.orders = orders self.start_date = start_date self.end_date = end_date def total_sales_within_date_range(self): orders_within_range = [] for order in self.orders: if self.start_date <= order.placed_at <= self.end_date: orders

TL;DR 負荷の変動が激しい環境でコネクションプールの設定のチューニングをさぼるためによくやるハックを紹介します。 問題 Go から https や mysql など外部のリソースにアクセスする場合、一般的にコネクションプールを使うことになります。 コネクションプールは、利用が終わった (idle) コネクションをプールしておき、次に使いたい時に再利用するものです。 (idle コネクションのプールを以後 free pool と呼びます。) ほとんどのコネクションプールの実装には、 idle なコネクションの最大数を制限するオプションがあります。 また、利用中の (active) コネクションと idle なコネクションを合計した全体を制限するオプションを持つものもあります。 例えば net/http パッケージの Transport は MaxIdleConnsPerHost というフ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は Let’s talk about logging の翻訳です。 Nate Finch による Go Forum への投稿で始まったスレッド を見てこの記事を書くことにしました。 この記事は Go を対象にしていますが、あなたのいままでのやり方を振り返ってみたら、同じ考え方がより広く適用できると思います。 なんでこんなに足りないの？ 訳注: "Why no Love?" を、「（愛されてないから）機能が足りない」というニュアンスで解釈しましたが、自信が無いです。 Go の log パッケージ はレベル付きのロギングを提供してい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ベンチマークや重いソフトウェアのビルドなど、ノートPCには適していない作業をするマシンとして、いままで AWS のスポットインスタンスを使っていました。 しかし5月に GCE のプリエンプティブインスタンスが出て、試してみたところ予想以上に快適でした。 こういったスポットでの作業環境としてのプリエンプティブインスタンスのメリットを紹介していきます。 起動が早い スポットインスタンスは、入札してから実際にマシンが起動するまでのタイムラグが5分程度ありました。 プリエンプティブインスタンスは、通常の Compute Engine のインスタ

Python だけじゃなくて Ruby, php, Perl も扱えるアプリケーションサーバー uWSGI に、 cheaper というモードがあります。これは負荷などに応じてワーカー数を動的に調整する機能です。 デフォルトでは spare, backlog, busyness という制御アルゴリズムがありました。が、どれも気に入らなかったので spare2 というアルゴリズムを作成して、本家にマージされました。取り込まれたのは master ブランチ (開発版) なので、安定版の uWSGI 2.0 用にプラグイン も用意しました。 今回追加した spare2 アルゴリズムの解説と、既存の他のアルゴリズムがなぜ採用しにくかったかを説明します。 (他のアルゴリズムの詳細は ドキュメント を参照してください。) spare2 サンプルの設定ファイルを元に解説します。 process=10 は

NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ