出、出〜、mongos接続突然切奴〜ｗｗｗｗｗ

なんというか、ただの恥さらしブログになんだけど自戒のために残しておく。

なんかおかしい

ある日、本番稼働してない控えのmongosさんで変なエラーが出てアプリでもいっぱいエラーが出てきた。
なんかオカシイ。
エラー的には下記

Tue Nov 26 18:20:47.294 [conn88] Socket say send() errno:32 Broken pipe 10.10.10.10:27018
Tue Nov 26 18:20:47.294 [conn88] warning: problem while initially checking shard versions on RS01 :: caused by :: socket exception [SEND_ERROR] for 10.10.10.10:27018
Tue Nov 26 18:20:47.294 [conn88] DBException in process: socket exception [SEND_ERROR] for 10.10.10.10:27018

Broken pipe....?
mongos->mongodの接続が切れてる... ? _ ?

調べる

最初は単純にBroken pipeだからネットワーク的な問題かなと思い、
トラフィックが急にオチてたりethとかで変なエラーが出てないかを見たがそれっぽいものは特に何もナシ。

connectionsが頭打ちになってね？となり
そこ周りで調べてみることにした

mongodのプライマリシャードのconnectionsを確認してみる。
900ちょっとで停滞・・・？

実際にログインしてプロセス数を確認してみる

ec2-user@prd-mongod001(ip-10-10-10-10) ~
$ ps auxxx -L | grep mong | wc -l 
931

設定値は？

$ ulimit -u
1024

ﾃﾞﾌｫﾙﾄ･･･(´ｪ`* ;;;)

すごくそれっぽい

作業

mongoさん優しい。ulimitの推奨値書いてた
http://docs.mongodb.org/manual/reference/ulimit/
ulimitの説明とかも書いてくれてるしなんて親切なの・・・

実際に、作業にはいる

vim /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
#*          soft    nproc     1024

こっちをコメントアウトして、

vim /etc/security/limits.conf 
追記
root    soft    nofile  64000
root    hard    nofile  64000
root    soft    stack   unlimited
root    hard    stack   unlimited
root    soft    nproc   32000
root    hard    nproc   32000
*       soft    nofile  64000
*       hard    nofile  64000
*       soft    stack   unlimited
*       soft    nproc   32000
*       hard    nproc   32000

プロセス再起動

$ cat /proc/`pgrep mongo | head -1`/limits
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            unlimited            unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             32000                32000                processes 
Max open files            64000                64000                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       13087                13087                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us        

反映された
エラーも消えた。

実際の作業はchef流して、各mongo鯖のプロセスを再起動。
一応全てのmongoを１台ずつ再起動していったから、メンテに入れること無く作業は終わりました。
こんな所まで管理できるのもちょっと怖いね

感想

今回のサービスがAWS上で０から環境を作るというものだったのだが、
今まで社内の環境でKickstartとかでデフォルトで入ってた用意されたインフラ的なものにいかに助けられてたかという事を痛感した。
もっかいちゃんと読んでみよう。

おまけ１

mongod側のconnectionsをちょっと広い期間で見てみる。
（間にconnectionsが０にまで下がってるのは、僕がmongoのメモリリークのバグを踏んでサービスメンテ状態を２回引き起こしたからです、ごめんなさい死にます）

本当に今になって思えばなんだけど、
このグラフの期間で増設をしてmongosの台数が約2.5倍になったのに
mongodのconnectionが500 -> 900しかいかないなんて単純に考えてオカシイ

ちなみに、その後ulimitの変更を全ての鯖に適応したら

1200近くまで上がりました(′ʘ⌄ʘ‵)

おまけ2

ulimit適用してもOS再起動時に反映されてないんじゃないの？
【参考】http://blog.father.gedow.net/2012/08/08/ulimit-configuration/
といろいろ不安になったが、そもそも起動スクリプトにulimit書くとか以前に、起動ユーザーのulimitの値を引き継いでプロセスが上がってくるから、そんな心配はいらなかった
実際、試してみたら実行ユーザのulimitで上がってきました。

おまけ???

max processes1024
やんけ！と発見した後に、ulimitが原因だったと他に示す証拠が出てこなかったので、ステージング環境でmax processesを125とかにして再現するか試してみたらmongod自体が死んでテストにならなかった。うふふ
結局500ぐらいに変えて再発した。ので本番にも適用することにした。
状況証拠を集めみたいになってしまったが、今思えばmongodとかもログレベル上げてみれば良かったんや。