🐛 Bug
我在NFS共享上初始化了一个名为aim init的目录，并运行了几个指向该目录的任务。
最初，所有的指标和参数都正确地记录下来，但过了一段时间后，日志记录停止了，似乎开始反复从日志中失败。
aimrocks.errors.RocksIOError: b'IO error: While appending to file: /nas/projects/auto-ml/models/pkubik/pc/.aim/meta/chunks/07a1749cee044a69a80226d82f0d0b0c/000027.log: Input/output error'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: While appending to file: /nas/projects/auto-ml/models/pkubik/pc/.aim/meta/chunks/07a1749cee044a69a80226d82f0d0b0c/000027.log: Input/output error'
Exception ignored in: 'aimrocks.lib_rocksdb.DB.write'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: While appending to file: /nas/projects/auto-ml/models/pkubik/pc/.aim/meta/chunks/07a1749cee044a69a80226d82f0d0b0c/000027.log: Input/output error'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'
Exception ignored in: 'aimrocks.lib_rocksdb.DB.write'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'
Exception ignored in: 'aimrocks.lib_rocksdb.DB.write'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'
Exception ignored in: 'aimrocks.lib_rocksdb.DB.write'
Traceback (most recent call last):
File "src/aimrocks/lib_rocksdb.pyx", line 89, in aimrocks.lib_rocksdb.check_status
aimrocks.errors.RocksIOError: b'IO error: Stale file handle'(这个重复几次，我想每次尝试记录日志时都会重复)
经过手动检查，提到的文件似乎已经不存在了。在给定的目录中有一个类似的日志文件，编号更高-在这种情况下是000039.log,以及一堆其他文件：
000024.sst 000026.sst 000028.sst 000032.sst 000038.sst 000039.log 000040.sst CURRENT IDENTITY LOCK LOG LOG.old.1654955991303666 MANIFEST-000033 OPTIONS-000007 OPTIONS-000036重现问题
使用以下命令设置训练任务：
aim_run = aim.Run(
run_hash=name,
repo=os.environ.get("AIM_ROOT_DIR"), # shared NFS directory for multiple jobs
experiment=experiment_name,
)继续进行训练，每分钟记录一组指标。
预期行为
指标将持续记录。
环境
- Aim v3.10.3
- Python 3.8.12
- pip 21.2.4
- Ubuntu 20.04,来自NVidia NVCR docker镜像nvcr.io/nvidia/pytorch:22.03-py3
- 在Kubernetes集群上
7条答案
按热度按时间wpx232ag1#
@mahnerak你以前遇到过这样的错误吗？我记得你之前为Aim设置了NFS。
cczfrluj2#
在我重启任务后，它们似乎继续正确地进行日志记录，没有错误，但是在指标中存在预期的间隙(由于错误而未记录的时间)。
ca1c2owp3#
我在我的NFS设置中看到了很多陈旧的句柄错误(在不涉及aim的情况下)。
我想这主要是一个NFS问题，但我会调查一下。
请让我知道将来是否会发生这样的NFS特定问题。
zkure5ic4#
在集群上运行单个aim服务器并通过TCP附加我的作业是否通常更安全？
crcmnpdw5#
我不一定非要关注陈旧的句柄错误。最重要的部分似乎是进程试图追加一个已经不存在的日志文件。每个任务可能只访问自己的文件，UI最有可能不更改任何文件。
我想这可能是由于Pytorch中发生的多处理引起的。
NFS也可能存在一些不一致性，因为它相当古老和疯狂。这个错误是否是由于某种缓存机制引起的？
我粘贴在问题顶部的文件结构是针对aim还是rocksdb的特定吗？
n53p2ov06#
关于你的第一个问题：在集群上运行单个Aim服务器并通过TCP附加我的作业是否更安全？
aim server用于多个用户的远程跟踪。它运行得相当好，但仍被认为是一个实验性功能。我们计划修复已知的问题，并在下一个里程碑发布一个稳定版本。如果你现在正在尝试使用它，需要注意以下几点：至于你的第二个问题，.log和.sst文件是
rocksdb的内部文件。.log是一个预写日志，根据使用的选项进行刷新。一般来说，由于它由单个进程管理，不应该出现丢失.log文件的情况，但这可能是rocksdb端的一个bug。我们必须进一步调查这个问题以确定。dluptydi7#
我经常遇到这个问题。
类似的情景，可能要求更高：我在一个NFS挂载的文件夹中有一个单一的Aim仓库，其中有许多Lightning DDP SLURM作业记录到它。我的日志记录速率相当低，一次每50个训练迭代(我认为这是可以的，因为我正在训练一个速度较慢的模型，大约每2次训练迭代/秒前进)。由于我使用DDP,每个SLURM作业有16-64个Lightning Trainer(每个进程/GPU 1个Trainer),大约有8个作业在运行。因此，在每个运行的每次50个训练迭代中，我有8 * (16-64) = 128-512个进程向单个Aim仓库记录日志(每个运行一次Aim运行)。所以大约每2分钟左右，我从128-512个进程向单个Aim仓库记录日志。
这似乎不会对指标方面产生任何问题，但确实需要很长时间才能在Metrics Explorer中加载更多的运行。我说的是几分钟，有时甚至永远无法加载(当出现故障时),需要多次重启。
此外，每1000个训练迭代，我为每个作业/运行记录约2000张64x64分辨率的图像。总之，每34分钟大约有8个作业 * 2000张图像 = 16000张图像。现在，即使只是在Images Explorer中加载其中的两个作业，也是一场赌博。根据到目前为止已记录的图像数量以及我在Images Explorer中同时查看的运行数量，我要么等待5-10分钟，要么出现故障并崩溃。我可以肯定地减少我正在记录的图像数量，但仍然惊讶于每次我想在浏览器中更改查询时，我都必须等待它检查所有运行，等待数十分钟。我本以为它不会尝试筛选出所有可能的日志并仅给我最近的K个已记录图像。
无论如何，关于这种高强度使用Aim的问题，4.0版本会带来改进吗？我希望能够自由地记录和查看所需的内容，而不必等待，不必经历aimrocks错误等问题，只受到CPU带宽的限制。