#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% — ной загрузке процессора, тем длиннее, скорее всего, будет очередь процессов, готовых к запуску, что приведет к значительным скачкам в измерениях нагрузки.
Правильная установка этих ограничений, скорее всего, потребует проб и ошибок, поскольку не все процессы одинаковы и не вся рабочая нагрузка на хосте одинакова. Задание пакетной обработки, которое запускается с нерегулярными интервалами и насыщает диски и сеть, окажет на хост совсем другое влияние, чем научные вычисления, которые сильно ограничены процессором и памятью.