Разобраться с ООМ на relwithdebinfo #27100
Description
Начиная с 06.10 до 17.10 учащались проблемы с запуском ПРчеков и ночных билдов из-за проблем с ООМ на хостах при запуске первой итерации тестов.
Временным решением проблемы принято повышение ОП для раннеров типа build-preset-relwithdebinfo с 192ГБ до 256ГБ
Был заведен тикет в саппорт девтулзов, в котором был получен ответ "понижайте паралелльность". Для эксперимента был сделан - запуск с --test-threads 40 и --test-threads 20. Запуск с 40 потоками упал, запуск с 20 потоками увеличил время прогона на 20 минут для всего набора small, medium, но завершился успешно.
В процессе разбирательств был написан микроскрипт который позволяет прикинуть объем и динамику потребления ОП для успешных запусков
В выводе мы сейчас имеем график потребления, максимальную точку и то, какие сьюты выполнялись во это время
======================================================================
🔴 МАКСИМАЛЬНОЕ ПОТРЕБЛЕНИЕ ПАМЯТИ
======================================================================
Время: 1760704623
Потребление: 208.0698471069336 GB
Активных процессов: 53
======================================================================
📋 ПРОЦЕССЫ, РАБОТАВШИЕ В МОМЕНТ ПИКА:
1. ydb/tests/functional/restarts [test_restarts.py 7/10] chunk
├─ RSS: 9.189144134521484 GB (4.4% от пика)
├─ Старт: 1760704621
├─ Конец: 1760704788
└─ Общая длительность: 167s
2. ydb/tests/functional/restarts [test_restarts.py 5/10] chunk
├─ RSS: 9.154499053955078 GB (4.4% от пика)
├─ Старт: 1760704611
├─ Конец: 1760704805
└─ Общая длительность: 194s
3. ydb/tests/functional/restarts [test_restarts.py 2/10] chunk
├─ RSS: 9.123401641845703 GB (4.4% от пика)
├─ Старт: 1760704619
├─ Конец: 1760704784
└─ Общая длительность: 165s
4. ydb/tests/functional/cms [test_cms_restart.py 2/10] chunk
├─ RSS: 8.461490631103516 GB (4.1% от пика)
├─ Старт: 1760704596
├─ Конец: 1760704765
└─ Общая длительность: 169s
В рамках тикета предлагается продолжить разбирательство с ньюансами планирования узлов сборки в yamake, а так же продумать порядок сборки, который ганартирует нам потребление "не выше Х" во время работы, но при этом сохранит высокую утилизацию CPU для small тестов