Итак, есть приложение, которое потребляет довольно таки большие объемы памяти под временный буфер, загружаемый из базы данных - для увеличения скорости работы. Скажем на тестовой системе с реальной базой это может быть порядка 420M на буфер.

Распределитель памяти Linux работает довольно странно. В системе есть функция перегрузки, когда часть или вся информация изменилась. Буфер целиком уничтожается с помощью вызовов delete - valgrind утечек не обнаружил (на меньших базах). Затем все выделяется обратно с помощью new. Все это имеет древовидную структуру, потому использовать new() (placement new) невозможно.

Тем не менее... В системе 4Gb памяти. Первые четыре перегрузки память увеличивается линейно, пока не достигает отметки 1538M.
Последующие перегрузки остаются на этом пределе - порядка 50% от объема свободной памяти. Даже наблюдается некоторое падение 1515M и т.п.

На системах с меньшим объемом памяти, скажем, если было свободно около 10%, и с базами меньшего размера - обьем буфера вырастает только до второй перегрузки и прекращает рост.


Возможно, распределитель помечает память как discardable и освобождает ее по мере необходимости - но в данном случае такое поведение совсем не желательно - по крайней мере с точки зрения заказчика, который вопит что у меня leak'и и т.п.


Буду благодарен за любую информацию по данному поводу.


Это сообщение отредактировал(а) Dragon - 25.11.2006, 16:12

Dragon
в Linux существует страничный кэш, в нем кэшируются страницы для уменьшения операций I/O (загрузка с диска например, как в твоем случае), посему часть памяти используется для него. Точно не знаю, вероятно его рост прекращается при достижении определенного значения (не может же вся память использоваться под кэш). Видно его увеличение пропорционально объему загружаемых данных

Пропорционально объему и колличеству свободной памяти, да. Если это так, то ничего я с этим не поделаю - нужно менять настройки memory manager'а в ядре.

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



В общем в этом моменте память не вернется в полной мере. Если же убрать std::map, то все будет нормально... Вот так...


Это сообщение отредактировал(а) Dragon - 25.11.2006, 21:30

Dragon. Привет. я тут предполагаю что у тебя система на основе линукса 2.6
насчёт STL - какая аппаратная архитектура системы ?


заказчик конечно человек хороший, но распределение памяти системы - не его забота.
т.е. его забота, но ОПЕРАТИВНАЯ СИСТЕМА решает сколько ей где нужно.
а насчёт соотношения какой процент памяти кешируется, возможно ты хочешь осторожно поиграться с переменными ядра при помощи sysctl, напр. vm.swappiness
Менеджер ядра линукс считает, что "неиспользованная память = ВЫБРОШЕННАЯ память".
объясни это заказчику.

Скорее всего ритм стирания/создания данных не оправдывает постоянное стирание.
Кстати на системах с таким кол-вом памяти важную роль играет кол-во swap-а.
Сколько его на той системе ?



пока.

Привет, bilbobagginz  

Тестовая конфигурация 1:
1. Amd64 - или 4х процессорный двухядерный Opteron или 8-ми процессорный одноядерный, скорее всего первое
2. 4Gb RAM, 3.3 Gb swap
3. SuSE Linux 10.1 - соответственно для Amd64 - ядро с SMP, естественно

Тестовая конфигурация 2:
1. Intel32 - PIV HT 2.8 GHz
2. 512M RAM, 506M swap
3. SuSE Linux 10.1

В общем, ядро 2.6 - практически одинаковое. Да, я знаю, что эта стратегия оправдана, просто хотелось уточнить нет ли способа управлять менеджером памяти. Или высазывать ему "свои пожелания". Т.е. ты думаешь, если отключить swap или сделать его весьма маленьким, то система будет стараться чистить память? Это мысль...

Thanks. В общем, есть ли способ зделать, скажем flush() страницам памяти - или нечто в этом роде? Софтверные способы контроля?

Это сообщение отредактировал(а) Dragon - 26.11.2006, 02:09

Не будет. А вот тормозить - это пожалуйста. У меня правда размахи помельче, на 512 проверял  У нее при нехватке памяти идет жуткая проверка всего что только можно. Но это никак не влияет на то, сколько уходит на кэш. Т.е. все делается "по факту". Надо память - чистит кэш. Если нехватает - свопит. Если все равно нехватает - Segmentation Fault.

