Мы используем астропию для выполнения больших симуляций SKA, работающих в Dask на отдельных узлах или кластере. Мы используем как время, так и astroplan.Observer в наших расчетах. Некоторую долю времени мы видим ошибки в доступе к данным IERS. Например:
rascil/processing_components/visibility/base.py:275: in create_blockvisibility
570 from astroplan import Observer
571 /usr/local/lib/python3.7/site-packages/astroplan/__init__.py:32: in <module>
572 get_IERS_A_or_workaround()
573 /usr/local/lib/python3.7/site-packages/astroplan/utils.py:57: in get_IERS_A_or_workaround
574 if IERS_A_in_cache():
575 /usr/local/lib/python3.7/site-packages/astroplan/utils.py:78: in IERS_A_in_cache
576 with _open_shelve(urlmapfn, True) as url2hash:
577 /usr/local/lib/python3.7/site-packages/astroplan/utils.py:322: in _open_shelve
578 shelf = shelve.open(shelffn, protocol=2)
579 /usr/local/lib/python3.7/shelve.py:243: in open
580 return DbfilenameShelf(filename, flag, protocol, writeback)
581 /usr/local/lib/python3.7/shelve.py:227: in __init__
582 Shelf.__init__(self, dbm.open(filename, flag), protocol, writeback)
583 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
584 > return mod.open(file, flag, mode)
585 E _gdbm.error: [Errno 11] Resource temporarily unavailable
586 /usr/local/lib/python3.7/dbm/__init__.py:94: error
Наша интерпретация заключается в том, что это происходит из-за того, что несколько работников Dask пытаются получить доступ к одному и тому же файлу кэша. Это происходит всякий раз, когда используется несколько процессов на одном узле или процессы распространяются по кластеру, обращаясь к общей точке монтирования. Те же функции, выполняемые последовательно, не вызывают этой ошибки.
Для обходных путей мы попробовали следующее:
iers.conf.auto_max_age = None
iers.conf.remote_timeout = 100.0
data.conf.download_cache_lock_attempts = 10
Ничего из этого не помогло. Мы все еще видим те же ошибки GDBM. Можете ли вы предложить какие-либо предложения?
Спасибо.