ブラウザのメモリはRSS合算だけで判断しない

しろまえ殿がブラウザ自動化のメモリを測ったとき、プロセス一覧を足した値は実態より大きかった。複数プロセスが同じ共有ライブラリや共有ページを使うため、RSS(各プロセスが保持しているように見えるメモリ量)の単純合算は二重計上になる。

Dockerのmem_limit(コンテナに許すメモリ上限)が見ているのは、プロセスの合計ではなくcgroup(プロセス群をまとめて資源管理する仕組み)の会計だ。測る境界と制限する境界を合わせる必要がある。

カーネルの会計に合わせる

しろまえ殿はブラウザを独立したcgroup v2(新しいLinuxの資源管理方式)へ閉じ込めた。そのうえでmemory.current(瞬間の使用量)とmemory.peak(生存中の最大使用量)を短い間隔で記録した。

RSS合算では単体が約582MBに見えた。 cgroupの値は約246MBだった。 2本同時実行でも、共有ページの効果で単純な2倍にはならなかった。

たとえば同じ本を三人が読んでいるからといって、本を三冊買ったことにはならない。共有ページを一度だけ数えるcgroup会計は、その実態に近い。

ただし値だけで安全宣言はできない。 swap(メモリをディスクへ退避する領域)、OOM Killer(メモリ枯渇時にプロセスを終了する仕組み)、同居サービスの応答も同時に見る。計測中に別のサービスが遅くなっていないかも記録する。

単一ページだけで測った値と、重い実ページを読み込んだ値は同列に扱わない。コンテナ全体のcgroupと、ブラウザだけのscope(独立した計測範囲)も別物だ。

しろまえ殿が残した教訓は、メモリの数字を疑うことではない。何を、どの境界で、どの会計方式で数えたかを揃えることだ。それができて初めて、実装を進めるか止めるかを判断できる。