Child pages
  • Подбор кол-ва процессов и тредов
Skip to end of metadata
Go to start of metadata

Как сделать так, чтобы NOC хорошо себя чувствовал и успевал выполнять все задания вовремя.

Здесь и далее я буду называть Instances процессами, а Threads тредами, потому что оно так и есть. Треды плодятся процессом, а процесс завязан физически на ядро машины, так устроен python.
Но не нужно думать, что просто возьмём N процессов discovery, где N – кол-во ядер.

Введу понятие активаторо-треды и дискавери-треды, это общее кол-во тредо, созданное всеми процессами активатора или дискавери соответственно.
Например: 2 активатора по 45 тредов каждый это всего 90 активаторо-тредов.

Step-by-step guide

  1. Настраиваем мониторинг задач discovery согласно данной статье: График задач дискавери
  2. Запускаем нок, если не запущен, дожидаемся минут 10, чтобы наступил установившийся режим.
  3. Смотрим на график:
  4. Очевидно, что в среднем 100-200 задач остаются необработанными и надо с этим что-то делать. Если у вас там 0 и в running tasks куча задач, то всё прекрасно.
  5. Текущая конфигурация системы следующая:
    Кол-во активаторов: 4 процесса по 50 тредов.
    Кол-ва дискавери:     3 процесса по 200 тредов.
    Загрузка согласно htop:

 

Как определить, сколько чего нужно и зачем? Я не уверен, насколько это подтверждается архитектурно, но разработчики партизаны те ещё.
Вот мои изыскания:

  1. Выбираем 1 процесс активатора, 30 тредов, к примеру.
  2. Выбираем 1 процесс дискавери и 50 тредов, цифра тоже с неба.
  3. Дальше , после минут 10-15 работы в установившемся режиме(это важно) возможны варианты:
    1. нам не хватает активаторо-тредов: Мы увидим в логах var/log/discovery-default-06.log:2016-09-13 17:35:04,587 [scheduler.discovery] All workers are busy. Sending 12 jobs to burst Решение: увеличиваем кол-во активаторо-тредов, например за счёт тредов на одном процессе, пусть теперь их будет 100, т.е. 1 активатор и 100 тредов. Если после установившегося режима burst записи остались, добавьте процесс активатора, не уменьшая кол-во тредов.
    2. Нам не хватает дискавери-тредов: Мы наблюдаем кучу нерешённых задач в late_tasks, большой LA на машине тоже возможен. Добавляем дискавери-тредов, наблюдаем загрузку машины в top/htop, следим, чтобы утилизация отдельных процессов дискавери не была более 50-70% от ядра. Это даст нам запас на холодный старт
    3. нам не хватает коннектов к postgres: Всё падает, процесс sae в логах пишет, что эл-во кончилось и т.д. Кол-во коннектов должно быть больше, чем кол-во дискавери-тредов, т.к. каждый тред открывает свой коннект. например, на мои 3*200 дискавери тредов открыто 616 коннектов.(Система тоже туда ходит, поэтому делайте запас! Кто-то советует делать сразу 1000.)
      1. как мониторить: Создайте график в графане. Всё аналогично вышеупомянутой статье.
        ,

 

Вот так выглядит установившийся режим:

 

 

1 Comment

  1. Unknown User (e_zombie)

    Уменьшить нагрузку на CPU можно изменив этот параметр в ноль или удалить совсем.

    supervisord.conf:stderr_capture_maxbytes = 1MB

     

    E_zombie, [25.10.16 12:38]

    а почему супервизор может жрать проц?

     

    Dmitry Volodin, [25.10.16 12:40]

    логи пишет

     

    Dmitry Volodin, [25.10.16 12:40]

    сами сервисы на stdout гонят их

     

    Dmitry Volodin, [25.10.16 12:40]

    он подбирает

     

    Dmitry Volodin, [25.10.16 12:41]

    попробуй отключить ему capture mode

     

    Dmitry Volodin, [25.10.16 12:41]

    если включен

     

    Dmitry Volodin, [25.10.16 12:41]

    чтобы не пытался их анализировать