Rackspaceクラウドで2つのサーバーを実行しています。1つはWebアプリ用で、もう1つはdbおよびredisインスタンス用です。 Webサーバーには1GbのRAMとシングルコアがあります。 Nginxは、2人のワーカーを実行しているUnicornの前に座っています。また、sidekiqインスタンスを実行しています。この構成は適切に実行され、アプリがまだ起動されていないため、サーバーは通常、非常に低いCPUで動作します。
ただし、Unicornを再起動すると、アプリの完全なデプロイは言うまでもなく、すべての地獄が解き放たれます。これは次のようになります。
基本的に私のサーバーは3分間ワイプされます。時々応答性がありますが、監視によってあらゆる場所でダウンタイムアラートがトリガーされます(これはダウンタイムゼロの再起動です)。
フルデプロイを実行すると、アセットを事前コンパイルしてアップロードしている場合でも、グラフの長さは約8分になるため、サーバー上でのコンパイルは行われません。
私にとって興味深いのは、DigitalOceanで正確に重複したサーバーセットアップを実行していることです。サーバー全体を完全に再起動できますshutdown -r
そして50秒でページをアップして提供します。このRackspaceサーバーでは、本番サーバーに非常に大きなダウンタイムが発生するため、テストのために再起動することはありません。
私はLinuxサーバーの管理者ではないので、これがRackspaceクラウドサーバーのコースと同等かどうかを人々が教えてくれるかどうか疑問に思っています。私はいくつかの専用Windowsボックスを実行して10年の経験があり、このような問題は発生していません。
サーバーに対するhdparm。
ラックスペース:
$ Sudo hdparm -Tt /dev/xvdc
/dev/xvdc:
Timing cached reads: 5066 MB in 1.99 seconds = 2541.54 MB/sec
Timing buffered disk reads: 238 MB in 3.00 seconds = 79.32 MB/sec
DigitalOcean
$ Sudo hdparm -Tt /dev/vda
/dev/vda:
Timing cached reads: 15612 MB in 1.99 seconds = 7828.02 MB/sec
Timing buffered disk reads: 1416 MB in 3.00 seconds = 471.89 MB/sec
明らかに、DOサーバーはRSサーバーを大幅に上回っています。興味深いことに、DOサーバーは実際には2つのアプリをステージングしているため、RS1よりも多くの作業を行っています。両方のhdparmsは、サーバーの負荷がほぼ同じ(つまり、ごくわずか)で実行されます。これは純粋に遅いディスク速度ですか、それともここで何か他のことが起こっていますか?
両方のサーバーのトップ
ラックスペース
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9832 xxxxxxxx 20 0 525m 214m 4372 S 0.0 21.6 1:31.61 Ruby
9829 xxxxxxxx 20 0 443m 205m 3312 S 0.0 20.6 1:27.67 Ruby
15597 xxxxxxxx 20 0 554m 176m 1268 S 0.0 17.8 4:59.36 Ruby
9780 xxxxxxxx 20 0 443m 63m 1088 S 0.0 6.4 0:28.80 Ruby
787 root 20 0 193m 17m 2608 S 2.0 1.7 350:43.06 driveclient
1556 xxxxxxxx 20 0 77876 11m 1020 S 0.0 1.1 18:54.78 remote_syslog
17415 root 20 0 73096 3364 2608 S 0.0 0.3 0:00.03 sshd
デジタルオーシャン
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20921 xxxxxxxx 20 0 240m 191m 5328 S 0.0 19.1 0:29.62 Ruby
21009 xxxxxxxx 20 0 204m 178m 5356 S 0.0 17.8 0:20.82 Ruby
21194 xxxxxxxx 20 0 204m 174m 1724 S 0.0 17.4 0:00.10 Ruby
21206 xxxxxxxx 20 0 204m 174m 1656 S 0.0 17.4 0:00.10 Ruby
21181 xxxxxxxx 20 0 98.3m 89m 2184 S 0.3 8.9 0:03.04 Ruby
1426 xxxxxxxx 20 0 117m 40m 2272 S 0.0 4.1 1:09.02 Ruby
1429 xxxxxxxx 20 0 117m 29m 2180 S 0.0 3.0 1:09.64 Ruby
1422 xxxxxxxx 20 0 117m 4652 1172 S 0.0 0.5 0:08.08 Ruby
22066 xxxxxxxx 20 0 7188 3456 1512 S 0.0 0.3 0:00.09 bash
22008 root 20 0 10008 3320 2664 S 0.0 0.3 0:00.03 sshd
Rackspaceを捨てるべきですか?
編集:グラフを展開します(ファイルのアップロードとプリコンパイルされたアセットの解凍を除く)
編集:vmstat
$ vmstat -S M 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 380 67 13 109 4 4 13 10 10 17 1 1 97 0
0 0 380 67 13 109 0 0 0 0 650 1011 0 1 99 0
0 0 380 67 13 109 0 0 0 0 675 1008 0 1 99 0
0 0 380 67 13 109 0 0 0 0 659 1009 0 0 100 0
1 0 380 67 13 109 0 0 0 68 661 1027 0 0 99 1
0 0 380 67 13 109 0 0 0 0 667 1014 0 0 100 0
1 0 380 67 13 109 0 0 0 0 671 1016 1 0 99 0
0 0 380 67 13 109 0 0 0 0 668 1008 0 0 99 0
0 0 380 67 13 109 0 0 0 0 671 1022 0 0 100 0
0 0 380 67 13 109 0 0 0 0 783 1112 9 3 89 0
私はRackspaceで働いており、この問題の解決をお手伝いしたいと思います。 1-800-961-4454までお電話いただければ、サーバーが稼働しているホストの状態を確認し、近隣の問題としてノイズが多いと思われる場合は、新しいサーバーに移動できます。また、この問題が発生しているときに、「vmstat -S M 1 10」、「sar -b」(しばらく経過した後)、およびおそらく「iostat -x/dev/xvdc 26」の出力を確認することにも興味があります。
ありがとう!
-ジミー
これは確かにI/Oのボトルネックのように見えますが、これはおそらくノイズの多い隣人が原因です。
Rackspaceに、ライブチャットに参加するか電話をかけて、別のホストに移動してもらいます。ホストは、移行の処理中にホストの使用状況を確認できる必要があります。
あなたが投稿したデータから、これは間違いなくラックスペースサーバーのI/Oボトルネックです。グラフが明確に示しているように、CPU時間のほとんどはI/O待機に費やされています(つまり、CPUはI/Oプロセスの終了を待機しています)。
これは通常、ディスク速度が遅いことが原因で発生します。これは仮想インスタンスであるため、ホストシステムのI/Oの多くを使用している他のインスタンスが存在する可能性があります。別のホスティング業者を見つける以外にできることはあまりありません(または、I/O負荷の少ない別のホストシステムに移行するように説得するか、別のホストシステムに別のサーバーを配置して、それが優れているかどうかを試してください)。