也许，我将这个问题标记为"功能请求"是一个错误，实际上我只是在想我的用例(即~10K-50K次运行)是否适用于Aim,以及我是否应该稍后重新审视Aim。

@Yura52 奇怪的是，这个问题还没有得到解答。
这完全在Aim的范围内。
我们一直在优化大量的运行(可以理解的是，这有许多不同的维度可以进行优化)。
有Aim用户每月运行10-30K次，也有基准测试。
最近，由于#2654中连续运行的次数过多，我们遇到了“打开的文件过多”的问题。
我们正在努力解决这个问题。一个临时解决方案将尽快发布。然后有一个
传统上，对于深度学习的情况，没有必要为许多连续运行进行优化。
对于较小的运行或LLMOPs运行，现在情况已经不再如此。
@Yura52 如果你能分享更多关于你的设置的信息，我们就可以尝试复制你所面临的问题。这也有助于未来的用户，当我们改进像你这样的案例的性能时。

感谢您的回复！目前，我的项目正在进行中，但如果它被公开发布，我会尝试制作一个最小快照来重现问题。

快速解决方法是使用 ulimit -n 来增加最大打开文件描述符的限制。

P.S. 我可能会建议在 Aim 上故意使用较低的限制进行性能测试，例如：

...以确保它没有泄漏描述符或其他类似问题。

编辑：找到了一个可能的原因 #1786(评论)。
有时候，我需要进一步增加 ulimit -n。当我多次应用 run.get_metric() 到许多运行(后训练)时会发生这种情况。当我在后台有其他不相关的 I/O 运行时，Aim 查询/读取指标 API 也会变慢。也许这是由于许多小文件的大量 I/O 寻址或许多非顺序/随机读取引起的？
我正在做类似以下操作：

...我想暂时的解决方法是做类似这样的事情：

...但理想情况下，最好不要手动打开/关闭运行。