Errno 5 errno 12 невозможно выделить память

Обновлено: 02.07.2024

У меня есть этот журнал ошибок из MySQL, любая идея? Сайт работает некоторое время, а затем я получаю MySQL shutdown полностью через пару часов.

Mysql не может перезапустить, потому что у него нет памяти, проверьте, что у вас настроен соответствующий файл подкачки.

не помогло? Если это не ваша проблема, более квалифицированные вопросы для продолжения исследования:

у меня была именно эта проблема в самой первой системе, которую я установил на EC2, характеризующейся сайтом wordpress, размещенным там, иногда с "ошибкой установления соединения с базой данных".

журналы показали ту же ошибку,что и OP. Мое чтение ошибки (метки времени удалил):

  • ошибка памяти : InnoDB: Fatal error: cannot allocate memory for the buffer pool
  • InnoDB не может начать без достаточной памяти [ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] Unknown/unsupported storage engine: InnoDB [ERROR] Aborting
  • mysqld завершает работу, что в этом контексте действительно означает невозможность перезапуска! [Note] /usr/sbin/mysqld: Shutdown complete

проверка /var/log/syslog и поиск в MySQL выходы:

Примечание: вам может потребоваться gunzip и поиск по архивным журналам, если ошибка произошла до того, как журналы были повернуты демон cron.

решение

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

вы можете проверить, если у вас есть один настроен, запустив free -m .

total used free shared buffers cached Mem: 604340 587364 16976 0 29260 72280 -/+ buffers/cache: 485824 118516 Swap: 0 0 0

в приведенном выше примере Swap: 0 указывает на отсутствие файла подкачки.

учебники по настройке:

обратите внимание, что больше не означает лучше! с руководство Ubuntu:

"убывающая отдача" означает, что если вам нужно больше места подкачки, чем в два раза ваш размер ОЗУ, вам лучше добавить больше ОЗУ, поскольку доступ к жесткому диску (HDD) примерно на 103 медленнее, чем доступ к ОЗУ, поэтому что-то, что займет 1 секунду, вдруг занимает более 15 минут! И еще более минуты на быстром твердотельном накопителе (SSD).

The InnoDB memory heap is disabled

[Note] Plugin 'FEDERATED' is disabled.

решение не больше места, проблема-веб-сервер Apache, а не mysql, на самом деле вам нужно уменьшить innodb-buffer-pool-size

этот буфер используется процессом mysql с самого начала, поэтому, когда Apache нуждается в большем количестве ресурсов, ядро очистит ОЗУ от служб, это означает остановку mysql вместо сбоя сервера.

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

Текущий пример использования

В случае, если это поможет моему случаю использования, выполните следующие действия:

Я вывожу db-запросы, затем сохраняю полученные таблицы на удаленной машине. Затем я хочу передать их по сети и провести анализ. До сих пор в python я делал что-то вроде следующего:

В какой-то момент я получаю следующую ошибку в команде check_output: [Errno 12] Невозможно выделить память

Фон

Благодаря следующим вопросам, я думаю, у меня есть представление о том, что не так. Существует ряд решений, и я пытаюсь определить, какое из решений позволит избежать [Errno 12]. Невозможно выделить ошибку памяти, связанную с реализацией подпроцесса, используя fork/clone.

Подпроцесс Python.Popen "OSError: [Errno 12] Невозможно выделить память" Это дает базовый диагноз и предлагает некоторое обходное решение, например, размножение script и т.д.

Общие сведения о ошибках размещения виджета и памяти Python Предлагает использовать rfoo для обхода ограничения подпроцесса fork/clone и нереста дочернего процесса и копирования памяти и т.д. Это похоже на подразумевает модель клиент-сервер

Каков самый простой способ SSH с использованием Python?, но у меня есть дополнительные ограничения, которые я не могу использовать подпроцесс из-за ограничений памяти и реализации fork/clone? Решения предполагают использование парамико или что-то построенное поверх него, другие предлагают подпроцесс (который, как я нашел, не будет работать в моем случае).

Актуальные вопросы

Означает ли это, что в конечном итоге paramiko использует описанное выше решение Popen, которое будет иметь проблемы при увеличении объема памяти python и повторных вызовах Popen из-за реализации клона/вилки?

Примечания Я использую 64-битную основную память объемом 8 ГБ. Я не хочу использовать варианты покупки большего объема оперативной памяти.

Я сталкиваюсь со следующей проблемой. Я пытаюсь распараллелить функцию, которая обновляет файл, но я не могу запустить Pool() из-за OSError: [Errno 12] Cannot allocate memory . Я начал осматриваться на сервере, и я не использую старый, слабый / не хватает реальной памяти. Смотрите htop : Кроме того, free -m показывает, что у меня есть много оперативной памяти в дополнение к

7 ГБ памяти подкачки: И файлы, с которыми я пытаюсь работать, тоже не такие большие. Я вставлю свой код (и трассировку стека) ниже, там размеры следующие:

Используемый кадр данных predictionmatrix занимает ок. 80 МБ в соответствии с pandasdataframe.memory_usage() Файл geo.geojson составляет 2 МБ

Как мне отладить это? Что я могу проверить и как? Спасибо за любые советы / хитрости!

ОБНОВЛЕНИЕ

Согласно решению @ robyschek, я обновил свой код до:

