![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Забавный баг
Третий день ловлю баг, связанный с тем, что TCP сервер под большой нагрузкой падает с ошибкой out of memory, хотя ему выделено всего 800 мег и еще гиг физической памяти свободно. На каждое воспроизведение бага - сутки работы сервера под нагрузкой в несколько раз больше рабочей.
Оказалось - нехватка виртуальной памяти, причем вообще - не самой памяти, а ее адресного пространства. Менеджер памяти при выделении/удалении сильно фрагментирует память, в итоге адресам становится мало 2^31 и все падает, с ошибками типа "not enough storage" в самых левых функциях вроде записи в инишник.
Причем, западло в том, что увидеть это число в Task Manager нельзя, нужно смотреть Process Explorer или делать лог perfmon-ом.
Оказалось - нехватка виртуальной памяти, причем вообще - не самой памяти, а ее адресного пространства. Менеджер памяти при выделении/удалении сильно фрагментирует память, в итоге адресам становится мало 2^31 и все падает, с ошибками типа "not enough storage" в самых левых функциях вроде записи в инишник.
Причем, западло в том, что увидеть это число в Task Manager нельзя, нужно смотреть Process Explorer или делать лог perfmon-ом.
no subject
Вот в том числе из-за таких вещей и возникает желание переходить на .net.
no subject
no subject
Еще можно перейти на какую-нибудь альтернативную кучу типа quickheap - который жрет больше памяти, зато лишен упомянутого недостатка, а по эффективности кроет стандартные реализации, как бык овцу (http://rsdn.ru/article/dotnet/GCnet.xml#EPD)
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Фрагментация памяти создает много частично заполненых страниц и свопинг начнется раньше. А если учесть и то, что размер указателя вырос, то программа может потребовать значительно больше памяти.
no subject
Значительно памяти больше программа не потребует. Даже если предпложить что вся программа состоит только из указателей, то памяти будет тратить всего в 2 раза больше, что совсем не много.
no subject
А цену рабочего дня программиста надо сравнивать с ценой памяти, помноженной на количество пользователей...
no subject
no subject
no subject
no subject
Похоже, она типична для телекома...
no subject
no subject
no subject
no subject
no subject
no subject
Это реалтаймовый сервер сбора данных, там вся идея именно в том, чтобы держать в памяти множество мелких объектов, чтобы не грузить их из СУБД каждый раз. Но вообще там есть недоработка в этом кэше (лишние объекты лежат в памяти слишком долго), которую можно исправить, но это усложнит код и потребует в очередной раз прогонять все тестирование вдоль и поперек
no subject
no subject
no subject
интересно, можно ли его, или подобный, раньше чем за сутки обнаруживать - вроде можно, нет?
no subject
no subject
Всё хорошо работало до тех пор, пока люди не написали алгоритм, который в своей работе использует числа порядка двойки в степени 5033164800 (600*1024*1024*8). На такие числа этот наколенный класс пытается выделить непрерывный кусок памяти объёмом в 600 мегабайт, что ему, естественным образом, удаётся не всегда. Язык - C++. К счастью, проблема стала очевидной, когда в отладчике увидели падение на строке new unsigned int[digitsCount] и посмотрели, чему равен digitsCount.
no subject
no subject
Наверное. ;)