Ограничивал программу по памяти

Apr 23, 2023 18:04

Первое, что отвалилось, это был pthread_create. ;)

После чего всё совсем упало.

Делал я это с помощью jemalloc и спешу заметить, что сложность его внутри запредельная. Это одна из самых сложных программ, что я видел.

И если это ещё и быстро, быстрее многих других систем управления памятью, то что же в них такое творится?

программирование, распределение памяти

Leave a comment

Comments 13

az_from_belarus April 23 2023, 20:49:34 UTC

Глубоко копаете (уважительно).

А вариант попросту для прогона программок держать пару ящиков (старый и совсем старый) - чем не устраивает?

Reply

thesz April 23 2023, 21:14:38 UTC
Отсутствием ящиков. ;)

Задача была в получении отказа программы при использовании памяти сверх некоторого предела. Если пустить всё на самотёк, то программа убивается (ей SIGKILL посылают или она сама вызывает abort()), но это приводит к остановке кластера. Хотелось получать C++ исключение наподобие std::bad_alloc, но это оказалось практически невозможным.

Ну, и ящиков нету, да. К тому же, на сколь угодно дохлом компьютере мы так же можем получить останов кластера из-за (само)убиения программы, вместо обработки исключения.

Reply

az_from_belarus April 23 2023, 21:24:00 UTC

Не все понял (я так глубоко не залезаю), но суть ясна.

А ящики - надо иметь. Профессионалу или профессиональной команде нужно иметь крутой инструмент для работы и разбитая старая кляча для тестирования. Ну и можно среднерыночную попсово-бюджетную лошадку вдобавок к кляче. Впрочем, надо - только если для открытого рынка. Для корпоративного заказчика можно тупо выставить жестко - "юзать разработку на конфигурациях со следующими минимальными требованиями". Впрочем можно наткнуться и на жесткую ответку - "должно стабильно работать на конфигурациях таких-то или идите нафиг с вашим софтом". :-)

Конечно, пара ящиков не закрывает все вопросы, поскольку кое-что можно увидеть если работают сотни таких ящиков. Но иногда их наличие здорово выручает.

Reply

thesz April 23 2023, 22:21:44 UTC
Тестировать-то мы можем, да вот толку чуть. Тот же std::bad_alloc бросят не тогда, когда попросили многого, а когда ядро решило, что просим многого. Или когда монитор, следящий за текущим используемым объёмом памяти, решит, что просим многого.

А надо бы сразу выявлять слишком большое использование ресурсов.

Вот в SQLite тесты гоняют просто так и, дополнительно, отказывая, последовательно, в N-1, N-2 и так далее до 1-го выделения памяти из N произведённых. Мы так, пока, не можем.

Reply


Leave a comment

Up