RAM i Python

Чи є дефолтне обмеження RAM яке може бути використане Python? На 16G машині падає процес займаючи при цьому 6G. При цьому вільної мапяті там більше 12G.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Почему упорно автор не показывает стек трейс? Там целая куча вариантов, например в *unix все есть файл, может упираешься в лимит дискрипторов. Сам питон интерпретатор x64? Хз на счет питона, но x32 джава на x64 ОС тоже не может выйти за лимит адресного пространства.

попробуйте на другой машине, походу сервер криво настроен. ваша програмка которая набрала 15 гигов занимает память меньшими шагами чем 0.3 гига от матриц.

/var/log — там може бути багато цікавого.

Є підозра, що процес ВЖЕ хаває свої 16, просто він вигружений в своп частково. Або ж, якщо це хостинг, тебе просто на**али по пам′яті, реально виділивши менше та підробивши показники.

А також можливе звичайнісіньке собі переповнення індекса або ідентификатора, от генератор і валиться. Перевір, щоб в тебе не було великої кількості індексованих даних. Бажано, взагалі щоб малі порції даних, які не мають самостійної ролі в системі — взагалі не мали ідентифікаторів, а були лише елементом свого об′єкта чи масива. Навіть якщо це призведе до дублювання даних в пам′яті. Що це дасть — операційна система зможе легко викидати в своп все, чім зараз не користуєся. А збирач сміття дуже швидко знаходитиме непотрібні об′єкти.

Спробуй відслідкувати саме збирач сміття. В таких завданнях йому не позаздриш, особливо якщо використовуються замкнення. Та й взагалі спробуй подивитися, ЧОМУ падає процес, він же має щось при цьому казати.

Якщо в тебе 12 гіг гуляє — просто спробуй імітувати ситуацію в окремому процесі (в циклі створюй об′єкти і давай собі паузу щоб ти встиг зупинити процес), я чомусь впевнений що він з легкістю набере свої 12 гіг. Можеш це зробити навіть в себе на компі, лише дай свопу побільше. Тобто, доведи свою гіпотезу, або зруйнуй. Так само можешь в себе на компі пустити і копію бойового процеса, якщо він дружить зі свопом.

Є підозра, що процес ВЖЕ хаває свої 16, просто він вигружений в своп частково.
як це перевірити?
Або ж, якщо це хостинг, тебе просто на**али по пам′яті, реально виділивши менше та підробивши показники.
Так хостинг, місцевий адмін каже не на**али.

В мене на 4G лептопі той самий код при легших параметрах набирає свої ~3.5 G.
В /var/log:
-rw-r----- 1 syslog 15096 Feb 18 06:25 syslog.1
-rw-r----- 1 mysql 0 Feb 18 06:25 mysql.log
drwxr-s--- 2 mysql 4096 Feb 18 06:25 mysql
drwxr-x--- 2 openfire 4096 Feb 18 12:16 openfire
-rw-rw---- 1 root 17576448 Feb 18 13:55 btmp
-rw-r----- 1 syslog 3830 Feb 18 14:09 syslog
-rw-r----- 1 syslog 2759909 Feb 18 14:11 auth.log
-rw-rw-r— 1 root 62976 Feb 18 14:11 wtmp
-rw-rw-r— 1 root 32412 Feb 18 14:11 lastlog

Ну содержимое syslog после падения посмотри.

Там тільки за останні 6 год., креш відбувся раніше, ніякої інфи:

Feb 24 06:25:50 c CRON[5186]: (CRON) info (No MTA installed, discarding output)
Feb 24 06:39:01 c CRON[6006]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Feb 24 07:09:01 c CRON[7569]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Feb 24 07:17:01 c CRON[8000]: (root) CMD ( cd / && run-parts —report /etc/cron.hourly)
Feb 24 07:39:01 c CRON[9129]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Feb 24 08:09:01 c CRON[10641]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Feb 24 08:17:01 c CRON[11071]: (root) CMD ( cd / && run-parts —report /etc/cron.hourly)

До речі free показує
total used free shared buffers cached
Mem: 16434056 5840544 10593512 32708 830040 4009564
-/+ buffers/cache: 1000940 15433116
Swap: 2096444 0 2096444

