☰

下载速度变慢时去哪里寻找瓶颈？

tag-icon • tag-icon apache-2.2 centos bottleneck
下载速度变慢时去哪里寻找瓶颈？

我们网站的图片下载速度每晚都会变慢。与白天相比，晚上的流量增加了 50%。具体来说，白天每小时页面浏览量约为 20k，晚上每小时页面浏览量约为 30k。

我们使用 Apache、Centos 5、PHP 5 和 MySQL。

下图显示了每 10 分钟从特定远程站点下载特定 3MB 图像的时间。随着站点流量的增加，下载速度会下降一半。

替代文本

  • 我们的 CPU 使用率不高。我们有两个四核 CPU。
  • 32GB内存。
  • Mysql 使用大约 10GB 内存。
  • Apache 服务器状态显示高峰时段大约有 40-50 个并发进程。每个进程占用大约 30-40MB 的常驻内存。因此大约有 2GB 内存分配给 Apache。

其余内存（约 20GB）留给 Linux 使用。vmstat、free -m 未显示任何交换。以下是 vmstat 输出：

# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0    220 409700 491656 25727136    0    0     9    42    1    1  1  0 98  0  0
 2  0    220 408076 491656 25727140    0    0     0  2032 1916 1992  2  1 98  0  0
 0  0    220 405848 491656 25727180    0    0     0     0 1631 1325  1  0 99  0  0
 0  0    220 404992 491656 25727180    0    0     0     0 1508 1203  1  0 99  0  0
 3  0    220 405228 491656 25727216    0    0     0     0 1548 1600  2  1 98  0  0
 0  0    220 404236 491656 25727224    0    0     0     0 1860 1645  2  1 97  0  0
 1  0    220 403916 491656 25727284    0    0     0  2512 1817 1035  2  1 97  0  0
 0  0    220 403900 491656 25727284    0    0     0  2164 1826 1678  1  1 98  0  0
 0  0    220 408908 491656 25727312    0    0     0   828 1636  952  1  0 99  0  0
 0  0    220 408544 491656 25727312    0    0     0     0 1844 1991  1  1 98  0  0
 1  0    220 407856 491664 25727328    0    0   180     0 1567 1194  4  0 96  0  0
 0  0    220 406772 491664 25727460    0    0     0     0 1290 1049  4  1 95  0  0
 0  0    220 406964 491664 25727548    0    0    28   208 1589  904  1  0 99  0  0
 0  0    220 406840 491664 25727560    0    0     0  1796 1885 1396  1  0 99  0  0
 1  0    220 405136 491664 25727612    0    0     0     0 1727 1280  1  0 98  0  0
 0  0    220 404400 491664 25727628    0    0    24     0 1807 1494  1  0 98  0  0
 1  2    220 403996 491668 25727812    0    0   232     0 2221 1633  1  1 97  1  0
 0  0    220 404228 491668 25727844    0    0    20  1776 1673 1332  1  0 97  1  0
 0  0    220 403688 491672 25727988    0    0    68   348 1508  977  1  0 99  0  0
 0  0    220 403444 491672 25728004    0    0     0     0 1436  900  1  0 99  0  0
 0  0    220 403948 491672 25728104    0    0     0     0 1413 1131  1  0 99  0  0
 1  0    220 392984 491672 25728104    0    0     0  1520 1455 1946  5  2 93  0  0
 1  0    220 307264 491672 25728124    0    0     0    12 1829 1520  8  2 91  0  0
 4  0    220 306276 491672 25728132    0    0     0     0 1364 1497  7  0 92  0  0
 1  0    220 305320 491672 25728160    0    0     0     0 1510 1773  9  1 90  0  0
 1  0    220 305444 491672 25728164    0    0     0     0 1620 1666  7  0 93  0  0
 1  0    220 304456 491672 25728208    0    0     0  3396 1813 1836  7  0 93  0  0

由于此特定测试图像每 10 分钟调用一次，因此它应该保留在 OS Cache 中并从 OS Cache 中传送，对吗？CPU 一点也不忙。所以图像应该很快就传送了？

我在这里遇到的瓶颈是什么？
- 安装第二个硬盘只是为了托管图像有帮助吗？
- 如何使用 PHP APC 来减少 CPU 负载？

有什么建议可以诊断这个问题吗？

谢谢，哈鲁克

更新：
根据 Knitti 的建议，我在内存挂载目录中设置了相同的图像。
以下是昨天的结果：
记忆已安装 3MB 图像：
替代文本

硬盘3MB 图片：

替代文本

平均而言，它们非常接近。它们都受到晚间交通的影响。内存中的图像有时传输速度比硬盘慢。我认为这说明它们都在内存中，这是理所当然的。

所以我认为这不是硬盘瓶颈问题。

-也许这与 Apache 有关？
-或者与网络有关？

这是晚上的 sar -n ALL 输出。据此，我们在 10 分钟内发送的流量平均值不超过 400kb/s。我们的带宽是 10mbps，所以我们甚至还没有用到一半。

                IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
08:10:01 PM        lo      0.63      0.63     66.48     66.48      0.00      0.00      0.00
08:10:01 PM      eth0    342.69    431.72  59755.43 368330.14      0.00      0.00      0.00
08:10:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:10:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:20:01 PM        lo      0.43      0.43     45.08     45.08      0.00      0.00      0.00
08:20:01 PM      eth0    310.96    389.32  62960.35 327811.74      0.00      0.00      0.00
08:20:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:20:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:30:01 PM        lo      0.68      0.68     71.97     71.97      0.00      0.00      0.00
08:30:01 PM      eth0    341.29    421.12  69692.70 354844.36      0.00      0.00      0.00
08:30:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:30:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:40:01 PM        lo      0.79      0.79     87.60     87.60      0.00      0.00      0.00
08:40:01 PM      eth0    365.76    451.49  66813.87 385379.38      0.00      0.00      0.00
08:40:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:40:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00

08:40:01 PM     IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s   rxcmp/s   txcmp/s  rxmcst/s
08:50:01 PM        lo      0.47      0.47     49.49     49.49      0.00      0.00      0.00
08:50:01 PM      eth0    336.77    413.37  57303.78 357556.44      0.00      0.00      0.00
08:50:01 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:50:01 PM      sit0      0.00      0.00      0.00      0.00      0.00      0.00      0.00


08:00:01 PM    totsck    tcpsck    udpsck    rawsck   ip-frag
08:00:01 PM       218        21         9         0         0
08:10:01 PM       200        21         9         0         0
08:20:01 PM       211        22         9         0         0
08:30:01 PM       205        22         9         0         0
08:40:01 PM       191        21         9         0         0
08:50:01 PM       201        21         9         0         0

答案1

听起来像是网络问题。在非高峰时段和高峰时段对图像下载进行数据包捕获。比较两者，看看是否收到大量 RST。

答案2

  • 如果您从 ramdisk/内存 fs 提供一些文件，您可以检查另一个磁盘是否有帮助。没有什么比内存速度更重要。
  • 计算您的下载速度乘以您的并发下载量。也许您的上行连接带宽不足。
  • 从第三（第四、第五）个位置进行检查，以确保您没有遇到下载位置的限制。

答案3

您需要对 TCP ACK 数据包进行优先级排序。请参阅http://phix.me/dm/

相关内容