Забавный баг

[metaclass]

Третий день ловлю баг, связанный с тем, что TCP сервер под большой нагрузкой падает с ошибкой out of memory, хотя ему выделено всего 800 мег и еще гиг физической памяти свободно. На каждое воспроизведение бага - сутки работы сервера под нагрузкой в несколько раз больше рабочей.

Оказалось - нехватка виртуальной памяти, причем вообще - не самой памяти, а ее адресного пространства. Менеджер памяти при выделении/удалении сильно фрагментирует память, в итоге адресам становится мало 2^31 и все падает, с ошибками типа "not enough storage" в самых левых функциях вроде записи в инишник.
Причем, западло в том, что увидеть это число в Task Manager нельзя, нужно смотреть Process Explorer или делать лог perfmon-ом.

Comments

[eu3eu.livejournal.com]

А нефиг большие объекты в памяти держать. Временные файлы для того придуманы. Причём, не факт, что они реально на диске создаются - иногда они из кэша не успевают вылиться, как уже прибиваются, так что быстродействие не страдает.

[metaclass.livejournal.com]

Большие объекты как раз нормально работают, в дыры от них потом мелкие селятся. А вот мелкие уже потом фрагментируют это дело вдоль и поперек.
Это реалтаймовый сервер сбора данных, там вся идея именно в том, чтобы держать в памяти множество мелких объектов, чтобы не грузить их из СУБД каждый раз. Но вообще там есть недоработка в этом кэше (лишние объекты лежат в памяти слишком долго), которую можно исправить, но это усложнит код и потребует в очередной раз прогонять все тестирование вдоль и поперек

[zamotivator.livejournal.com]

boost::memory_pool!

[lionet.livejournal.com]

http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf