LINUX.ORG.RU

История изменений

Исправление kirill_rrr, (текущая версия) :

rrr@raspberrypi:~$ ./test.py      
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    x.append(os.urandom(999))
NameError: name 'os' is not defined

Заменил os.urandom() на urandom(), работа пошла.

rrr@raspberrypi:~$ time ./test.py 
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
MemoryError

real    26m5.570s
user    0m23.415s
sys     15m44.270s

Это был вообще шоколадный сценарий, потому что urandom у меня даёт что то около 4Мб/ сек, т.е. заполнение 4гб лимита за ~16,6 минуты. С такой медленной утечкой памяти, да ещё и без считывания уже записаных данных никаких заметных тормозов не возникло, память процесса стабилизировалась на 270-320М. Минут через 5 мне надоело смотреть на шестерёночки и я пошёл сёрфить дальше. Вытеснение половины памяти, доступной файерфоксу разумеется сделало процесс менее приятным, но ничего такого заоблачного.

Косяк возник когда был достигнут лимит, выдана ошибка и понадобилось вычистить процесс из памяти и свопа. Вот тогда система начала серьёзно тормозить и сёрфить уже стало нереально. Но вот уйти в консоль и прибить всё через htop я однозначно смог бы. Похоже разница между временем real и user+sys и является временим самовыпиливания питона. На момент начала теста в свопе лежало 1,3Гб, при обработке ошибки 3,75Гб. Т.е. далеко не 4Гб на питон, а всего 2,5-3. Почему? Хз. zram 2 диска по 200М при 942М доступной. Т.е. 42,5% или тот самый

Худший эффект (для системы и отзывчивости) достигается при больших объемах zram disksize.

Да, и вывод: если малина с гигом памяти ведёт себя лучше вашего 10гб ПК, то у вас определённо лютый косяк подсистемы свопа.

Исходная версия kirill_rrr, :

rrr@raspberrypi:~$ ./test.py      
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    x.append(os.urandom(999))
NameError: name 'os' is not defined

Заменил os.urandom() на urandom(), работа пошла.

rrr@raspberrypi:~$ time ./test.py 
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
MemoryError

real    26m5.570s
user    0m23.415s
sys     15m44.270s

Это был вообще шоколадный сценарий, потому что urandom у меня даёт что то около 4Мб/ сек, т.е. заполнение 4гб лимита за ~16,6 минуты. С такой медленной утечкой памяти, да ещё и без считывания уже записаных данных никаких заметных тормозов не возникло, память процесса стабилизировалась на 270-320М. Минут через 5 мне надоело смотреть на шестерёночки и я пошёл сёрфить дальше. Вытеснение половины памяти, доступной файерфоксу разумеется сделало процесс менее приятным, но ничего такого заоблачного.

Косяк возник когда был достигнут лимит, выдана ошибка и понадобилось вычистить процесс из памяти и свопа. Вот тогда система начала серьёзно тормозить и сёрфить уже стало нереально. Но вот уйти в консоль и прибить всё через htop я однозначно смог бы. Похоже разница между временем real и user+sys и является временим самовыпиливания питона. На момент начала теста в свопе лежало 1,3Гб, при обработке ошибки 3,75Гб. Т.е. далеко не 4Гб на питон, а всего 2,5-3. Почему? Хз. zram 2 диска по 200М при 942М доступной. Т.е. 42,5% или тот самый

Худший эффект (для системы и отзывчивости) достигается при больших объемах zram disksize.