Repository navigation
Description
Почему один 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? Либо, если хочешь, сначала отдельно продиагностирую именно контейнер панели — скажи, что предпочитаешь.
Activity
konard commentedon Jul 7, 2026
🚨 Solution Draft Failed
The automated solution draft encountered an error:
What happened
origin/maininkonard/ProverCoderAI-docker-gitagainstupstream/maininProverCoderAI/docker-git.konard; the task requester isskulidropek.origin/mainhas 1 commit(s) unique toorigin/main; replacing it withupstream/mainwould remove them from the fork default branch history.Commits that would be lost
640892f8ba17 github-actions[bot] chore(release): version packagesWhat you can do
gh repo delete konard/ProverCoderAI-docker-git --yes solve https://github.com/ProverCoderAI/docker-git/issues/447 # Manual branch repair after preserving any fork-only commits: git fetch upstream git reset --hard upstream/main git push --force-with-lease origin main🤖 Models used:
fable(claude-fable-5)claude-fable-5)Click to expand failure log (44KB)
Now working session is ended, feel free to review and add any feedback on the solution draft.