На счет NUMA можно подробнее, это архитектура проца, как может быть она включена?

Ага спасибо, изучаю

https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1 вот исходная статья про баг

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

Или норм ядро без бага, чет не могу понять по переписке:) попробуй сделать эксперимент что в гисте был :)

Да у моего EPYC AMD два сокета, вполне допускаю что может быть контейнер запущен так что лимитов 8 и 4 с одного сокета 4 с другого, если вы про это.

https://github.com/golang/go/issues/33803 вроде пока ещё тупое :)

лимиты в контейнерах (не пинниг) ограничивают потребление по времени, а не по конкретному процу
допустим одно ядро 1000Mhz (типа CPU limut = 1). допустм 80 ядер итого 80 времени на сервер. кружечка 2
т.е. процее поработает 0.025  на каждом из ядер и это при справедливом шедуленге и отсутствии накладных расходов (а это всегда не так).
+ если лимиты и реквесты разные будет еще веселее.

При большом количетве процессов там sy будет афигеть какой большой.
кстати есть возможность показть из top строку с us sy  ni и т.д.

Для простого понимания ещё, горутины исполняются в thread pool размером gomaxproc, поэтому это важно реально, если есть лимиты небольшие/много ядер/много горутин

> если лимиты и реквесты разные будет еще веселее
Ну реквесты это же ваще cpu.shares, то есть вес. Поэтому приравнивание реквестов и лимитов от тротлинга не спасет

https://miro.medium.com/max/1478/0*hp7ANO_Z6pHsaVBD.png https://miro.medium.com/max/1478/0*2FNdeW0a0VfRJKEt.png

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

Вот хорошие две картинки

Да есть

Подтверждаю, хотя разработчик меня убеждал в обратном, мол его приложение лучше будет работь если limits=requests. Проверили и я ему показал что от тротлинга оно не спасло.

на той же ноде с 80 ядрами, допустим если она пустая и там только наш под. Мы дали реквестов  и лимитов 1000m. То есть 1024 cpu shares  и cfs_quota_us / cfs_period_us = 1.

Допустим там еще kubelet и 20 системных процессов также имеют cpu shares по 1024 (умолчание)
В итоге все эти 80 ядер будут разделены между  20 системными процессами и нашим подиком на равные части. То есть каждому процессу дадут условно  ~ 3 ядра (80 / ~20) в попугаях и нашему поду в том числе.  При этом мы ограничили  лимит на 1000m (cfs_quota_us / cfs_period_us = 1). В итоге ядро будет тротлить наш подик только в путь, поскольку по cpu.shares он может кушать 3 ядра, а вот квота ему этого не будет давать делать

Вообще лимиты это скользкая тема, надо много тестить и понимать как это работает, tail latency все дела

если бы они еще и работали по CPU особенно. Просто если форки наплодятся то тут пиши пропало

Я полностью согласен. У меня это еще более наглядно обычно, еще и сетевой трафик 1-10 гигабати и та еще и стевухи отжирают cpu через IRQ