Как иметь дело с утечками памяти в RMagick в Ruby?

Я тоже столкнулся с этой проблемой - решение состоит в принудительной сборке мусора.

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

В более поздних версиях RMagick, я также считаю, что вы также можете вызвать destroy! на изображении, когда вы закончите его обработку.

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

В качестве альтернативы вы можете использовать mini-magick , который является оболочкой для клиента командной строки ImageMagick.

На самом деле, это не проблема, специфичная для Ruby, другие интерпретаторы тоже разделяют ее. Конкретная проблема заключается в том, что сборщик мусора Ruby видит только память, выделенную самим Ruby, а не внешними библиотеками (за заметным исключением библиотеки, использующей средства управления памятью Rubys). Итак, ImageMagick-Object в пространстве памяти Ruby действительно мал, но изображение в пространстве, управляемом ImageMagick, велико. Итак, это не утечка сама по себе, но она ведет себя как утечка. Сборщик мусора Rubys никогда не сработает, если ваш процесс не превышает определенного предела (стандартно 8 МБ). Поскольку ImageMagick никогда не создает большие объекты в пространстве Ruby, он, вероятно, никогда не сработает. Итак, вы либо используете предложенный метод создания нового процесса, либо используете exec. Еще один довольно изящный вариант - иметь на бэкэнде службу обработки изображений, которая выполняет ответвления для каждой задачи. Другой вариант - иметь какой-то мониторинг, который время от времени запускает сборщик мусора.

Существует еще одна библиотека, названная MagickWand Тимоти Полом Хантером (автором RMagick), которая пытается решить эти проблемы и создать более удобный API. Он находится в альфа-версии и требует довольно новой версии ImageMagick.

Это не из-за ImageMagick; это связано с самим Ruby, и это хорошо известная проблема. Я предлагаю разделить вашу программу на две части: долго работающую часть, которая выделяет мало памяти и занимается только управлением системой, и отдельную программу, которая фактически выполняет обработку. Длительный процесс управления должен делать ровно столько, чтобы найти некоторую работу для дочернего процесса, который он порождает, и дочерний процесс должен выполнять всю обработку для этого конкретного рабочего элемента.

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

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

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

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