[連載4]どどんとふが重い?

前回の投稿で、1300人のLANパーティーというフザけたネタ解決策も提案しましたが、現実的な解決策もありました。
他に考えた対策も一つ紹介したいと思います。

対処法2改:どうせ待たされるんだからSWAP承知でメモリとプロセス数を増やす

公式鯖第壱鯖、第弐鯖限定で2016年5月20日から試験的に実装しています。その後に対処法3を思いついたので今となっては微妙な対策です。
SWAP承知といってもHDDにSWAPされて大幅にレスポンスが落ちたらかえって待ちが増えてしまうので、なるべく重くならない方法として
zramにSWAPさせています。(これがzramの本来の使い方で、ファイル置き場にするほうが邪道な使い方です)
どどんとふ公式鯖稼働系が動いている仮想マシンは14GBのメモリを割り当てていますが、このうち2GBをsaveData用zram0に、
それに加えて6GBをzram1に割り当て、そこにswapを割り当てました。

そして、第壱鯖と第弐鯖のプロセス数を60→100に増やしました。合計で80のプロセス数増です。
設定前後のnginxのreq/secを比較して、結果を見てみましょう。

nginx_request-week

なんということでしょう!!
5/20以前は300req/secで頭打ちになっていたnginxの処理能力が387req/secと増やしたプロセス数の分だけ増えています!!


SWAPも増えていますし当然ながらメモリをリアルタイム圧縮するためにCPU使用率は顕著に上昇していますが、まだCPUには余裕があるのでコレはコレでチューニングとしてはアリなわけですが、
対処法3であるnginxのfastcgiのバッファリングを増やすことにより待ちが改善するのであれば、プロセス/スレッド切り替えのコストが削減できるためCGIのプロセス数を減らした方がCPU使用効率は良くなります。
プロセス数が少なくて済むのであれば、メモリも必要量が減るのでzramをSWAPに割り当てる必要もないですし、saveData用のzramも圧縮を無効化してさらに速度を上げるという方法も可能となります。

これがお仕事の業務システムであれば、テストを実施して、結果をまとめて、手順書を作って、説明資料を作って、レビューを受けて、利用者との停止調整を行ってという膨大な手間と最低でも2週間はかかりそうな時間がかかるのですが、どどんとふ公式鯖は無保証な個人提供のサービスですので、管理人である私が王です。
そんな手続きはバッサリすっ飛ばして、2016年5月21日の朝に公式鯖の第壱~第四鯖までのfastcgi_buffersを1024 16kbに変更しました。その時点で30人ほど利用者が居たようですが、3秒ぐらいのサービス一時停止ぐらいなので気にせず実施です。ビバ個人鯖!!

来週の公式鯖の負荷状況を見て、zramによるSWAP設定は見直そうと思います。