GD
x32 ?
Size: a a a
2020 March 05
GD
если выделяется какой-нибудь вектор или массив, то ему нужно непрерывное адресное пространство. Поэтому если утекли копейки, но разбили пространство пополам, то больше вы его выделить не сможете и будете получать bad_alloc, хотя по диспетчеру задач память вернется
M
Grigory Dobrov
если выделяется какой-нибудь вектор или массив, то ему нужно непрерывное адресное пространство. Поэтому если утекли копейки, но разбили пространство пополам, то больше вы его выделить не сможете и будете получать bad_alloc, хотя по диспетчеру задач память вернется
Да, интересная мысль
CD
Всем привет! Столкнулся со следующей проблемой. У меня есть сервер, который принимает запросы, протокол не важен. Тест кейс такой:
1. Формирую большой запрос, для которого у сервиса хватит памяти чтобы обработать, получаю валидный результат.
2. Формирую большой запрос, для которого у сервиса точно не хватит памяти, чтобы обработать - получаю bad allocation
3. Снова формирую такой же запрос, как и на первом шаге - получаю bad allocation
4. Формирую большой запрос, но меньше чем в первом шаге - получаю валидный ответ.
5. До перезапуска сервиса, все запросы, такого же размера, как в первом шаге возвращают bad allocation.
В связи с этим, несколько вопросов:
1. Возможно ли такое поведение из-за выделения памяти ОС? После bad allocation что-то случается с фрагментацией памяти, и я не могу уже выделять такие большие области как прежде?
2. Поведение замечено на WIndows. Есть ли какие то особенности для этой ОС с хэндлом bad allocation исключения?
Спасибо за внимание!
1. Формирую большой запрос, для которого у сервиса хватит памяти чтобы обработать, получаю валидный результат.
2. Формирую большой запрос, для которого у сервиса точно не хватит памяти, чтобы обработать - получаю bad allocation
3. Снова формирую такой же запрос, как и на первом шаге - получаю bad allocation
4. Формирую большой запрос, но меньше чем в первом шаге - получаю валидный ответ.
5. До перезапуска сервиса, все запросы, такого же размера, как в первом шаге возвращают bad allocation.
В связи с этим, несколько вопросов:
1. Возможно ли такое поведение из-за выделения памяти ОС? После bad allocation что-то случается с фрагментацией памяти, и я не могу уже выделять такие большие области как прежде?
2. Поведение замечено на WIndows. Есть ли какие то особенности для этой ОС с хэндлом bad allocation исключения?
Спасибо за внимание!
в х32 вы не решите эту проблему никогда
CD
Но выдялется именно вектор чаров и удаляется тоже
Если произошла любая аллокация статической переменной или что-то подобное, все фрагментировалось
На практике выделение последовательного блока более 60М на х32 при длительной работе можно считать ненадежным
На практике выделение последовательного блока более 60М на х32 при длительной работе можно считать ненадежным
M
в х32 вы не решите эту проблему никогда
Какую именно? Что после bad allocation не могу отправить те же данные, что до этого обрабатывались?
M
Если произошла любая аллокация статической переменной или что-то подобное, все фрагментировалось
На практике выделение последовательного блока более 60М на х32 при длительной работе можно считать ненадежным
На практике выделение последовательного блока более 60М на х32 при длительной работе можно считать ненадежным
Интересно, а где про это можно узнать?
CD
Интересно, а где про это можно узнать?
Проводить с этим эксперименты
CD
На самом деле это может решаться довольно легко с помощью кастомных аллокаторов и отдельного хипа под запрос. Я так лечил подобную проблему. Но протаскивать алокаторы может оказаться неприятным экспириенсом.
Единственный путь в 32 - изолированная аллокация и полное освобождение данных (т. е. абсолютно никаких кешей между запросами), да
CD
На практике проще даже избегать длинных аллокаций
m
Единственный путь в 32 - изолированная аллокация и полное освобождение данных (т. е. абсолютно никаких кешей между запросами), да
Достаточно только самые большие куски на отдельной куче аллоцировать.
CD
Достаточно только самые большие куски на отдельной куче аллоцировать.
Мне кажется, проще не аллоцировать больше 1М последовательного блока :)
IA
Какой вы используете подход, если вам нужно отменить boost::steady_timer. Дело в том, что у меня происходит data race при cancel(). Таймер крутится на io_context'e в другом потоке
CD
Достаточно только самые большие куски на отдельной куче аллоцировать.
Могу сказать от себя, что мы конкретно задолбались с использованием диска как того-самого-аллокатора, пока нельзя было на 64 глобально перейти
ПК
Какой вы используете подход, если вам нужно отменить boost::steady_timer. Дело в том, что у меня происходит data race при cancel(). Таймер крутится на io_context'e в другом потоке
Ну дак херани мутекс
IA
Ну дак херани мутекс
До m_timer.cancel()? не помогает. Я думаю, может как-то подход вообще пересмотреть