🐛 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带宽的限制。