我在特定情况下遇到了服务器速度变慢的问题。事实是:
- 1)我使用计算应用程序 WRF(天气研究和预报)
- 2)我使用配备 128GB RAM 的双 Xeon E5-2620 v3(NUMA 架构 - 可能与问题有关!)
- 3)我使用 mpirun -n 22 wrf.exe 运行 WRF(我有 24 个可用的逻辑核心)
- 4)我使用 Centos 7 和 3.10.0-514.26.2.el7.x86_64 内核
- 5)从计算性能来看,一切运行正常,直到发生以下情况:
- 5a)Linux 文件缓存获取一些数据,或者
- 5b)我使用 tmpfs 并向其中填充一些数据
在 5a 或 5b 场景中,我的 WRF 开始突然变慢,有时甚至比正常情况慢 5 倍。
- 6) RAM 没有被交换,这甚至还没有接近发生,在最坏的情况下,我有大约 80% 的可用 RAM!
- 7) /etc/sysctl.conf 中的 vm.zone_reclaim_mode = 1 似乎有助于延迟 5a 场景中的问题
- 8) echo 1 > /proc/sys/vm/drop_caches 在 5a 场景中完全解决问题,将 WRF 性能恢复到最大速度,但只是暂时的,直到文件缓存再次获取数据,因此我在 cron 中使用此命令(别担心,没问题,我只将计算机用于 WRF,它不需要文件缓存即可发挥全部性能)
- 9)但是,上述命令在 5b 场景中仍然没有任何作用(当我使用 tmpfs 来存储临时文件时)
- 10)只有我手动清空 tmpfs,性能才会在 5b 场景中恢复
- 11)这不是WRF或mpi的问题
- 12) 这种情况只发生在这一种类型的计算机上,我管理了很多这种类型的计算机,用于相同/类似的目的 (WRF)。只有这台计算机具有完整的 NUMA 架构,所以我怀疑这与它有关
- 13)我也怀疑 RHEL 内核与此有关,但不确定,还没有尝试重新安装到不同的发行版中
- 14) numad 和 numactl 选项调用 mpirun 类似“numactl -l”,没有任何区别
如果您有任何想法可以尝试避免这些减速,请告诉我。
在关注了这个问题的一些“相关”链接后,我突然想到了一个主意。透明大页面会是这个问题的根源吗?一些文章强烈暗示 THP 在 NUMA 系统上运行不佳。
答案1
我建议启用 numad 服务:
yum install numad
systemctl enable numad
systemctl start numad
numad 应该能够自动处理内存局部性。进程在第一个 NUMA 节点的 CPU 上运行,但其数据在第二个 NUMA 节点本地的 RAM 中的情况应该不再发生(除非所需内存量大于单个 NUMA 节点本地 RAM 的容量)。
我还建议使用最适合您使用场景的配置文件来配置经过调整的服务。您必须衡量差异并选择最佳的(或者您可以创建一些自定义的)。
也许我已经找到你节点上出现奇怪行为的原因了。我搜索了 mpirun 并找到了手册页:
https://www.open-mpi.org/doc/current/man1/mpirun.1.php
有记载:
快速摘要
如果您只是想知道如何运行 MPI 应用程序,那么您可能想要使用以下形式的命令行:% mpirun [ -np X ] [ --hostfile ] 这将在您当前的运行时环境中运行 X 个副本(如果在受支持的资源管理器下运行,Open MPI 的 mpirun 通常会自动使用相应的资源管理器进程启动器,而不是例如 rsh 或 ssh,它们需要使用主机文件,或者默认在本地主机上运行所有 X 个副本),默认情况下按 CPU 插槽以循环方式进行调度。有关更多详细信息,请参阅本页的其余部分。
请注意,从 v1.8 系列开始,mpirun 会自动绑定进程。在没有任何其他指令的情况下,使用三种绑定模式:
绑定到核心:当进程数<= 2时
绑定到套接字:当进程数> 2时
无约束:超额认购时
如果您的应用程序使用线程,那么您可能希望确保根本不受绑定(通过指定 --bind-to none),或者使用适当的绑定级别或每个应用程序进程特定数量的处理元素绑定到多个核心。
在您的例子中,n=22,没有应用绑定,线程可以重新定位。您可以尝试外部 CPU 绑定(例如使用任务集)。您必须进行实验。