aimrocks RocksIOError on NFS share

uemypmqf  于 4个月前  发布在  其他
关注(0)|答案(7)|浏览(56)

🐛 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集群上
wpx232ag

wpx232ag1#

@mahnerak你以前遇到过这样的错误吗?我记得你之前为Aim设置了NFS。

cczfrluj

cczfrluj2#

在我重启任务后,它们似乎继续正确地进行日志记录,没有错误,但是在指标中存在预期的间隙(由于错误而未记录的时间)。

ca1c2owp

ca1c2owp3#

我在我的NFS设置中看到了很多陈旧的句柄错误(在不涉及aim的情况下)。
我想这主要是一个NFS问题,但我会调查一下。
请让我知道将来是否会发生这样的NFS特定问题。

zkure5ic

zkure5ic4#

在集群上运行单个aim服务器并通过TCP附加我的作业是否通常更安全?

crcmnpdw

crcmnpdw5#

我不一定非要关注陈旧的句柄错误。最重要的部分似乎是进程试图追加一个已经不存在的日志文件。每个任务可能只访问自己的文件,UI最有可能不更改任何文件。

我想这可能是由于Pytorch中发生的多处理引起的。
NFS也可能存在一些不一致性,因为它相当古老和疯狂。这个错误是否是由于某种缓存机制引起的?
我粘贴在问题顶部的文件结构是针对aim还是rocksdb的特定吗?

n53p2ov0

n53p2ov06#

关于你的第一个问题:在集群上运行单个Aim服务器并通过TCP附加我的作业是否更安全?

aim server 用于多个用户的远程跟踪。它运行得相当好,但仍被认为是一个实验性功能。我们计划修复已知的问题,并在下一个里程碑发布一个稳定版本。如果你现在正在尝试使用它,需要注意以下几点:

  • 如果写入频率过高(即每秒写入许多指标),许多并行训练的远程跟踪将变慢

至于你的第二个问题,.log和.sst文件是rocksdb的内部文件。.log是一个预写日志,根据使用的选项进行刷新。一般来说,由于它由单个进程管理,不应该出现丢失.log文件的情况,但这可能是rocksdb端的一个bug。我们必须进一步调查这个问题以确定。

dluptydi

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

相关问题