同じ会社で働いてる @kuwa_tw さんから紹介いただいて、WEB+DB PRESS vol. 79の記事を書かせていただきました。雑誌に、というか印刷物に自分の書いたものが掲載されるのは初めての経験です。あまり歓迎されないけれども避けては通れない、メンテナンスという切り口で書かせていただいています。
始め、執筆の話をもらった時は、自分の書いた文章が印刷されて世に出るなんて想像もつかない出来事だなあと思っていましたが、実際手元に届いても、これが広く読者の方々に読まれるというのがどういうことなのかよくわかっておりませんｗ 皆さんからマサカリが飛んできて初めて理解できるものなのかもしれません。ご意見などありましたら @dblmkt までいただけるとうれしいです。
執筆のチャンスをくれた @kuwa_tw さんを始め、不慣れな我々をサポートしてくれた技術評論社の編集者の方、一緒に記事を執筆し色々なアドバイスをくれた同僚達にこの場を借りて感謝を表したいと思います。ありがとうございました！
CentOS 5+Tomcat 7+JDK 7+Apacheという組み合わせで動かしていたサーバ群に、OSだけCentOS 6にしてミドルウェアのバージョンは変えないサーバを何台か追加したところ、CentOS 6の方が、Tomcatが確保している仮想メモリ量が圧倒的にでかいことに気づいた。
ちなみに、どちらのサーバもヒープサイズは「-Xmn1024m -Xmx2048m -Xms2048m」となっており、本来なら2GBプラスアルファ(コードキャッシュ他の領域分)しかメモリは食わないはずだ。もちろん、ロードバランサではどちらのサーバにも同じ重みでアクセスを流していおり、負荷は同じのはず。
CentOS 5のサーバ
こちらはざっくり3GB弱の仮想メモリを確保していると出ている(左から5番目、VSZの列)。ヒープサイズから考えるとまあこんなものかというレベル。
# ps auwx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
31234 10315 110 8.8 3134280 1447956 ? Sl Nov14 6870:09 /usr/local/java/bin/java -Djava.util.logging.config.file=/usr/l cal/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -XX:MaxPermSize=128m -XX:PermSize=128m -XX:SurvivorRatio=2 -Xmn1024m -Xmx2048m -Xms2048m (後略)
CentOS 6のサーバ
一方こちらは10GB弱ものメモリを確保していることになっている。ヒープサイズとの差分9GB近くはどっから出てきたのか？
# ps auwx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
31234 19463 156 33.6 11270576 2708744 ? Sl Nov14 9532:10 /usr/local/java/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -XX:MaxPermSize=128m -XX:PermSize=128m -XX:SurvivorRatio=2 -Xmn1024m -Xmx2048m -Xms2048m (後略)
CentOS 6の方のサーバのTomcatのプロセスIDを指定してpmapコマンドでメモリの確保状況を見てみると、何やら同じ容量(64MBぐらい)を確保しているanonという行がたくさん表示されているのが目につく。これが悪さしているようだ。ちなみに、一番右の列には通常そのメモリを確保しているファイル名が出るが、anonというのは匿名で割り当てのみがされた領域を示しているようだ。
# pmap -x 19463 | sort -k2 -n
Address Kbytes RSS Dirty Mode Mapping
(略)
00007f08d0218000 63392 0 0 -- [ anon ]
00007f0878215000 63404 0 0 -- [ anon ]
00007f099c208000 63456 0 0 -- [ anon ]
00007f08941fe000 63496 0 0 -- [ anon ]
00007f09341fb000 63508 0 0 -- [ anon ]
00007f091c1ea000 63576 0 0 -- [ anon ]
00007f08901e5000 63596 0 0 -- [ anon ]
00007f08fc1e3000 63604 0 0 -- [ anon ]
00007f09c01e0000 63616 0 0 -- [ anon ]
00007f094c1d8000 63648 0 0 -- [ anon ]
(略)
調べてみたところ、この現象は、CentOS 6に含まれているglibc 2.11の挙動によるものだそうだ。glibc 2.10から、スレッドごとにメモリ空間を割り当てるような実装に変わったとのこと。なお、CentOS 5ではglibcは2.5。以下、glibcのコミッタUlrich Drepper氏による2.10のchangelog解説からの抜粋。
glibcに対する今回の変更では、スレッドごとにメモリプールを作るようになった。これで多くの場面で間違った割り当てを排除することができる。メタデータは通常1つのスレッド内でしかアクセスしない(スレッドは割り当てられたコアから移動されないのが望ましい)。アドレス空間を吹き飛ばしてしまうようなメモリのハンドリングを防ぐため、メモリプールの使い過ぎに上限が設けられた。デフォルトでは、32ビットマシンではコアあたりメモリプール2つ、64ビットマシンではコアあたりメモリプール8つを生成する。
プールが確保するサイズは64MBであり、上の例のCentOS 6のマシンの場合、CPUは24コアの64ビットマシンなので、「24コア x 8 x 64MB」が仮想メモリとして確保されているため、VSSの列の値が大きくなっていたというわけだ。なお、このプール用のメモリはあくまで割り当てられただけで使用されているわけではない。そのため、実際に使われているメモリはRSS(Resident Set Size)の列に表示されているものである(当然だが)。
Tomcat動かしてて気づいたのでタイトルが「TomcatのJVMが～」となっているが、同じようなつくりのメモリを大きく確保するアプリケーションでは同じことになるのは言わずもがな。
参考1 : Quoraのやりとり「なぜいくつかのアプリケーションはRHEL5と比べてRHEL6では明らかに大きな仮想メモリを使うのか？」
参考2 : IBM developerWorksの記事「Linuxのglibc 2.10以上(RHEL6)のmallocは仮想メモリの使用量を過大に表示するのか」
参考3 : StackOverflowのやりとり「Linux上でのJavaの仮想メモリ使用量が大きすぎる」
解説が非常に詳しくてためになる。
MySQL Casual Talks vol. 5に行ってきたので、自分なりのメモと資料へのリンク。
途中、アラートが鳴り始めて確認してたりしてメモが適当なところがあるが仕方なしｗ
かなりのスピードでじゃんじゃんプレゼンが進んで行ったが、どれも面白い・役立つ内容ばかりで、楽しいひと時でした。発表者の皆様、会場の提供や調整などしてくださった@myfinderさんはじめとする皆様、ありがとうございました。自分の隣でビール缶を次々と「カシュッ」と空けていた@oranieさんのような余裕を持ちつつ、次回は自分も何かネタを提供できるといいなあ。
のChapter 10