Dragon, 
posix_fadvise(2) - может убить (выборочно) кэш. 
еще
systl -w vm.drop_caches=1
Убьет весь кэш. Перед перегрузкой ?


Оставляет порядка процента.

Но я не уверен что дело в кэше. Что за база и где ? На том же компьютере ? 
Главный вопрос - занятая память (1538М) смотрится _по системе_ или на  программе ?

Добавлено @ 08:32 
А вообще (почитал внимательно  ) Тут все таки явные leak'и   
Любой malloc _будет_ освобождать память если количество занятой памяти гораздо меньше требуемой. И она _сразу_ вернется в систему в качестве  "free"

Это сообщение отредактировал(а) GrayCardinal - 26.11.2006, 08:25

для твоего процесса   . Хотя не факт, что будет выбран именно твой

Насколько я помню - больше - порядка 5 - 6% Но не суть важно.


MySQL база. Локальная. Память смотрится по программе (VIRT в top).

Заказчик же смотрит по системе, я только что об этом подумал...  RRD строит графики, периодически  даные обновляются скриптом.
А я то думаю, что они мне вопили про 3Gb. 

Ладно, тем не менее вопрос не снимается - 420M - 839M - 1238M - 1538M - 1538M - 1538M - 1538M - 1515M ...
Попробую поискать пути управления страничным кэшем.

[cut]

Это сообщение отредактировал(а) GrayCardinal - 26.11.2006, 12:47

В-0-вых  базы данных имеют собственный менеджер памяти.

знаете, когда из мертвого бездомного кота ( т.е. MySQL) пытаются сделать тяжеловесного першерона ( ORacle/interbase, ну PostgreSQL на худой конец ) получаются разные неприятности ( напр. тягя слабая ).

Во-первых этот вопрос не в отдел разработки, а в администрацию (т.е. заточка системы под задачу)

Во-вторых, может пора вам пересмотреть целесообразность использования базы май-сикуел. 

с.у.в.

Ну, как я уже сказал, я снимаю показания о виртуальной памяти по программе - так что MySQL тут ни при чем.
Что касается перехода на другие движки, то я буду заниматься поддержкой Oracle в ближайшее время, когда закончу с текущими проблемами. Этот пункт давно находится в списке задач. 

какая версия-то ? похаченная какая-нибудь наверное версия.....

Насчет Oracle? Не думаю, что клиенты приймут похаченную версию. По крайней мере в США правосудие в области интеллектуальной собственности значительно ближе к народу, чем у нас. Честно говоря, им и в голову не могло прийти использование не лицензионной версии )

А MySQL 5.0.18 - и не настолько уж он плох. Правда тяжко ему приходится, когда таблица доходит до 5 Gb размером... Ну так, для этого используются архивы и т.п.


Это сообщение отредактировал(а) Dragon - 28.11.2006, 13:20

MySQL не создавали для работы с большими таблицами, если вы это делаете, возможно вы похачили сам MySQL. ( не Oracle  )

а документы с сайта mysql.com вам не помогают ?

Да ну, проблема не в базе данных, она может быть вообще удаленной - проблема в стратегии менеджера памяти/или аллокаторов С++. Которые кэшируют прорву памяти и используют ее впоследствии. С одной стороны это, наверное, правильно - но с другой хотелось бы это контроллировать.

Но насколько я понял для управления страницами кэша используются ряд функций из man(9):
 - find_or_create_page
 - find_lock_page
 - unlock_page

Но это слишком низкоуровневый доступ. Я даже не уверен, что эти функции могут быть доступны с user-level. В общем, так или иначе, прийдется писать собственный распределитель памяти для STL контейнеров... или забить на это. Дело это мутное, но видать такова моя судьба. 

P.S. Насколько я помню, MySQL InnoDB таблицы, особенно на raw partition's свободно держат > 5 Gb. И уж не думаю, чтобы кто-то хачил код MySQL. Т.е. уверен в этом - иной раз приключаются совсем уж глупые проблемы связанные с повреждением таблиц - особенно если кто-то не внял предупреждению и создал MyISAM. Но при таких размерах для MySQL это естественно.