Почему один grep так забивает процессор
Дело в трёх вещах, которые сложились вместе:
- ugrep по умолчанию многопоточный. Он смотрит в /proc/cpuinfo, видит 16 ядер хоста и поднимает ~16 рабочих потоков — независимо от того, что контейнеру разрешено меньше.
Обычный grep был бы однопоточным; rtk переписал его в параллельный ugrep, и вместо 1 ядра он захотел 16.
- Контейнер dg-utpmarket-issue-1 ограничен 4.8 ядрами (cgroup cpu.max = 480000/100000). 16 голодных потоков дерутся за 4.8 разрешённых ядра → ядро Linux душит (throttle)
контейнер в 96% интервалов. Все 16 потоков постоянно висят в состоянии «готов работать, но не пущен».
- Эти «задушенные, но готовые» потоки раздувают метрики. Load average считает все runnable-потоки → отсюда load ~13. CPU pressure считает время, что задачи стоят в очереди
за CPU → отсюда 58%. Плюс поиск идёт от корня / по гигантскому дереву (node_modules, кэши, монтирования) — он физически не может закончиться, крутится 4 часа.
Важный нюанс
Реально хост съедено ~6.5 ядра из 16 (utpmarket ~4.8 + browser ~1 + мелочь). То есть железо не упёрто в потолок — но цифры load/pressure выглядят страшно именно из-за
троттлинга: куча потоков молотит вхолостую в очереди. При этом само окружение utpmarket полностью встало (агент внутри задушен), а частые переключения троттлинга (142 тыс.
событий) добавляют накладных расходов планировщику на весь хост.
Что это значит для панели
Если панель отвечает медленно — это либо тот же эффект (её бэкенд docker-git-api стоит в общей очереди / дёргает подтормаживающий docker-демон), либо у панели есть отдельная
причина. Честно: доказанный факт — это зависший ugrep. Убьём его (освободит 4.8 ядра и уберёт троттлинг-шум) — и сразу станет видно, ушёл ли лаг панели полностью или
осталась вторая причина, которую тогда добью отдельно.
Убить зависший ugrep? Либо, если хочешь, сначала отдельно продиагностирую именно контейнер панели — скажи, что предпочитаешь.
Почему один grep так забивает процессор
Дело в трёх вещах, которые сложились вместе:
Обычный grep был бы однопоточным; rtk переписал его в параллельный ugrep, и вместо 1 ядра он захотел 16.
контейнер в 96% интервалов. Все 16 потоков постоянно висят в состоянии «готов работать, но не пущен».
за CPU → отсюда 58%. Плюс поиск идёт от корня / по гигантскому дереву (node_modules, кэши, монтирования) — он физически не может закончиться, крутится 4 часа.
Важный нюанс
Реально хост съедено ~6.5 ядра из 16 (utpmarket ~4.8 + browser ~1 + мелочь). То есть железо не упёрто в потолок — но цифры load/pressure выглядят страшно именно из-за
троттлинга: куча потоков молотит вхолостую в очереди. При этом само окружение utpmarket полностью встало (агент внутри задушен), а частые переключения троттлинга (142 тыс.
событий) добавляют накладных расходов планировщику на весь хост.
Что это значит для панели
Если панель отвечает медленно — это либо тот же эффект (её бэкенд docker-git-api стоит в общей очереди / дёргает подтормаживающий docker-демон), либо у панели есть отдельная
причина. Честно: доказанный факт — это зависший ugrep. Убьём его (освободит 4.8 ядра и уберёт троттлинг-шум) — и сразу станет видно, ушёл ли лаг панели полностью или
осталась вторая причина, которую тогда добью отдельно.
Убить зависший ugrep? Либо, если хочешь, сначала отдельно продиагностирую именно контейнер панели — скажи, что предпочитаешь.