![我的云服务器上的 I/O 速度慢是否导致服务器重启速度慢的问题?](https://linux22.com/image/615145/%E6%88%91%E7%9A%84%E4%BA%91%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E7%9A%84%20I%2FO%20%E9%80%9F%E5%BA%A6%E6%85%A2%E6%98%AF%E5%90%A6%E5%AF%BC%E8%87%B4%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%87%8D%E5%90%AF%E9%80%9F%E5%BA%A6%E6%85%A2%E7%9A%84%E9%97%AE%E9%A2%98%EF%BC%9F.png)
我在 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
答案1
我在 Rackspace 工作,我们很乐意帮助您解决此问题。如果您能拨打 1-800-961-4454 给我们打电话,我们可以检查您的服务器所在主机的运行状况,如果确实存在嘈杂邻居问题,我们可以将其移至新主机。当此问题发生时,我还想查看“vmstat -SM 1 10”、“sar -b”(经过一段时间后)以及“iostat -x /dev/xvdc 2 6”的输出。
谢谢!
-吉米
答案2
从您发布的数据来看,这肯定是 Rackspace 服务器上的 I/O 瓶颈。如您的图表所示,大部分 CPU 时间都花在了 I/O 等待上(即 CPU 正在等待 I/O 进程完成)。
这通常是由于磁盘速度慢造成的,而且由于这是一个虚拟实例,可能还有其他实例占用了主机系统的大部分 I/O。除了寻找其他主机提供商(或者说服他们将您迁移到 I/O 负载较少的另一个主机系统,或者在另一个主机系统上安装另一台服务器并尝试那个服务器是否更好)之外,我认为您能做的不多。
答案3
这显然看起来像是一个 I/O 瓶颈,可能是由吵闹的邻居造成的。
通过进入他们的实时聊天或拨打电话,让 Rackspace 将您迁移到另一个主机。他们应该能够在处理您的迁移时检查主机的使用情况。