我的云服务器上的 I/O 速度慢是否导致服务器重启速度慢的问题？

Question

我在 Rackspace 云上运行了两台服务器，一台用于 Web 应用程序，另一台用于数据库和 redis 实例。Web 服务器有 1GB 的 RAM 和单核处理器。Nginx 位于 unicorn 前面，unicorn 运行着 2 个 worker。我还运行着一个 sidekiq 实例。此配置运行良好，服务器通常以非常低的 CPU 运行，因为应用程序尚未启动。

然而，当我重启 Unicorn 时，更不用说部署完整的应用了，一切都乱套了。它看起来像这样：

基本上我的服务器 3 分钟内就瘫痪了。有时它还能响应，但监控却到处触发停机警报（这只是零停机重启）。

如果我进行完整部署，即使我正在预编译资产并上传，图表也会跨越大约 8 分钟，因此没有服务器上编译。

对我来说有趣的部分是，我在 DigitalOcean 上运行着一个完全相同的服务器设置。我可以完全重启整个服务器shutdown -r，并在 50 秒内启动并提供页面。对于这个 Rackspace 服务器，我不敢重启它，即使是为了测试，因为这会给我的生产服务器带来非常长的停机时间。

我不是 Linux 服务器管理员，所以我想知道是否有人可以告诉我这是否是 Rackspace 云服务器的常态。我有十年运行一些专用 Windows 机器的经验，从未遇到过这样的问题。

针对服务器的 hdparm。

Rackspace：

$ 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 

数字海洋

$ 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 服务器实际上正在运行两个应用程序，因此比 RS 服务器执行的工作更多。两个 hdparm 运行时的服务器负载大致相同（即非常小）。这纯粹是因为磁盘速度慢，还是还有其他原因？

两台服务器均位居榜首

Rackspace

 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     

Answer 1

我在 Rackspace 工作，我们很乐意帮助您解决此问题。如果您能拨打 1-800-961-4454 给我们打电话，我们可以检查您的服务器所在主机的运行状况，如果确实存在嘈杂邻居问题，我们可以将其移至新主机。当此问题发生时，我还想查看“vmstat -SM 1 10”、“sar -b”（经过一段时间后）以及“iostat -x /dev/xvdc 2 6”的输出。

谢谢！

-吉米

Answer 2

从您发布的数据来看，这肯定是 Rackspace 服务器上的 I/O 瓶颈。如您的图表所示，大部分 CPU 时间都花在了 I/O 等待上（即 CPU 正在等待 I/O 进程完成）。

这通常是由于磁盘速度慢造成的，而且由于这是一个虚拟实例，可能还有其他实例占用了主机系统的大部分 I/O。除了寻找其他主机提供商（或者说服他们将您迁移到 I/O 负载较少的另一个主机系统，或者在另一个主机系统上安装另一台服务器并尝试那个服务器是否更好）之外，我认为您能做的不多。

Answer 3

这显然看起来像是一个 I/O 瓶颈，可能是由吵闹的邻居造成的。

通过进入他们的实时聊天或拨打电话，让 Rackspace 将您迁移到另一个主机。他们应该能够在处理您的迁移时检查主机的使用情况。