# Profiling a Yandex Food PHP monolith to identify CPU usage and reduce allocated cores

DevFeed: [Profiling a Yandex Food PHP monolith to identify CPU usage and reduce allocated cores](<https://devfeed.tech/articles/1000-80-cpu-24892.md>)

Original publisher: [Read original article](<https://habr.com/ru/companies/yandex/articles/1078050/>)

Author: m03r (Яндекс)

Published: 2026-09-08T07:31:51Z

Content type: article

Language: ru

Sources: [Яндекс - Как мы делаем Яндекс / Статьи](<https://devfeed.tech/sources/source.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [eBPF](<https://devfeed.tech/topics/ebpf.md>), [Linux](<https://devfeed.tech/topics/linux.md>)

Tags: [cpu](<https://devfeed.tech/tags/cpu.md>), [ebpf](<https://devfeed.tech/tags/ebpf.md>), [haproxy](<https://devfeed.tech/tags/haproxy.md>), [linux](<https://devfeed.tech/tags/linux.md>), [perforator](<https://devfeed.tech/tags/perforator.md>), [php](<https://devfeed.tech/tags/php.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>)

## AI overview

A backend developer describes investigating unexpectedly high CPU usage in a legacy PHP monolith at Yandex Food. By profiling the application with Perforator and its PHP support, the investigation examined why CPU consumption was unusually high and how the allocated capacity could be reduced.

## Source excerpt

Всем привет, меня зовут Миша, и я бэкенд-разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы анализировали наш PHP-монолит и вынесли из него процессинг заказов, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания. Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как-то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит. Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое-то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут. Немного спойлеров: дело оказалось далеко не только в PHP. Читать далее