И я все еще получаю ту же ошибку. Кроме того, согласно документации, map() должен разделить мой data на куски, так что я не думаю, что он должен повторять мои временные интервалы 80 МБ. Хотя я могу ошибаться . :) Кроме того, я заметил, что если я использую меньший ввод (

11 МБ вместо 80 МБ), я не получаю ошибку. Так что я думаю, что пытаюсь использовать слишком много памяти, но я не могу себе представить, как она переходит от 80 МБ к чему-то, что 16 ГБ ОЗУ не может обработать.

2 ответа

У нас было это пару раз. По словам моего системного администратора, в Unix есть «ошибка», которая выдает ту же ошибку, если у вас недостаточно памяти или если ваш процесс достигает максимального предела дескриптора файла.

Так что вы должны посмотреть на свой скрипт и дважды проверить, не является ли проблема созданием слишком большого количества FD.

При использовании multiprocessing.Pool способ запуска процессов по умолчанию - fork . Проблема с fork заключается в том, что весь процесс дублируется. (см. подробности здесь). Таким образом, если ваш основной процесс уже использует много памяти, эта память будет дублирована, достигнув этого MemoryError . Например, если ваш основной процесс использует 2GB памяти и вы используете 8 подпроцессов, вам потребуется 18GB в ОЗУ.

Вы должны попробовать использовать другой метод запуска, такой как 'forkserver' или 'spawn' :

Эти методы позволяют избежать дублирования рабочей области вашего Process , но могут запускаться немного медленнее, поскольку вам необходимо перезагрузить используемые модули.

Примечание. Этот вопрос изначально был задан здесь, но время выплаты было истекло, хотя приемлемый ответ на самом деле не найден. Я повторно задаю этот вопрос, включая все детали, представленные в исходном вопросе.

Python script запускает набор функций класса каждые 60 секунд с помощью модуля sched:

script работает как демоннизированный процесс, используя код здесь.

Несколько методов класса, которые называются частью doChecks, используют модуль subprocess для вызова системных функций, чтобы получить системную статистику

Это нормально работает в течение периода времени до полного сбоя script со следующей ошибкой:

Выход free -m на сервере после разбиения script:

Сервер работает с CentOS 5.3. Я не могу воспроизвести свои собственные коробки CentOS, ни с каким-либо другим пользователем, сообщающим о той же проблеме.

Я пробовал несколько вещей, чтобы отладить это, как было предложено в исходном вопросе:

Запись выходного файла free -m до и после вызова Popen. Нет существенных изменений в использовании памяти, т.е. Память постепенно не используется, пока запускается script.

Я добавил close_fds = True для вызова Popen, но это не имело значения - script по-прежнему разбился с той же ошибкой. Здесь здесь и здесь.

Я проверил rlimits, которые показали (-1, -1) как на RLIMIT_DATA, так и на RLIMIT_AS, как предложено здесь.

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

Все проверки можно найти на GitHub здесь с функцией getProcesses, определенной из строки 442. Это вызвано doChecks(), начиная с строка 520.

script запускался с strace со следующим выходом перед сбоем:

из-за "каналов" или файловых дескрипторов или ресурсов ядра, связанных с ними? Вы когда-нибудь получали решение для этого? У меня очень похожие симптомы. У меня много свободной памяти, но после добавления свопа (как показывают некоторые ваши ответы) проблема исчезает. Просто подумал, узнал ли ты что-нибудь за месяцы между тем и сейчас. -- Спасибо! Я сталкиваюсь с той же проблемой, но без разрешения - есть идеи? @user248237 user248237, вы должны (в порядке предпочтения) либо (1) добавить больше подкачки , и / или (2) ослабить политику overcommit (так, чтобы ОС позволяла вам fork большой процесс, такой как python даже если очень мало свободной памяти доступно в «обещании», что exec гораздо меньшего процесса сразу же последует за fork ) и / или (3) уменьшит объем памяти вашего скрипта, так что fork не придется тратить столько памяти от вашего имени (преследуйте утечки памяти и раздувание и т. д.) и / или (4) порождение вспомогательного процесса, использование posix_spawn / vfork и т. д.

Как правило (т.е. в ядрах ванили), fork / clone происходят сбои с ENOMEM из-за того, что честный по отношению к Богу недостаток памяти ( dup_mm , dup_task_struct , alloc_pid , mpol_dup , mm_init и т.д. croak), или потому что security_vm_enough_memory_mm вам не удалось , а принудительно выполнить политика overcommit.

Начните с проверки vmsize процесса, который не был вилок, во время попытки fork, а затем сравните с объемом свободной памяти (физический и своп), относящейся к политике overcommit (подключите числа в.)

В вашем конкретном случае обратите внимание, что Virtuozzo имеет дополнительные проверки в overcommit правоприменительные. Более того, я не уверен, сколько у вас действительно контроля, от внутри вашего контейнера, свопинг и переназначение конфигурации (чтобы повлиять на результат принудительного исполнения.)

Теперь, чтобы действительно двигаться вперед, я бы сказал, что вы слева с двумя параметрами:

  • переключиться на более крупный экземпляр или
  • добавьте некоторые усилия по кодированию в , более эффективно контролируя объем

ПРИМЕЧАНИЕ, что усилия по кодированию могут быть все без изменений, если выяснится, что это не вы, но какой-то другой парень собрался в другом экземпляре на том же сервере, что и ваш amock.

Читайте также: