python: совместное использование огромных словарей с использованием многопроцессорности

Если словари доступны только для чтения, вам не нужны прокси-объекты в большинстве операционных систем.

Просто загрузите словари перед запуском воркеров и поместите их в место, где они будут доступны; самое простое место - глобально к модулю. Они будут доступны для чтения рабочими.

from multiprocessing import Pool

buf = ""

def f(x):
    buf.find("x")
    return 0

if __name__ == '__main__':
    buf = "a" * 1024 * 1024 * 1024
    pool = Pool(processes=1)
    result = pool.apply_async(f, [10])
    print result.get(timeout=5)

При этом используется только 1 ГБ памяти вместе, а не 1 ГБ для каждого процесса, потому что любая современная ОС будет создавать тень копирования при записи данных, созданных до вилки. Просто помните, что изменения данных не будут видны другим рабочим, и память, конечно же, будет выделена для любых данных, которые вы изменяете.

Он будет использовать некоторую память: страница каждого объекта, содержащая счетчик ссылок, будет изменена, поэтому она будет выделена. Будет ли это иметь значение, зависит от данных.

Это будет работать в любой ОС, которая реализует обычное разветвление. Это не будет работать в Windows; его (урезанная) модель процесса требует перезапуска всего процесса для каждого рабочего, поэтому она не очень хороша для обмена данными.

Почему бы вам не попробовать это с базой данных? Базы данных не ограничены адресуемой / физической памятью и безопасны для многопоточного / процессного использования.

В интересах экономии времени и отсутствия необходимости отлаживать проблемы на уровне системы, возможно, вы могли бы разделить свой 5,8-миллионный словарь записей на три набора по ~ 2 миллиона в каждом и запустить задание 3 раза.

Я думаю, что проблема, с которой вы столкнулись, заключалась в том, что размер таблицы или хеш-таблицы изменялся по мере роста. Изначально у dict есть заданное количество доступных сегментов. Я не уверен насчет Python, но я знаю, что Perl начинается с 8, а затем, когда ведра заполнены, хэш воссоздается еще на 8 (например, 8, 16, 32, ...).

Ковш - это место посадки для алгоритма хеширования. 8 слотов не означают 8 записей, это 8 ячеек памяти. Когда добавляется новый элемент, для этого ключа создается хэш, который затем сохраняется в этом сегменте.

Вот где в игру вступают столкновения. Чем больше элементов находится в корзине, тем медленнее будет работать функция, поскольку элементы добавляются последовательно из-за динамического изменения размера слота.

Одна из проблем, которая может возникнуть, заключается в том, что ваши ключи очень похожи и дают одинаковый результат хеширования, то есть большинство ключей находятся в одном слоте. Предварительное выделение хэш-сегментов поможет устранить это и фактически сократит время обработки и управление ключами, а также избавит от необходимости выполнять всю эту подкачку.

Однако я думаю, что вы по-прежнему ограничены объемом свободной непрерывной памяти, и в конечном итоге вам нужно будет перейти к решению для базы данных.

примечание: я все еще новичок в Python, я знаю, что в Perl вы можете увидеть статистику хэша, выполнив print% HASHNAME, он покажет ваше распределение использования корзины. Помогает определить количество столкновений - на случай, если вам нужно заранее выделить сегменты. Можно ли это сделать и на Python?

Богатый