Poniższy kod nie wydają się biec równolegle, a nie jestem pewien dokładnie dlaczego:Can not Get wieloprocesorowe do uruchomienia procesów jednocześnie
def run_normalizers(config, debug, num_threads, name=None):
def _run():
print('Started process for normalizer')
sqla_engine = init_sqla_from_config(config)
image_vfs = create_s3vfs_from_config(config, config.AWS_S3_IMAGE_BUCKET)
storage_vfs = create_s3vfs_from_config(config, config.AWS_S3_STORAGE_BUCKET)
pp = PipedPiper(config, image_vfs, storage_vfs, debug=debug)
if name:
pp.run_pipeline_normalizers(name)
else:
pp.run_all_normalizers()
print('Normalizer process complete')
threads = []
for i in range(num_threads):
threads.append(multiprocessing.Process(target=_run))
[t.start() for t in threads]
[t.join() for t in threads]
run_normalizers(...)
Zmienna config
jest tylko słownik zdefiniowane z zewnątrz _run()
funkcja. Wydaje się, że wszystkie procesy są tworzone - ale nie jest to szybsze niż w przypadku pojedynczego procesu. Zasadniczo, co się dzieje w funkcjach run_**_normalizers()
czyta się z tabeli kolejki w bazie danych (SQLAlchemy), następnie wykonuje kilka żądań HTTP, a następnie uruchamia "potok" normalizatorów w celu modyfikacji danych, a następnie zapisania ich z powrotem w bazie danych. Pochodzę z obszaru JVM, gdzie wątki są "ciężkie" i często używane do równoległości - jestem trochę zdezorientowany tym, ponieważ uważałem, że moduł wieloprocesowy powinien ominąć ograniczenia GIL Pythona.
Moduł przetwarzania wieloprocesorowego wykorzystuje procesy, a nie wątki. W związku z tym GIL nie ma na nią wpływu. –
Przetestowałem Twój kod i podstawowa technika jest w porządku. Nie jestem pewien co do współużytkowanego 'config', jeśli słownik' config' jest często używany, co teoretycznie może spowalniać działanie. Możliwe, że procesor nie jest tutaj twoim wąskim gardłem. –
Uruchomiłem go tylko na mojej stacji roboczej, 8 rdzeniach z 16 GB pamięci RAM. Przy 1 lub 1, 8 lub 16 procesach nic się nie zmienia - a zasoby systemowe są w porządku. –