さて、先週発覚した、「PHP7でphp-fpmがSIGSEGVで死ぬ」問題対策、この週末も解析を続けていました。まだ決定打には到達していない気がしないでも無いですが・・・続報です。
すべてはSIGSEGVから始まったのです・・・・。
という訳で、なんか考えた結果について。
redisを諦めた理由。
まずは、じゃぁAPCu使うの諦めて、redisなりmemcachedなり使えば良いじゃない、という案は当然あります。ただ、memcachedについては、以前、Cache系プラグインとの組み合わせで使っていて、結構性能が悪く、結局、APCが一番速いという結論になった経緯があります。Wordpress(php)からの外部KVS呼び出しコストは結構安くないというのが、そのときの経験からの感触です。
他方、memcachedについては、mod_pagespeedとの組み合わせでは、かなり良い動きをしています。mod_pagespeedはmemcachedと組み合わせて初めて真価を発揮すると言って良いと思います。
という訳で、redisにしたって、結果は同じだろう、と思うところがありつつ、それでもredisならやっぱり違うかな、と期待するところもあり、redis containerを準備してました。
が、結局やめました。redisの環境要件がちょいと厳しいのがその理由です。
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis-serverを起動すると、この３つのWARNINGが出力されます。CoreOSでもCentOS6でも同じように出力されましたので、どちらの環境でも（dockerに限らず）OSパラメータの調整が要るようです。あくまで警告なんですが、somaxconnはまぁ良いとして、overcommit_memoryやTransparent Huge Pagesの動作を変更するのは、OS環境全体の動きに影響を及ぼすので、流石に躊躇します。特にTHPは、2.6系カーネルのLinux環境では比較的目玉機能だと思っていますので、これを切れと言われると流石に厳しい。
専用VMでも作れば、影響をその環境に押しとどめることが出来るのですが、せっかくcontainerベースで作っているところ、個別のコンテナ（アプリ）の要件でホスト環境を弄るのは嬉しくないなぁ、と思っています。まぁこれがcontainerの機能的な制限とも言えます。
以上、２つの理由から、redisは取り急ぎ断念。この辺、カーネルのバージョン上がったら、namespaceなりでプロセス単位で制御できると嬉しいと常々思っています。特にHugePage関連。
APCuのその後。
という訳で、APCuでの悪あがきを継続中です。
と、その前に。
APCuにはAPCの状態を見る「apc.php」という管理画面が付属しています。ただ、それは3.xでの話。最新の5.1ではrpmを入れただけではこれが見当たらないです。古いapc.phpでも状態は見れるんですが、オブジェクトのUser Entry Labelが見れなかったり、php-fpmサーバー側で「キーが無い」とかエラーメッセージが出たりするので、こちらも最新版を入手すべしです。
githubから最新のapc.phpを持ってくれば、きちんと中身も見れます。当たり前といえば当たり前なんですが、一応。
とりあえず、悪あがき第一弾。前回の「Fragmentation 100%」から、これは明らかにメモリが足りないだろう、ということでメモリを増やしてみた。UNIX domain socketでのnginxとの連携が契機となるという情報もあったので、tcpベースに変更した（ちょっとオーバーヘッド増えるかなぁ）、apc.mmap_file_maskを/dev/zeroにした。
; Enable APCu Backwards Compatibility Module extension=apc.so apc.shm_size=64M apc.mmap_file_mask=/dev/zero
結果。
狙い通り、32Mを超えて、きちんと動き続けています。ただ、フラグメントの状態やメモリの減り方は、あまり変わっていない。現在のサイトのコンテンツ量から見て、おそらくは溢れないとは思われるんですが、安定して動いているとは思えない状態です。
そこで、さらにパラメータ調整して、現在検証中です。
; Enable APCu Backwards Compatibility Module extension=apc.so apc.shm_size=64M apc.mmap_file_mask=/dev/zero apc.entries_hint=32768 apc.ttl=7200
ttlを入れるかどうかは非常に難しいところですが、どこかでCAPしてくれることを期待して入れてみました。hintは24時間運用したとき、概ね1.2万件程度のデータが登録されていたので、3万件を指定。まぁ性能には影響しないかと思いますが、保険です。
これでどの程度動きが変わるかな、というところを現在確認中です。
PHP7+APCuは非常に高速ですので、是非とも安定して動いてくれることに期待しつつ。続く。
コメント