Как на ровном месте сэкономить 1000+ ядер, или Куда на самом деле уходили 80% CPU
<img src="https://habrastorage.org/getpro/habr/upload_files/f92/681/7e0/f926817e01e2a4cc02c6a8a9f8b5ba5e.png" /><p>Всем привет, меня зовут Миша, и я бэкенд‑разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы <a href="https://habr.com/ru/companies/yandex/articles/921122/">анализировали наш PHP‑монолит</a> и <a href="https://habr.com/ru/companies/yandex/articles/972612/">вынесли из него процессинг заказов</a>, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания. </p><p>Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как‑то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит.</p><p>Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое‑то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут. </p><p>Немного спойлеров: <span class="habrahidden">дело оказалось далеко не только в PHP. </span></p> <a href="https://habr.com/ru/articles/1078050/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1078050#habracut">Читать далее</a>