ふるた技工所(てっこうしょ)

キーワードサーチ

▼キーワード検索

プロフィール

Aちゃん22

フリーページ

2014.11.24

午後は眠く殆ど何もせず - 何もしなくてもできる仕込み systemd の耐久試験を始める、memory leak が有る

カテゴリ：ソフト開発日誌

2014.11.26 追記 systemd メモリリークの様子をグラフでプロット

午後に強い眠気、昨日干しておいた布団の上に横になるだけで体が張り付いた様に動かなくなる。眠気をおして、Fedora 20 x86_64 を仮想マシンに install し、update を適用する。systemd を試すためだ。

眠気の理由に systemd source code を clone して読み始めた事もある。自分は systemd を好ましく思っていない。導入する複雑さに見返りが有る程に起動の早さなどの利便性が有ると思ってはいない。今までは何となくそう思っていた。技術的に思いが正しいことなのか、明確にしたかった。

読み始めてまず気付くのが排他制御が無い。これは dbus の queue を使っているから順次実行され本質的に不要なのか、それとも全く忘れているのか未だ読み切れていない。

allcate, free が多い。全てをチェックしきれているのか疑念が有る。特に unit 相互の依存性を自動解決するのが systemd の目的で有るのに、reference counter 等の参照中の free を防ぐ手段を持っていない様に見える。これも別の仕掛けで防いでいるのだろうか？

いたる所で alloca が多用されている。free を忘れないのは便利だとは思う。systemd に関して言えば自分で落とし穴をたくさん作っている。mam page に依れば stack overflow には無防備なはず。

write_to_journal() を見ると log_error() が使われていて再帰呼び出し構造になっている。一度異常が発生すると更に事態を悪化させる様なコードになっている様に見える。

少し見回しただけで怪しい個所が彼方此方にある。こんなのが PID 1 で良いのか？と Fedora20 のインストール途中で眠くなって布団に潜ってしまった。

(lm)sensord をインストールする。これは、仮想マシンでは特に意味をなさない。systemd の負荷試験用だ。sensord の enable, disable, start, stop を高頻度・非同期で実施し、systemd の作りの善し悪しを見てみることにする。 test script を書く。これらは単純に enable, disable, start, stop を並列実行するために書いた script 群だ。

暫く動かしてみて cpu 時間を 35% 程消費するも systemd は壊れる様子を見せない。「そうなのかなぁ」と思って top コマンドに表示される systemd の RES (VmRSS) 項目を暫く眺めてみた。

1 分くらいすると増加傾向に有ることが分かる。随分と分かり易い memory leak だ。そのうちに GC されて減る(いつか kernel に返却される)のだろうか？

未だ結論は早いかもしれない。この程度の耐久試験で memory leak するのでは systemd は PID 1 に居座る器じゃないと思う。git log を見ると開発開始から 5 年が経過している。なのに今だと単純な負荷試験で問題が露見する程度の作り込みだ。systemd を書いた人は PID 1 の責務の重さを理解していないのだろう。

2014.11.26 追記 : systemd メモリリークの様子をグラフでプロット

お気に入りの記事を「いいね！」で応援しよう