W moim /etc/defaults/celeryd pliku konfiguracyjnym, mam ustawione:Seler, pracowników i AutoScaling
CELERYD_NODES="agent1 agent2 agent3 agent4 agent5 agent6 agent7 agent8"
CELERYD_OPTS="--autoscale=10,3 --concurrency=5"
Rozumiem, że demon ikra 8 pracowników seler, ale całkowicie nie jestem pewien co autoscale i concurrency robić razem. Sądziłem, że współbieżność jest sposobem na określenie maksymalnej liczby wątków, których pracownik może użyć, a autoskalowanie to sposób, w jaki pracownik może w razie potrzeby skalować i zmniejszać liczbę pracowników pracujących z dziećmi.
Zadania mają duży ładunek (około 20-50kB) i są podobne do 2-3 milionów takich zadań, ale każde zadanie trwa mniej niż sekundę. Widzę wzrost zużycia pamięci, ponieważ broker dystrybuuje zadania do każdego pracownika, co powoduje wielokrotne replikowanie ładunku.
Myślę, że problem tkwi w konfiguracji i że połączenie pracowników + współbieżność + autoskalowanie jest nadmierne i chciałbym lepiej zrozumieć, co robią te trzy opcje.
Dokumentacja do [autoskalowania] (http://celery.readthedocs.org/en/latest/userguide/workers.html#autoscaling) i [współbieżność] (http://celery.readthedocs.org/en/latest /userguide/workers.html#concurrency) jest całkiem jasne. Czego nie rozumiesz. W szczególności nie ma sensu precyzować obu naraz. I jaki dokładnie jest twój problem? Spike pamięci? Czy to rzeczywiście jest problem - czyli czy trafiasz na swap, czy wywołujesz OOM? – scytale
@scytale Widzę wywoływaną OOM. Wiele procesów zostaje po prostu zakończonych za pomocą 'Killed', kiedy rośnie. Wydaje mi się, że teraz jestem jasny na temat autoskalowania i współbieżności. Myślałem, że '--autoscale' doda więcej pracowników, ale jest to po prostu dynamiczne ustawienie dla określania współbieżności zamiast stałego ustawienia z' --concurrency'. Domyślam się, że moje jedyne zamieszanie wokół "dodaje więcej pracowników przy mniejszej współbieżności lub dodaj mniej pracowników o większej współbieżności". Nie wiem, jak ocenić ten kompromis. – Joseph
rozróżnijmy pracowników i procesy robocze. odrodzisz pracownika selera, a następnie spawnuje szereg procesów (w zależności od rzeczy takich jak -koncurrency i --autoscale). Nie ma sensu uruchamianie więcej niż jednego procesora, chyba że chcesz robić routing, słuchać różnych kolejek itp. Powiedziałbym, aby uruchomić jeden robot z domyślną liczbą procesów (tj. Pominąć --concurrency i --autoscale i będzie domyślnie tyle procesów, ile jest rdzeni). Następnie przetestuj swoją aplikację w celu ustalenia poziomu współbieżności, który odpowiada Twoim potrzebom. – scytale