您使用哪种 Web 服务器硬件来处理 100 Mbps 以上的静态文件？

Question

我目前使用 Amazon S3 来满足我的大部分静态文件服务需求，但我的每月账单变得非常昂贵。我使用日志做了一些粗略的计算，在高峰时间，我最昂贵的亚马逊存储桶正在处理大约100180 Mbps 的流量。主要是 50K 以下的图像。

S3 在存储和冗余方面非常有帮助，但如果我能提供帮助，我真的不需要为带宽和 GET 请求付费。我在自己的数据中心有很多廉价的带宽，所以我将一个 nginx 服务器配置为缓存代理，然后用我的大部分文件（大约 240 GB）准备缓存，这样我的磁盘就不会像疯了一样写入空缓存。

我尝试切换，但我的服务器窒息了。

看起来我的磁盘有问题 - 这台机器有 4 x 1 TB SATA 磁盘 (Barracuda XT) 以 RAID 10 设置。这是我手头唯一有足够存储空间用于此的东西。我很确定 nginx 设置正确，因为我已经将它用作另一个较小的 Amazon 存储桶的缓存代理。假设这是一台机器的合理流量，也许 SSD 值得一试。

如果您处理大量静态文件服务，您使用什么硬件？

附加信息

文件系统：ext4，已挂载 noatime，barrier=0，data=writeback，nobh（控制器上有备用电池） Nginx：worker_connections = 4096，worker_rlimit_nofile 16384，worker_processes 8，open_file_cache max=100000 inactive=60m

Answer 1

我不认为你的磁盘有问题。首先，nginx 的 ncache 使用磁盘存储进行缓存。因此，磁盘速度将成为问题的潜在原因之一，具体取决于数据集的热/冷程度，但是，我认为您没有理由不能使用您提到的硬件提供 100mb/秒的服务 - 特别是如果您“正在使用 nginx。

我猜测的第一件事是您的工作进程数很低，您的worker_connections可能太低，并且您可能没有将open_file_cache设置得足够高。然而，这些设置都不会导致高 IO 等待或类似的峰值。您说您正在提供 <50k 图像，看起来您的图像集的 1/4 可以轻松地由操作系统缓冲。Nginx 肯定没有配置最佳。

Varnish 处理这个问题的方式略有不同，使用 RAM 而不是磁盘作为缓存。

很大程度上取决于您的数据集，但是，根据您提供的数据，我认为磁盘 IO 没有任何理由出现这样的峰值。您是否检查过 dmesg 和日志以查看您的某个驱动器当时是否遇到了一些 IO 错误？我认为可能导致峰值的唯一另一件事是超出了 nginx 的文件缓存，这将导致它必须进入 FIFO 模式来打开新文件。

确保您的文件系统安装了 noatime，这应该会减少您的工作负载中大量的写操作。

以经常处理 800mb/秒的机器为例：

# uptime
 11:32:27 up 11 days, 16:31,  1 user,  load average: 0.43, 0.85, 0.82

# free
             total       used       free     shared    buffers     cached
Mem:       8180796    7127000    1053796          0       1152    2397336
-/+ buffers/cache:    4728512    3452284
Swap:      8297568     237940    8059628

Quadcore Xeon:
    Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz

$ ./bw.pl xxx.xxx 2010-09-01 2010-09-30
bw: 174042.60gb

average 543mb/sec, peaks at 810mb/sec

=== START OF INFORMATION SECTION === Model Family:     Seagate Barracuda
7200.12 family Device Model:     ST3500418AS Serial Number:    6VM89L1N
Firmware Version: CC38 User Capacity: 
500,107,862,016 bytes

Linux 2.6.36-rc5 (xxxxxx)   10/04/2010  _x86_64_    (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.33    0.00    2.40    5.94    0.00   87.33

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             109.61     19020.67       337.28 19047438731  337754190

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.09    0.00    3.40   10.26    0.00   78.25

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             138.52     21199.60       490.02     106210       2455

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.74    0.00    3.25    9.01    0.00   84.00

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             125.00     21691.20       139.20     108456        696

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.75    0.00    3.12   14.02    0.00   78.11

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             154.69     19532.14       261.28      97856       1309

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.81    0.00    3.36    9.48    0.00   80.36

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda             112.80     17635.20       309.00      88176       1545

MRTG：

https://i.stack.imgur.com/CRqPi.png

数据集：

# du -sh ads
211.0G  ads

# ls|wc -l
679075