Как избежать регулирования ЦП в контейнерной среде
_________________________________

В Uber все рабочие нагрузки с отслеживанием состояния выполняются на общей контейнерной платформе на большом количестве хостов. Рабочие нагрузки с отслеживанием состояния включают MySQL® , Apache Cassandra® , ElasticSearch® , Apache Kafka® , Apache HDFS ™ , Redis ™ , Docstore , Schemaless и т. д ., и во многих случаях эти рабочие нагрузки размещаются на одних и тех же физических хостах.

Имея 65 000 физических хостов, 2,4 миллиона ядер и 200 000 контейнеров, увеличение использования для снижения затрат является важной и постоянной задачей. До недавнего времени попытки были заблокированы из-за троттлинга ЦП, что указывает на то, что было выделено недостаточно ресурсов.

Оказалось, что проблема заключалась в том, как ядро ​​Linux распределяет время для запуска процессов. В этом посте мы опишем, как переключение с квот ЦП на наборы ЦП (также известное как закрепление ЦП) позволило нам обменять небольшое увеличение задержек P50 на значительное снижение задержек P99. Это, в свою очередь, позволило нам сократить выделение основных ресурсов для всего парка машин до 11 % из-за меньшей разницы в требованиях к ресурсам.

https://shly.link/PmF4E