さてさて、サポートに連絡を入れ「調査にお時間を頂く」の一報から8日が経過しました。
11月ももう10日過ぎたんですね、あしたはポッキーの日です。
調査に時間がかかるのは私がサポートしているVPSでも同じことで仕方ないのは分かっている
ので、この日数は特に気になりません。仮想化レベル以前の調査が行われているような気がします。
そもそもサポートに問い合わせた理由は以下の記事に書いてあるとおり、サーバーレスポンスが低く
MRTGとSNMPDでのリソース監視がスムーズに行えないという事にあった。
ServersMan@VPS Entryプランのレスポンスナウ
現在のMRTGとSNMPDでのサーバーリソース情報取得にはタイムアウトを20秒としているのだが、
これでもタイムアウトが発生したぜ!というメールが数日に一回送られてくる。
例:/etc/mrtg/mrtg.cfgの一部
Target[disk]: .1.3.6.1.4.1.2021.9.1.9.1&.1.3.6.1.4.1.2021.9.1.9.1:public@サーバーIP::20:2
しかもこのタイムアウトというのは、100%ディスク使用量の取得の際にタイムアウトしている。
ServersMan@VPSのサポートからの連絡を待つ間、効果があるかわからないがプロセス実行に時間が掛かっているsnmpdのプロセスを2時間置きにリロードする設定をクーロンで施してみた。ま、これが問題解決に至るとは思えないけれど、こちらで確認できるCPU利用率が落ち着くことを祈る。
本日のレスポンス状況。lsを10回実行するのに16秒。
[root@webproxy cron.d]# n=0; time while [ $n -lt 11 ] ; do ls / > /dev/null ; n=`expr $n + 1` ; done real 0m16.790s user 0m0.017s sys 0m6.893s [root@webproxy cron.d]#
topで見るsnmpd。TIMEの項目が気になる。
[root@webproxy cron.d]# top -bn1 | egrep 'PID|snmpd'
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7810 root 18 0 25900 6716 4212 S 0.0 0.6 113:17.90 snmpd
[root@webproxy cron.d]#
cronの設定を/etc/cron.d/snmpdとして設定した。
[root@webproxy cron.d]# echo "2 */2 * * * root /etc/init.d/snmpd reload" >> snmpd [root@webproxy cron.d]# ls -al total 16 drwx------ 2 root root 4096 Nov 10 09:00 . drwxr-xr-x 54 root root 4096 Nov 2 09:52 .. -rw-r--r-- 1 root root 313 Oct 31 20:41 mrtg -rw-r--r-- 1 root root 44 Nov 10 09:00 snmpd [root@webproxy cron.d]# [root@webproxy cron.d]# cat snmpd 2 */2 * * * * root /etc/init.d/snmpd reload [root@webproxy cron.d]#
これで様子見をしたい。
検証用サーバーの用途でも使用しているので、早く元気になって欲しいなServersMan@VPS。
コメント
[…] さて、先日から様子を見ているEntryプランですが […]