Forwarded from Сергей Озеранский
🧠 Как 3 вечера анализа и оптимизаций дали минус 1 CPU и +40% к скорости ответов API
👀 Всё началось с того, что я случайно (ну как случайно, проблема была всегда, просто я первый задался вопросом - "почему?") заметил, что один Python-сервис на staging потребляет до 2.5 CPU.
Для сравнения — весь namespace потребляет около 6 CPU. То есть один сервис ест почти половину ресурсов. И это при том, что это не какой-то нагруженные сервис, это синхронный API-сервис, да еще и без нагрузки, это же staging.
Стало интересно — а что там внутри вообще так жрёт?
📦 Запустил профайлинг CPU через Pyroscope и… понеслось.
UI у Pyroscope меня не устроил — флеймграфы красивые, но неудобные для глубокого анализа.
📥 Поэтому я выгрузил дамп как
Так мне удобнее, быстрее и информативнее.
📊 Профилирование показало несколько важных узких мест:
🧱 Проблема №1: конвертация данных из MySQL
Самое "жирное" место —
Это код, который конвертирует строки из БД в Python-объекты на каждый запрос.
Наиболее затратные конвертации:
-
-
-
-
-
✅ Решение:
📌 Использовал C extension у mysql-connector-python
Официальная документация: https://dev.mysql.com/doc/connector-python/en/connector-python-cext.html
📉 Результат:
- Минус 1 CPU
- До +40% ускорение некоторых endpoint’ов
🧠 Проблема №2: неэффективный Python-код
Пример: функция
- делает кучу проверок в логике
- использует неэффективные структуры данных, например, list для поиска вместо
- обрабатывает сразу множество возможных вариантов логики, в зависимости от входных данных
✅ Решение:
📌 Переписал участок без изменения бизнес-логики:
- заменил структуры данных
- добавил ранние выходы
- убрал дублирующиеся проверки
📌 Cognitive complexity снизилась, временная сложность — тоже. Производительность выросла.
⚠️ Проблема №3: код, который не нужен, но работает
Профайлинг показал, что куча ресурсов уходит на код, который вообще не должен уже как год использоваться. Но код активно выполняется. WTF!?
🤷♂️ Функции вызываются, результат — пустой, но код исполняется. Причём часто и тяжело.
✅ Решение:
📌 Удалил мёртвый код, обновил импорты, подчистил зависимости.
📌 Поднял вопрос о полной деактивации этого кода и мы таки это сделали — ресурсы можно использовать лучше.
🐘 Проблема №4: Импорты. Много. Дорого.
Во время анализа я наткнулся на ещё одну тихую, но дорогую проблему — огромные ресурсы уходят на фазу импорта модулей в Python.
Конкретно — на
📌 Почему это важно?
- Импорты выполняются на каждый старт сервиса.
- Чем жирнее и зависимее ваши модули, тем дольше и тяжелее проходит импорт.
- Это не всегда очевидно, но можно видеть в профайлинге:
📊 У нас в сервисе модулей реально много.
Многое из них – просто "свалены в кучу", где-то грузятся тяжёлые зависимости. Да и сложная структура проекта вынуждает иметь большое количество импортов.
И, как итог, CPU тратится на то, что можно было бы стремиться избежать.
✅ Что с этим делать:
- Разделять модули по функциональности.
- Отложенные импорты (lazy import) – практика может применяться (но есть нюансы), если модуль нужен только в конкретной функции.
- Минимизировать зависимости и импорт только того, что действительно нужно.
- Следить за импортами в
Следующий шаг: memory профайлинг. Pyroscope в нашей инфрастуктуре такое не умеет и нужно приседать, но надеюсь дойдут руки и до RAM.
👀 Всё началось с того, что я случайно (ну как случайно, проблема была всегда, просто я первый задался вопросом - "почему?") заметил, что один Python-сервис на staging потребляет до 2.5 CPU.
Для сравнения — весь namespace потребляет около 6 CPU. То есть один сервис ест почти половину ресурсов. И это при том, что это не какой-то нагруженные сервис, это синхронный API-сервис, да еще и без нагрузки, это же staging.
Стало интересно — а что там внутри вообще так жрёт?
📦 Запустил профайлинг CPU через Pyroscope и… понеслось.
UI у Pyroscope меня не устроил — флеймграфы красивые, но неудобные для глубокого анализа.
📥 Поэтому я выгрузил дамп как
pprof файл и открыл его через go tool pprof.Так мне удобнее, быстрее и информативнее.
📊 Профилирование показало несколько важных узких мест:
🧱 Проблема №1: конвертация данных из MySQL
Самое "жирное" место —
conversion.py → MySQLConverter.row_to_python.Это код, который конвертирует строки из БД в Python-объекты на каждый запрос.
Наиболее затратные конвертации:
-
_DECIMAL_to_python-
_INT_to_python-
_JSON_to_python-
_DATETIME_to_python-
_STRING_to_python✅ Решение:
📌 Использовал C extension у mysql-connector-python
Официальная документация: https://dev.mysql.com/doc/connector-python/en/connector-python-cext.html
📉 Результат:
- Минус 1 CPU
- До +40% ускорение некоторых endpoint’ов
🧠 Проблема №2: неэффективный Python-код
Пример: функция
change_type, которая:- делает кучу проверок в логике
- использует неэффективные структуры данных, например, list для поиска вместо
set / dict- обрабатывает сразу множество возможных вариантов логики, в зависимости от входных данных
✅ Решение:
📌 Переписал участок без изменения бизнес-логики:
- заменил структуры данных
- добавил ранние выходы
- убрал дублирующиеся проверки
📌 Cognitive complexity снизилась, временная сложность — тоже. Производительность выросла.
⚠️ Проблема №3: код, который не нужен, но работает
Профайлинг показал, что куча ресурсов уходит на код, который вообще не должен уже как год использоваться. Но код активно выполняется. WTF!?
🤷♂️ Функции вызываются, результат — пустой, но код исполняется. Причём часто и тяжело.
✅ Решение:
📌 Удалил мёртвый код, обновил импорты, подчистил зависимости.
📌 Поднял вопрос о полной деактивации этого кода и мы таки это сделали — ресурсы можно использовать лучше.
🐘 Проблема №4: Импорты. Много. Дорого.
Во время анализа я наткнулся на ещё одну тихую, но дорогую проблему — огромные ресурсы уходят на фазу импорта модулей в Python.
Конкретно — на
_find_and_load, часть механизма импорта, который занимается поиском, загрузкой и инициализацией модулей.📌 Почему это важно?
- Импорты выполняются на каждый старт сервиса.
- Чем жирнее и зависимее ваши модули, тем дольше и тяжелее проходит импорт.
- Это не всегда очевидно, но можно видеть в профайлинге:
_find_and_load, _find_and_load_unlocked, _load_unlocked – вот это всё.📊 У нас в сервисе модулей реально много.
Многое из них – просто "свалены в кучу", где-то грузятся тяжёлые зависимости. Да и сложная структура проекта вынуждает иметь большое количество импортов.
И, как итог, CPU тратится на то, что можно было бы стремиться избежать.
✅ Что с этим делать:
- Разделять модули по функциональности.
- Отложенные импорты (lazy import) – практика может применяться (но есть нюансы), если модуль нужен только в конкретной функции.
- Минимизировать зависимости и импорт только того, что действительно нужно.
- Следить за импортами в
__init__.py — именно они могут тянуть за собой пол кодовой базы.Следующий шаг: memory профайлинг. Pyroscope в нашей инфрастуктуре такое не умеет и нужно приседать, но надеюсь дойдут руки и до RAM.
👍36🤡7❤1👎1
Forwarded from Об ЭП и УЦ
Уязвимость Яндекс Браузера
25 марта 2025 года Google выпустила обновление, исправляющее уязвимость нулевого дня в браузере Google Chrome. Эксплойт, кстати, был обнаружен Лабораторией Касперского.
Спустя всего 2 дня выходит обновление Chromium ГОСТ👍 .
А как там самый популярный браузер из реестра отечественного ПО? А там всё печально. Для актуальной версии Яндекс Браузера соответствует двухмесячная версия Chromium 132.0.6834.955.
Не тот браузер добавили в реестр отечественного ПО.
25 марта 2025 года Google выпустила обновление, исправляющее уязвимость нулевого дня в браузере Google Chrome. Эксплойт, кстати, был обнаружен Лабораторией Касперского.
Спустя всего 2 дня выходит обновление Chromium ГОСТ
А как там самый популярный браузер из реестра отечественного ПО? А там всё печально. Для актуальной версии Яндекс Браузера соответствует двухмесячная версия Chromium 132.0.6834.955.
Не тот браузер добавили в реестр отечественного ПО.
Please open Telegram to view this post
VIEW IN TELEGRAM
/
Эксплойты нулевого дня и атаки нулевого дня
Что такое нулевой день и что такое уязвимости, эксплойты и атаки нулевого дня? В этой статье рассказывается о нулевом дне и об обнаружении и предотвращении атак нулевого дня.
😁41👍6🤡6🤷♂1🫡1
Forwarded from I’m CTO, bitch
Помните, в прошлом году делали софт для умного дома Дилдок.Лайф. Там у них мега-навороченные умные унитазы с голосовым ассистентом. Мы их предупреждали, что такое случится, но они не слушали и требовали делать всё по их ТЗ.
И вот итог:
1. Дата-центр лежит уже 3 часа.
2. Их умные унитазы из-за отсутствия соединения отказываются смывать. Ручной кнопки смыва в них не предусмотрено, всё только через голосового помощника или с телефона управляется.
3. Вся их умная бытовая техника тоже не работает или заглючила. Даже чайники не работают. А роботы-пылесосы активировали режим «skynet».
4. Техдир из Лайфа просит нас срочно что-то сделать, любые деньги предлагает.
Я ему посоветовал смывать в унитазе пока из ведра. Но у него дома умные краны, и они тоже не работают.
#стояделали
И вот итог:
1. Дата-центр лежит уже 3 часа.
2. Их умные унитазы из-за отсутствия соединения отказываются смывать. Ручной кнопки смыва в них не предусмотрено, всё только через голосового помощника или с телефона управляется.
3. Вся их умная бытовая техника тоже не работает или заглючила. Даже чайники не работают. А роботы-пылесосы активировали режим «skynet».
4. Техдир из Лайфа просит нас срочно что-то сделать, любые деньги предлагает.
Я ему посоветовал смывать в унитазе пока из ведра. Но у него дома умные краны, и они тоже не работают.
#стояделали
🤣70✍8🔥5🤡4👍2🥱1
I’m CTO, bitch
Помните, в прошлом году делали софт для умного дома Дилдок.Лайф. Там у них мега-навороченные умные унитазы с голосовым ассистентом. Мы их предупреждали, что такое случится, но они не слушали и требовали делать всё по их ТЗ. И вот итог: 1. Дата-центр лежит…
И этот пост понятно к чему. Сегодня 12 часов валялась обоссавшись и обосравшись зона ru-central1-b в Яндекс.Облаке и вроде как сейчас приходит в более или менее живое состояние. Всем кто в ночи будет чинить свои сервисы мои соболезнования и лучи поддержки.
Но проблема в том, что современные "хипсторы" решили почему-то что облака (не только AWS, GCP и т.д., а в более широком смысле) круто и надёжно, поэтому всё теперь привязывается и создаётся в них. Всё конечно же ради вашего удобства (нет)
И если пост выше это типа юмор (тоже нет), то вот почитайте реальную историю о том как человек не может воспользоваться нормально посудомоечной машиной, потому что ей нужен WiFi и приложение
Не буду я подключать посудомойку к вашему дурацкому облаку
https://habr.com/ru/companies/ruvds/articles/894602/
Оригинал
I won't connect my dishwasher to your stupid cloud
https://www.jeffgeerling.com/blog/2025/i-wont-connect-my-dishwasher-your-stupid-cloud
Если что, то Jeff Geerling достаточно известный в узких кругах человек
https://xn--r1a.website/tech_b0lt_Genona/3810
https://xn--r1a.website/tech_b0lt_Genona/3814
В целом, наблюдать за всем этим печально, потому что люди ради своего как бы удобства, перестают владеть не только купленным софтом (в самом широком смысле), но теперь уже и железом. Более того, радостно продолжают голосовать за это рублём.
Но проблема в том, что современные "хипсторы" решили почему-то что облака (не только AWS, GCP и т.д., а в более широком смысле) круто и надёжно, поэтому всё теперь привязывается и создаётся в них. Всё конечно же ради вашего удобства (нет)
И если пост выше это типа юмор (тоже нет), то вот почитайте реальную историю о том как человек не может воспользоваться нормально посудомоечной машиной, потому что ей нужен WiFi и приложение
я решил запустить цикл ополаскивания, но обнаружил, что он, а также другие функции, например, отложенный запуск и экорежим, требуют установки приложения.
Более того, для использования приложения нужно привязать посудомойку к Wi-Fi, настроить облачный аккаунт для какой-то системы под названием Home Connect, и только тогда вы сможете пользоваться всеми функциями машины.
. . .
Приложение? Я бы мог понять наличие удобных функций для тех, кому они нужны. Как в моём новом холодильнике (который я решил не подключать к WiFI): у него есть приложение, позволяющее мониторить температуру внутри или проще искать коды ошибок. Если бы мне нужны были эти дополнительные возможности, которых не было в моём старом холодильнике, то их можно было бы получить.
Но обязательное требование приложения для доступа к функциям, которыми раньше можно было управлять кнопками на самой посудомойке, или по-прежнему можно, если заплатить на 400 долларов больше за «крутую» модель 800? Это печально.
. . .
Что можем сделать мы?
Не думаю, что мы должны прощать подобное производителям.
Во-первых, это позволяет дизайнерам устройств лениться.
Во-вторых, с моей стороны это может показаться какой-то теорией заговора, но мне кажется, это часть запланированного устаревания. Как и в случае с машиной GE, в которой многие детали спроектированы так, чтобы заржаветь спустя пять или десять лет.
Если у вас есть облачное приложение, то для него должен работать облачный сервис. А его поддержка стоит денег.
Абонентской платы пока нет, что означает один из двух вариантов:
Производители уже могут продавать кому-то наши данные.
Рано или поздно они или закроют сервис, потому что это источник затрат (поэтому цикл ополаскивания и экорежим таких посудомоек пропадут, как по мановению волшебной палочки) или они перейдут на модель с подпиской.
В-третьих, это дыра в безопасности вашей локальной сети.
Не буду я подключать посудомойку к вашему дурацкому облаку
https://habr.com/ru/companies/ruvds/articles/894602/
Оригинал
I won't connect my dishwasher to your stupid cloud
https://www.jeffgeerling.com/blog/2025/i-wont-connect-my-dishwasher-your-stupid-cloud
Если что, то Jeff Geerling достаточно известный в узких кругах человек
https://xn--r1a.website/tech_b0lt_Genona/3810
https://xn--r1a.website/tech_b0lt_Genona/3814
В целом, наблюдать за всем этим печально, потому что люди ради своего как бы удобства, перестают владеть не только купленным софтом (в самом широком смысле), но теперь уже и железом. Более того, радостно продолжают голосовать за это рублём.
👍37💯12❤5🤡2
Технологический Болт Генона
И этот пост понятно к чему. Сегодня 12 часов валялась обоссавшись и обосравшись зона ru-central1-b в Яндекс.Облаке и вроде как сейчас приходит в более или менее живое состояние. Всем кто в ночи будет чинить свои сервисы мои соболезнования и лучи поддержки.…
Это ебануться
А есть кто на канале из админов https://xn--r1a.website/yandexcloud_chat? Можно пожалуйста бан снять с
Я в вашем официальном чате дал человеку ссылку на ваш же официальный канал с алертами (https://xn--r1a.website/yandexcloudalerts) и меня забанил ваш же бот.
UPD: Всем спасибо, из бана вытащили.
А есть кто на канале из админов https://xn--r1a.website/yandexcloud_chat? Можно пожалуйста бан снять с
@rusdacent?Я в вашем официальном чате дал человеку ссылку на ваш же официальный канал с алертами (https://xn--r1a.website/yandexcloudalerts) и меня забанил ваш же бот.
UPD: Всем спасибо, из бана вытащили.
🌚46😁43🤡15🆒4🤣3🤷♂1❤🔥1👏1🙈1💅1
Технологический Болт Генона
И этот пост понятно к чему. Сегодня 12 часов валялась обоссавшись и обосравшись зона ru-central1-b в Яндекс.Облаке и вроде как сейчас приходит в более или менее живое состояние. Всем кто в ночи будет чинить свои сервисы мои соболезнования и лучи поддержки.…
При обсуждении под постом https://xn--r1a.website/tech_b0lt_Genona/5163 я вспомнил, что хотел написать на похожую тематику ранее, но как-то замотался и забыл
Я не зря там написал последний абзац
Раньше так же было сложно представить ситуацию с принтерами, как в посте с посудомоечной машиной, но прошло время и мы в моменте, когда чуть ли уже не последний крупный производитель принтеров залез в "очко".
Brother начал блокировать картриджи сторонних производителей после принудительного обновления прошивки принтеров
https://habr.com/ru/news/888020/
Оригинал
Brother accused of locking down third-party printer ink cartridges via forced firmware updates, removing older firmware versions from support portals
https://www.tomshardware.com/peripherals/printers/brother-accused-of-locking-down-third-party-printer-ink-cartridges-via-firmware-updates-removing-older-firmware-versions-from-support-portals
И это ещё половина проблемы. Софт, который "вставляет палки в колёса", ещё и ломает ваше "железо"
HP доигралась. Новая прошивка «окирпичила» ее принтеры, теперь они не работают даже с оригинальными картриджами
https://www.cnews.ru/news/top/2025-03-11_hp_doigralaskrivaya_proshivka
Оригинал
Firmware update bricks HP printers, makes them unable to use HP cartridges
https://arstechnica.com/gadgets/2025/03/firmware-update-bricks-hp-printers-makes-them-unable-to-use-hp-cartridges/
Так что ждём картриджи с моющими средствами без которых ваша посудомойка откажется работать.
ЗЫ С автомобилями такая же ситуация, если не хуже.
Я не зря там написал последний абзац
В целом, наблюдать за всем этим печально, потому что люди ради своего как бы удобства, перестают владеть не только купленным софтом (в самом широком смысле), но теперь уже и железом. Более того, радостно продолжают голосовать за это рублём.
Раньше так же было сложно представить ситуацию с принтерами, как в посте с посудомоечной машиной, но прошло время и мы в моменте, когда чуть ли уже не последний крупный производитель принтеров залез в "очко".
Brother начал блокировать картриджи сторонних производителей после принудительного обновления прошивки принтеров. Также в Brother запустили процесс удаления старых версий прошивок своих принтеров и МФУ с портала техподдержки.
. . .
Россманн признался, что раньше говорил многострадальным владельцам печатающих устройств HP или Canon, столкнувшимся с проблемами DRM картриджей: «Купите лазерный принтер Brother за 100 долларов, и все ваши беды будут решены». Но теперь и Brother пошла по пути HP или Canon.
Brother начал блокировать картриджи сторонних производителей после принудительного обновления прошивки принтеров
https://habr.com/ru/news/888020/
Оригинал
Brother accused of locking down third-party printer ink cartridges via forced firmware updates, removing older firmware versions from support portals
https://www.tomshardware.com/peripherals/printers/brother-accused-of-locking-down-third-party-printer-ink-cartridges-via-firmware-updates-removing-older-firmware-versions-from-support-portals
И это ещё половина проблемы. Софт, который "вставляет палки в колёса", ещё и ломает ваше "железо"
Американская компания HP Inc. окончательно «убила» свои принтеры и многофункциональные устройства (МФУ). Как пишет портал Ars Technica, она выпустила прошивку, которая не дает печатать даже на принтерах, в которых установлены оригинальные расходные материалы.
Опасная прошивка имеет номер 20250209 и ряд устройств, в том числе LaserJet MFP M232-M237 она превращает в «кирпич». Точное количество моделей, которых зацепила проблема, пока не установлено.
Принтеры и МФУ отказываются печатать, даже если установить в них только что купленный оригинальный картридж. Они выдают ошибку с кодом 11. Пользователи начали жаловаться на проблему, притом как на сторонних ресурсах, так и на официальном форуме HP, однако к моменту публикации материала у HP не было готового ее решения.
HP доигралась. Новая прошивка «окирпичила» ее принтеры, теперь они не работают даже с оригинальными картриджами
https://www.cnews.ru/news/top/2025-03-11_hp_doigralaskrivaya_proshivka
Оригинал
Firmware update bricks HP printers, makes them unable to use HP cartridges
https://arstechnica.com/gadgets/2025/03/firmware-update-bricks-hp-printers-makes-them-unable-to-use-hp-cartridges/
Так что ждём картриджи с моющими средствами без которых ваша посудомойка откажется работать.
ЗЫ С автомобилями такая же ситуация, если не хуже.
👍27🤡8😱3🫡3💊3❤2🔥1😁1
В этот замечательный день хочу отметить одного из преданных подписчиков, который нет-нет, да нагрянет почитать посты (а может быть и не читает). Обязательно массово отметится реакциями соответствующими на нескольких постах сразу и будет таков.
С праздником тебя, фанат! ❤️
С праздником тебя, фанат! ❤️
🤡306😁10🥱4👎2💊2❤1🥴1