我们有一个集中式文件缓存，一组 Web 服务器用它来存储“重量级”页面。每个 Web 服务器都使用 Samba 来挂载这个共享区域。
我们的服务器上有大量 iowait，我想知道我们可以采取哪些步骤来构建更高效的集中缓存？我们已经将 memcache 用作某些对象的首行缓存，并且可能只是为此投入更多内存，但我感兴趣的是找出可以使用哪些技术来加速基于文件的缓存。所有服务器都运行最新版本的 Ubuntu。
服务器使用带有 LVM 的 ext3 文件系统。也许其他文件系统对于此类活动来说性能会更好？我们使用 Samba 多年，只是因为每个人都熟悉它，而且我们在 NFS 维护方面遇到了麻烦（例如拒绝卸载）。也许有更好的技术……
答案1
检查分配给该卷的 io 调度程序（在内核文档中称为 io 电梯）。
$ cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
对于大多数 RedHat 和 Fedora 发行版，默认是 CFQ 调度程序。恕我直言，这不是 iobound 服务器进程的最佳选择。我推荐 deadline 调度程序
$ echo "deadline" > /sys/block/sda/queue/scheduler
改变这一点，或者添加
elevator=deadline
到您的启动参数以使其永久生效。
高 iowait 时间也可能由过度预读导致，这对您的工作负载来说可能是不必要的。RedHat 和 Fedora 系统的默认值为 128k
$ cat /sys/block/sda/queue/read_ahead_kb
128
尝试将较低的值回显到该文件并查看是否可以减少 iowait 时间。
另外，请检查底层磁盘或阵列。如果它已降级或正在重建，您的 iowait 时间将飙升，因为底层磁盘子系统在重建自身时会窃取 io 带宽
答案2
服务器上较高的 IOWait% 意味着您需要更快的磁盘/更多的内存用于磁盘缓存。
看看你的“iostat -x 5”统计数据 - 你的磁盘是否已饱和？根据你的应用程序语义，文件服务器上的更多内存可能对你有好处。
如果服务器存储和检索页面之间存在较长的延迟，则需要更快的磁盘。
检查 free 的输出以查看您有多少内存以及它用于什么用途。
答案3
由于 Samba 是通过网络访问的，因此我认为您的网络首先是瓶颈。链接是否针对通过网络的文件/数据包的类型和大小进行了优化？
您能否监控这些链接以了解它们的利用率？
如果网络似乎不是瓶颈，那么您可以查看以下提示本指南稍微优化一下你的 Samba 配置。
编辑
您提到了 LVM，它们是什么类型的磁盘？普通的现成 7200RPM IDE 驱动器？如果真的是 IO 等待，那么是的，您需要更快的磁盘。这可能就像 SATA 10k 驱动器一样简单，甚至可以进入高性能 raid。
答案4
另一个选择是使用反向代理缓存解决方案，如 Squid 或 varnish，而不必通过不同的层来获取相同的数据。只需考虑一下，因为这样的解决方案将针对提供网页进行优化（而不是更通用的文件服务解决方案）。