Я навіть до вільної 10593512 не дотягую.

Написав простеньку програму, запустив на сервері
doc_sett = []
for jj in range(0, 1000):
for ii in range(0, 10000000):
doc_sett.append(0.4334*(ii*2.3+jj))
print (memory_usage_psutil())

Впевнено досягла 15.6G

Впевнено досягла 15.6G

Ну так воно так и буде, ви ж самi листа на 10 мiлярдiв елементiв набираете.

Так перше обмеження на число елементів, чи на пам’ять яку вони займають?

Операционка, разрядность?

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
Linux c 3.13.0-51-generic #84-Ubuntu SMP Wed Apr 15 12:08:34 UTC 2015×86_64×86_64×86_64 GNU/Linux

А вы не пробовали написать по адресу, т.е. в девлист пайтона? На стековерфлоу, напонец. Поверьте, люди, которые могут ответить на ваш вопрос достаточно заняты, чтобы не втыкать на доу. Не за что!

На стековерфлоу чекаю відповіді на одне питання вже місяць :)))), доу набагато помічніший.

в самой ОС какие ограничения?
распараллелить пробовали?
загляните сюда: stackoverflow.com/...85185/python-memory-limit
там люди утверждают, что без проблем и бо́льший объем выделяли.
так шо вариантов очень много: ограничение ОС, ограничение конфига, ограничения на файловые операции(может, это у вас так один файл за раз в память выгружается?)

Я не знаю, что там у вас за процесс. но нужно аналитически подумать может ли он (процесс) есть 6 гиг. Если нет, то возможны какие то утечки в самой программе.
И да, на счет 6 гиг, я надеюсь , вы имели ввиду ресурсную память, а не виртуальную.

Так, ресурсну, йдуть послідовні обчислення попарних відстаней в невеликих матрицях:
dist_words_20 = np.zeros((len(UU[2]),len(UU[0])), dtype=np.float16)
dist_words_20[:] = distance.cdist(UU[2],UU[0],metric=’euclidean’)

Невеликi — це поняття вiдносне. Але якщо, у вашiй програмi, ви одночасно не оперуете великою кiлькостю элементiв, то 6gb пам’ятi виглядае дуже пiдозрiло.
Це може бути баг у самiй програмi, або цього питона треба пiдштовхнути до дефрагметацii.

Невеликi — це поняття вiдносне.
— одна матричка продукує відстаней на ~0.3G. Тоді як, в проміжний файл записувати дані?

До речi, щоб виявити баг у самiй прозi, бажано використовувати профайлер.

Та нема там багу, матриці однотипні.

Насправдi, якщо мове йде про ОС Linux, то треба дивитись таку штуку, як — OOM_Killer. Насправдi це воно мочить процеси, якi жеруть пам’ять.
Так, i якщо я не помиляюсь, то рiшення мочити чи не мочити вiн приймае незалежно вiд того, чи е у системi вiльна пам’ять

Вы бы не могули более детально описать ошибку? С каким эксепшен падает процесс? я не разибарюсь в Python, но думаю, что детали не помешают.

Просто на Python код не виділяється більше 6G пам’яті. Коли використовую чуть менше даних, все ок.

Значит неэффективно используете возможности языка, как минимум.
Питон не упирается в 6гб, я обрабатываю 20гб+ файлы/данные на машине с 8гб памяти на борту, без проблем (не анализ данных конечно, операции попроще).
Вероятно в Вашем случае — сильно много данных загружается непосредственно в память, после чего не хватает памяти именно для обработки этих данных, что вызывает экзепшн.

Заміри пам’яті проводжу:
process = psutil.Process(os.getpid())
mem = process.get_memory_info()[0] / float(2 ** 20)
після кожного кроку, ріст пам’яті йде монотонно з кроком десь 0.3G.

Йдуть послідовні обчислення попарних відстаней в невеликих матрицях:
dist_words_20 = np.zeros((len(UU[2]),len(UU[0])), dtype=np.float16)
dist_words_20[:] = distance.cdist(UU[2],UU[0],metric=’euclidean’)
При досягненні 6G креш.

у вас по ходу падає в момент аллокейту великої килькості даних на момент, коли пітон вже зїв 6. Треба дивитися код

Підписатись на коментарі