slav0nic
10 раз повторяю, это нормальное поведение, повтори запрос и увидишь, что озу не стало в 2 раза больше и это не memory leak

Повторно загружаю страницу вновь и вновь…ну в 2 раза не стала больше, а за раз на 1мб в среднем накапывает память=) Уж не знаю это утечки или особенности работы Джанги

slav0nic
мне лень искать, но гуглится на тему
сделай x = range(100000);del x; будет тот же “прикол”

Я только что это сделал, мой предыдущий пост, - поднимите взор выше и увидите результаты - после gc.collect() количество памяти возвращается в состояние первичного запуска питона.

slav0nic
тут в другом вопрос, нахрена ты делаешь fetchall(), чтоб вывести count()? и зачем тебе всё сразу читать в память

Это только тестовый пример (немногим выше это написал), в реале над списком могут выполнятся, например математические или статистические операции по нескольким формулам и т.п. не в этом суть вопроса.

kmike Если сделать еще одну функцию представления для другой страницы, в которой поменять запрос к бд ( к другой таблице), то картина следующая: при запуске встроенного сервера Джанга занимает 9мб, после захода на вторую страницу (где меньше записей из бд) потребление памяти возрастает до 17мб, после захода на первую страницу возрастает до 50мб. Если поменять порядок захода, то сперва 50 мб, а потом…тоже 50 мб =) . Стоит напомнить что сам объем данных возвращаемых из БД не 50 мб а 110мб или более. Если поставить в конце функций del и gc.collect() то картина не меняется.
Блин как то так

да причём здесь вообще джанга…
напиши тоже самое в обычном скрипте и играйся дальше, раз такой упрямый)

slav0nic ну нет, что вы, я вовсе не упрямый=) Наверное мы просто не поняли друг друга.

В общем дело разумеется не в Django, а в особенностях работы питона. В какие то моменты он освобождает память полностью, а в какие то нет, для подтверждения этих слов приведу примеры:

1)я открою консоль python и буду вводить команды, в комментариях буду писать занимаемый процессом объем памяти RSS:
То есть мы открыли консоль питона, получили длинный список/выделили память процессу, удалили список, вызвали сборщик мусора/ освободили память. И количество памяти занимаемое процессом в конце примерно равно тому количеству что было в начале. Это хорошее и красивое поведение - оно не оставляет вопросов. (напоминает типичные действия в таких языках как С)

2) Возьмем функцию представления из первого поста и переделаем так что бы вызвать ее обычным интерпретатором Python. В результате после запроса из бд у меня было занято около 110мб памяти, после удаления списка и вызова сборщика мусора значение стало 41мб. Это мне не выгодное поведение, но так уж видимо устроен Питон.

Хотя сама проблема чрезмерного потребления памяти на боевом сервере осталась, но собственно с этим ничего не поделать наверняка, поэтому вопрос теряет актуальность я думаю.
Спасибо всем откликнувшимся!

если устраивает, то делай выборку меньшими блоками, чтоб не хранить здоровый список в озу