.
これまでのあらすじ
一筋縄では解決しないと思い、気長に、HTTP2のハッカソンに参加したり、別の処理系でのHTTP2を動かすなどの活動をしていた。
きっかけ
ある意味、HTTPサーバをmrubyで制御する未来という夢は達成されたようなものなで、Trusterdではもう少し違った視点で開発を再開している。もう少しインターナルなプロトコルサーバという役割で。
— Ryosuke Matsumoto / まつもとりー (@matsumotory) November 11, 2015
エラー処理が動いていた
メモリ使用量に着目して、h2oや、nghttp2のpythonバインディングによるサーバーを作っては、これらでは同様の条件にしても、ある程度メモリ使用量に増加は見られるが、減少することもあり、trusterd(mruby-http2)でのそれとは異なる挙動を示していた。 が、valgrindでもleakが検出されないし、正直お手上げ状態だった。
本来はこのあたり、ここにペタペタ貼りたかったが、だいぶ期間を置いてしまったのと、Docker上のコンテナで作業していたものの一部が、VMごと、消し飛んでしまい。詳細を記録化することができない。
h2loadで負荷をかけるとエラーが発生することがある
h2loadでクライアント数や多重化数を増やすとOSXをデフォルトで使っていると簡単にサーバー側でエラーが発生する。 Docker使ってLinuxでも検証していたが、こちらでも負荷が増えるとエラーが発生していたようだった。
しかし、これに気付かず、h2loadを繰り返し動かし、その後のメモリ使用量を表示するツールまで作成し、HTTPリクエストの処理結果は気にしていなかった。65536バイト返す単純なものなので、まさかエラーが発生することがあるとは思いもしなかった。
今回特定できたLeak箇所
Http2サーバーでリクエストに対して処理中エラーが発生した際に、確保していた構造体自身の領域の解放だった。
まとめ
- サーバー処理は、負荷が一定以上超えるとリクエストが正常に処理できない状況が発生する
- エラー処理でもきちんと不要となったメモリの解放処理を行う
- メモリ使用量はエラーレスポンスを返す状況も含めて確認する
- id:matsumoto_r さんすごい！
