Какова реальная загрузка процессора контейнера из команды docker stats

#docker #docker-compose #docker-swarm #timescaledb

Вопрос:

Я запускаю postgres timescaledb на своем узле docker swarm. Я установил лимит процессора на 4, а лимит памяти на 32G. Когда я проверяю docker stats , я вижу этот вывод:

 CONTAINER ID   NAME                                                                                     CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
c6ce29c7d1a4   pg-timescale.1.6c1hql1xui8ikrrcsuwbsoow5                                                 341.33%   20.45GiB / 32GiB      63.92%    6.84GB / 5.7GB    582GB / 172GB     133
 

Процессор% колеблется около 400%. Узел имеет 6 процессоров, а средняя нагрузка составляла 1-2 (средняя нагрузка за 1 минуту), поэтому, по моему мнению, с моим лимитом процессоров — 4 максимальная нагрузка должна колебаться около 6. Моя текущая нагрузка составляет 20 (средняя нагрузка за 1 минуту), а вывод top команды изнутри postgres показывает 50-60%.

Ограничение конфигурации моей службы:

 deploy:
  resources:
    limits:
      cpus: '4'
      memory: 32G
 

Я в замешательстве, все значения разные, так каково реальное использование процессора postgres и как его ограничить ? Моя нагрузка на сервер повышена до максимума, четный предел postgres установлен на 4. Внутри postgres я вижу из htop, что есть 6 ядер и 64G MEM, так что похоже, что у него есть все ресурсы хостов. Из статистики docker максимальный процессор составляет 400% — corelate с ограничением в 4 процессора.

Комментарии:

1. «средняя нагрузка составила 1-2» … «Моя текущая нагрузка составляет 20» 1-2 что и 20 что в соответствии с чем? Включите запуск команд и их вывод.

2. Извините, я уточняю вопрос. Средняя нагрузка на 1 м.

3. Пример операционной системы load average: 17,52, 14,80, 12,60

4. средняя загрузка не имеет никакого отношения к процессору. это подсчет живых процессов. и не имеет значения с точки зрения нагрузки.

Ответ №1:

Средняя загрузка из команд, как top в Linux, относится к числу процессов, запущенных или ожидающих запуска в среднем за определенный период времени. Ограничения ЦП, используемые docker, определяют количество циклов ЦП в течение некоторого периода времени, разрешенного для процессов внутри группы. На самом деле это не одно и то же, особенно когда вы учитываете такие вещи, как ожидание ввода-вывода. У вас может быть процесс, ожидающий чтения с диска, который хочет запуститься, но блокируется при этом вызове ввода-вывода, увеличивая ваши измерения нагрузки на хост, но не используя никаких циклов процессора.

При расчете объема ЦП, выделяемого для cgroup, вам не только нужно учитывать ввод-вывод и другие системные потребности процесса, но и учитывать теорию очередей, когда вы приближаетесь к насыщению ЦП. Чем ближе вы приблизитесь к 100% — ной загрузке процессора, тем длиннее, скорее всего, будет очередь процессов, готовых к запуску, что приведет к значительным скачкам в измерениях нагрузки.

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