我有一个文件共享网站，我的文件托管在具有以下系统规格的服务器上：
32GB RAM
12x3TB
2x Intel Quad Core E5620
我在这个服务器上有文件，每个文件最多 4GB。446GB 已满 (/36TB)
[root@hosted-by ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 2.7G 44G 6% /
tmpfs 16G 0 16G 0% /dev/shm
/dev/sda1 97M 57M 36M 62% /boot
/dev/mapper/VolGroup01-LogVol00
33T 494G 33T 2% /home
再看看这个：
为什么wa%这么高？（我认为这就是服务器速度这么慢的原因）
答案1
服务器上的磁盘是如何设置的，我假设您没有使用任何 RAID 实现来加快磁盘读/写速度（因为磁盘使用情况显示 LVM 组为 33TB），这是您的问题。
由于以前的答案是正确的，'wa'代表磁盘 I/O 等待，它非常高，实际上锁定了您的服务器并将任何依赖磁盘 I/O 的进程置于不间断的睡眠状态（顶部标记为“D”的进程） - 问题是您无法通过向这些进程发送 SIGKILL 信号来清除这些进程，它们直到从磁盘获得想要的内容后才会响应，然后它们才会退出。
可以通过减少磁盘 I/O 等待来清除 D 状态下的进程，这将清除进程或重新启动服务器，而重新启动是您最不想做的事情，如果您需要进行文件系统检查（fsck），则需要很长时间才能在慢速磁盘上浏览 33TB 的数据，甚至在 RAID 设置上也需要很长时间。
如果每台服务器使用大量磁盘，请考虑获取带有高质量 RAID 卡的服务器并将磁盘设置为 RAID6，这样，如果发生磁盘故障，您将获得更好的速度和冗余，因为 RAID6 可以承受两个故障的 HDD，而其他 RAID 配置可以承受 1 个故障磁盘。
此外，当您拥有新的服务器设置时，请查看 RAID 阵列健康监控，einarc 将有助于确定 RAID 阵列并显示您的 RAID 阵列是否存在任何问题。使用 RAID 设置，您将牺牲一些磁盘空间，但与当前设置相比，您将获得更好的读/写速度。
如果您有 12 个 3TB 驱动器并将它们置于 RAID 6 配置中，则计算您拥有的磁盘空间的公式是(N – 2) x (Smallest HDD size)，因此在 12 个 3TB 磁盘上您将拥有 30TB 的可用磁盘空间：
(12 - 2) x 3TB = 30TB
另外还有一个建议，如果您只使用此服务器来提供文件，我建议您切换到 nginx，与 Apache 服务器相比，nginx 在资源利用率和性能方面都更胜一筹，Apache 服务器在一定程度上表现不错。但这取决于您的系统设置。
答案2
“wa” 表示等待，这意味着您的 CPU 正在等待某些 I/O 操作完成。问题很可能与从磁盘读取/写入文件有关。您应该考虑根据 HDD I/O 操作需求调整系统。
某些时候，您可能希望在多台机器（具有较低的 CPU 规格）上分配 HDD 空间。
另一个想法是使用 SSD 进行缓存（特别是如果您可以预测某些文件的使用情况）。这需要额外的开发，但这可能是最便宜的解决方案。
答案3
乍一看，您的 IO 子系统似乎不足以完成这项任务。我相信队列理论中有这样的说法，当利用率达到 100% 时，服务时间将趋于无穷大。这实际上也是一个相当突然的事情，利用率达到 80% 左右时，服务时间将急剧增加。
以下是一些可供检查的其他工具：
- Linux sysstat（sar -d）应该会告诉您磁盘的计算利用率，可能值得检查它们是否实际达到或接近 100%（尽管它看起来像这样）
- iotop 可以帮助你确定是用户在驱动你的 IO 负载，还是其他原因
我确实注意到，您似乎只有很少的内存可用于 Linux 磁盘/块缓存，尽管添加 RAM 只能帮到您目前，但如果您可以将热集放入内存中，或者至少将热集的大部分放入内存中，那就太棒了。实际上，您也有一些方法进入交换区，这也不是一件好事，并且根据交换区的位置，它可能会增加您的 IO 负载。
但是，如果您的磁盘系统 IO 容量确实达到（或接近）100% 利用率，那么可能就该重新考虑一下您的存储方式了，首先坐下来实际研究一下用户负载的 IO 要求是什么（IOPS 的数量、读取和/或写入密集型、是随机访问还是顺序访问、热设置有多大等、所需的总带宽是多少等），然后设计一个可以满足上述要求的解决方案（服务器/存储）。