Web * Location Information
vpsタグのついている投稿
kmemsizeをnagiosで監視
2010年4月23日
VPSで運用している環境にて、kmemsizeの制約にひっかかり、いきなりOSが止まってしまいました。
それを回避するためにnagiosでこのkmemsizeを監視するスクリプトを書きました。
kmemsizeは/proc/user_beancountersに仮想ファイルとして出力されています。
このファイルはrootしか読めないため、/etc/sudoersへnagiosを実行しているユーザを追加する必要があります。
#!/usr/bin/perl
use strict;
## add folloing lines to /etc/sudoers
# Defaults:nagios !requiretty
# nagios ALL=(ALL) NOPASSWD: /bin/cat
my $CRITICAL = 0.8;
my $WARNING = 0.7;
my $kmem_line = `sudo cat /proc/user_beancounters 2> /dev/null | grep kmem`;
chomp $kmem_line;
$kmem_line =~ /([0-9]+) +([0-9]+) +([0-9]+) +([0-9]+)/;
my $current_kmemsize = $1;
my $max_kmemsize = $4;
my $status = "OK";
if($max_kmemsize * $CRITICAL < $current_kmemsize){
$status = "CRITICAL";
}elsif($max_kmemsize * $WARNING < $current_kmemsize){
$status = 'WARNING';
}
print $status;
print " - ";
print $current_kmemsize;
print " | ";
print $kmem_line;
print "\n";
exit(0);
kmemsize
2010年4月22日
VPS上のOSがいきなり止まったから原因を調べたら、VPSで割り当てられているkmemsizeがリミットに達したからだった。
物理メモリ使用量や、プロセス数はさほど多くないのにkmemsizeのリミットに引っかかるとは。。。意外な落とし穴だった。
CPIでは、32MB割り当てられている。VPSのサービス内容を見てみるとkmemsizeは必ず示されて居るぐらい重要な指標みたい。
nagiosの監視項目に追加しておかなきゃです。
CPIでは、このトラブルが起きた時にはParallelsからコンテナ（VPS上の仮装OS）の再起動を手動で実行する必要があります。
この事に関して、CPIの回答は消極的。
kmemsizeの制限にかかった際にOSが停止したようであるとの事ですが、
そのような場合にコンテナを再起動するような設定はいたしかねます。尚、リソースを多く使用するプログラム等を設置されている場合は、
お客様にてプログラムの見直しを行っていただきますよう
お願い申し上げます。
以下に、kmemsizeがリミットに達した時の物理メモリ容量とプロセス数のmuninグラフを添付しておきます。これじゃ、物理メモリを1GBも使い切れないじゃん！
YMC vs CPI
2010年1月7日
VPSのbenchmark。
目的：ネットワーク帯域など、クライアントから見たHTTPのレスポンス性をチェックする。
測定環境
apache上げて単純なHTMLファイルの転送。
ファイルの内容：
<html><body><h1>It works!</h1></body></html>
apache benchのオプション：
% /usr/local/apache2/bin/ab -n 1000 -c 2
Requests per second: 34.84 [#/sec] (mean)
Requests per second: 163.67 [#/sec] (mean)
結果
4.7倍 CPIが高速！
VPS契約時に確認すべき重要なこと
2009年10月29日
短期的には問題にならないけど将来的にはかなり問題になること、それは機能がアップグレードされるかどうか！？
ハードウェアの調達コストは低くなるので、VPSプロバイダはVPSの新しいプランまたはアップグレードされたプランを発表する。しかしながら、すでに契約している顧客に対してはアップグレードをしない場合があったり、アップグレードする場合はIPアドレスが変わってしまうという事態が起こる。
クラウド（PaaS)であればハードウェアも仮想化されているのでこのような問題は起こらないが、VPSでは起こってしまう。仮想化への過渡期なのでしょうがないが、VPSを契約する場合は注意すべき。
サーバ仮想化技術の流れは以下で、
専用サーバ→VPS→クラウド（PaaS)
VPSは発展途中。メリットデメリットが存在する。しかしながら、クラウドも実用段階に入ってきているので今VPSを契約するならしばらく待ってクラウドを契約した方が将来的には楽。
VPS HTTP benchmark (YMC vs KDDI)
2009年10月8日
tareget file: 145.19 KB
% ab -c 2 -n 1000
ymc
min mean[+/-sd] median max
Connect: 23 30 133.9 23 3025
Processing: 147 189 85.4 152 829
Waiting: 24 25 2.8 24 77
Total: 170 219 158.4 176 3207
kddi
min mean[+/-sd] median max
Connect: 7 18 29.5 15 737
Processing: 126 228 9.0 230 248
Waiting: 7 28 8.4 29 50
Total: 192 247 24.9 246 868
YMC VPSベンチマーク
2009年9月8日
YMCのVPSを使っています。
しかしながら、ページ表示速度が遅いのでまず静的HTMLでベンチマーク取ってみました。
利用しているサービスはカスタム10。
測定環境
- 回線:100Mbps 光ファイバ（goo スピードテストで66.37Mbps）
ベンチマーク1
- ルータ経由数：21
以下、測定結果。
重要なポイントだけ引用。
% date Tue Sep 8 01:54:15 JST 2009 % /usr/local/apache2/bin/ab -n 100Server Software: Apache/2.2.11 Document Length: 18661 bytes Concurrency Level: 1 Time taken for tests: 11.174 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 1896400 bytes HTML transferred: 1866100 bytes Requests per second: 8.95 [#/sec] (mean) Time per request: 111.743 [ms] (mean) Time per request: 111.743 [ms] (mean, across all concurrent requests) Transfer rate: 165.73 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 23 24 0.5 24 26 Processing: 73 87 51.1 76 350 Waiting: 23 25 1.2 25 32 Total: 98 112 51.1 100 374
まとめると以下。
- 回線が遅い
- レスポンスが来るまでが遅い（Processingの時間が長い）
ベンチマーク2
YMCのトップページの表示速度はすごく速いのでベンチマーク取ってみた。
- ルータ経由数：16
% date
Tue Sep 8 01:54:15 JST 2009
% /usr/local/apache2/bin/ab -n 100 http://www.ymc.ne.jp/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.ymc.ne.jp (be patient).....done
Server Software: Apache/2.0.52
Server Hostname: www.ymc.ne.jp
Server Port: 80
Document Path: /
Document Length: 27895 bytes
Concurrency Level: 1
Time taken for tests: 4.105 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2804900 bytes
HTML transferred: 2789500 bytes
Requests per second: 24.36 [#/sec] (mean)
Time per request: 41.049 [ms] (mean)
Time per request: 41.049 [ms] (mean, across all concurrent requests)
Transfer rate: 667.29 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 6 0.5 6 8
Processing: 34 35 0.6 35 38
Waiting: 7 8 0.3 8 9
Total: 39 41 0.8 41 45
比較
VPSが19KB、YMCのHTMLが28KBなのに、この差。
YMCのVPSサービスをフルに使う！
2007年6月14日
claraのvpsが遅い
2006年8月16日
物理マシンのCPUがほとんどidleなのに全然CPUを割り当ててくれてない。
そして、遅い。 PHPのコンパイルに20分かかる。
追記：やっぱり、おそい。おそすぎる。ぜんぜんCPUリソースを割り当ててくれていない。
そして、プロセス数の最大が60とか70だと全然足りない。
daemontoolsでデーモンを管理し出すと軽いプロセスが1サービスにつき4つできちゃうし、
Apache,PHP,MySQLを入れたらもう60プロセス。もちろんいらないサービスはuninstallしまくり。
なので、claraのVPSはやめて他のを探した。
条件は、プロセス数が100以上。CPUリソースの割り当てが500MHz程度。
そしたら、@YMCのVPSのホスティングが一番よかった。YMCでは、サーバのプロセス数の上限なし、CPUリソース300MHz保証。
CPUに空きがあったら全部割り当ててくれる。この情報はWebでは公開されておらず、電話で問い合わせた。
YMCは費用対パフォーマンスは最高！！！！
レンタルサーバーもすすんだなー。個人で1つのホストを借りられちゃう。
最近のコメント