web-dev-qa-db-ja.com

クラウドサーバーでIOが遅いため、サーバーの再起動が遅くなりますか?

Rackspaceクラウドで2つのサーバーを実行しています。1つはWebアプリ用で、もう1つはdbおよびredisインスタンス用です。 Webサーバーには1GbのRAMとシングルコアがあります。 Nginxは、2人のワーカーを実行しているUnicornの前に座っています。また、sidekiqインスタンスを実行しています。この構成は適切に実行され、アプリがまだ起動されていないため、サーバーは通常、非常に低いCPUで動作します。

ただし、Unicornを再起動すると、アプリの完全なデプロイは言うまでもなく、すべての地獄が解き放たれます。これは次のようになります。 This isn't a great graph

基本的に私のサーバーは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を捨てるべきですか?

編集:グラフを展開します(ファイルのアップロードとプリコンパイルされたアセットの解凍を除く)

This is not the graph of a happy deploy

編集: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     
3
toxaq

私はRackspaceで働いており、この問題の解決をお手伝いしたいと思います。 1-800-961-4454までお電話いただければ、サーバーが稼働しているホストの状態を確認し、近隣の問題としてノイズが多いと思われる場合は、新しいサーバーに移動できます。また、この問題が発生しているときに、「vmstat -S M 1 10」、「sar -b」(しばらく経過した後)、およびおそらく「iostat -x/dev/xvdc 26」の出力を確認することにも興味があります。

ありがとう!

-ジミー

2
RackerJimmy

これは確かにI/Oのボトルネックのように見えますが、これはおそらくノイズの多い隣人が原因です。

Rackspaceに、ライブチャットに参加するか電話をかけて、別のホストに移動してもらいます。ホストは、移行の処理中にホストの使用状況を確認できる必要があります。

1
Kyle Kelley

あなたが投稿したデータから、これは間違いなくラックスペースサーバーのI/Oボトルネックです。グラフが明確に示しているように、CPU時間のほとんどはI/O待機に費やされています(つまり、CPUはI/Oプロセスの終了を待機しています)。

これは通常、ディスク速度が遅いことが原因で発生します。これは仮想インスタンスであるため、ホストシステムのI/Oの多くを使用している他のインスタンスが存在する可能性があります。別のホスティング業者を見つける以外にできることはあまりありません(または、I/O負荷の少ない別のホストシステムに移行するように説得するか、別のホストシステムに別のサーバーを配置して、それが優れているかどうかを試してください)。

1
etagenklo