Python 并行、信号量泄漏警告和无追溯的中止
Python parallel, semaphore leak warning and abort without traceback
我正在 运行 使用 joblib.Parallel
在 python 中进行并行网格搜索。我的脚本相对简单:
# Imports for data and classes...
Parallel(n_jobs=n_jobs)(
delayed(biz_model)(
...
)
for ml_model_params in grid
for past_horizon in past_horizons
)
当我在我的本地机器上 运行 它时,它似乎 运行 很好,尽管出于内存原因我只能在小数据集上测试它。然而,当我尝试在远程 Oracle Linux 服务器上 运行 它时,它开始一些 运行s 并在一段时间后输出:
/u01/.../resources/python/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
Aborted!
我试图在本地重现它,并通过一些小实验成功了 运行。未并行化的脚本也 运行s 和作业数量(无论是低还是高)都不能阻止错误的发生。
所以我的问题是,如果没有追溯,有没有办法让 joblib
或 Parallel
更冗长?在没有回溯的情况下,我完全不知道去哪里查看可能的失败原因。显然,如果仅凭此可以推断出某些可能的中止原因(但我未能理解),我非常感谢通知。
提前致谢。
使用记录器,捕获异常,记录它,刷新日志并再次引发它,通常可以解决问题
# Imports for data and classes...
# Creates logger
Parallel(n_jobs=n_jobs)(
try:
delayed(biz_model)(
...
)
for ml_model_params in grid
for past_horizon in past_horizons
except BaseException as e:
logger.exception(e)
# you can use a for here if you had more than a handler
logger.handlers[0].flush()
raise e
)
我正在 运行 使用 joblib.Parallel
在 python 中进行并行网格搜索。我的脚本相对简单:
# Imports for data and classes...
Parallel(n_jobs=n_jobs)(
delayed(biz_model)(
...
)
for ml_model_params in grid
for past_horizon in past_horizons
)
当我在我的本地机器上 运行 它时,它似乎 运行 很好,尽管出于内存原因我只能在小数据集上测试它。然而,当我尝试在远程 Oracle Linux 服务器上 运行 它时,它开始一些 运行s 并在一段时间后输出:
/u01/.../resources/python/lib/python3.6/multiprocessing/semaphore_tracker.py:143: UserWarning: semaphore_tracker: There appear to be 1 leaked semaphores to clean up at shutdown
len(cache))
Aborted!
我试图在本地重现它,并通过一些小实验成功了 运行。未并行化的脚本也 运行s 和作业数量(无论是低还是高)都不能阻止错误的发生。
所以我的问题是,如果没有追溯,有没有办法让 joblib
或 Parallel
更冗长?在没有回溯的情况下,我完全不知道去哪里查看可能的失败原因。显然,如果仅凭此可以推断出某些可能的中止原因(但我未能理解),我非常感谢通知。
提前致谢。
使用记录器,捕获异常,记录它,刷新日志并再次引发它,通常可以解决问题
# Imports for data and classes...
# Creates logger
Parallel(n_jobs=n_jobs)(
try:
delayed(biz_model)(
...
)
for ml_model_params in grid
for past_horizon in past_horizons
except BaseException as e:
logger.exception(e)
# you can use a for here if you had more than a handler
logger.handlers[0].flush()
raise e
)