Решение проблемы и минимизация использования памяти в Common Lisp (SBCL)

Question

У меня есть VPS с небольшим объемом памяти (256 МБ), который я пытаюсь использовать для разработки на Common Lisp с помощью SBCL + Hunchentoo для написания нескольких простых веб-приложений.Кажется, что большой объем памяти используется без выполнения чего-либо особенно сложного, и через некоторое время обслуживания страниц у него заканчивается память, и он либо сходит с ума, используя всю подкачку, либо (если подкачки нет) просто умирает.

Поэтому мне нужна помощь, чтобы:

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

Я предполагаю, что первые два достаточно просты, но возможен ли вообще третий?Как люди справляются с нехваткой памяти или ограниченными условиями памяти в Lisp?

(Также я отмечаю, что 64-разрядный SBCL, по-видимому, использует буквально в два раза больше памяти, чем 32-разрядный.Ожидаемо ли это?Я могу запустить 32-разрядную версию, если это сэкономит много памяти)

Answer 1

Чтобы ограничить использование памяти SBCL, используйте параметр --dynamic-space-size (например,sbcl --dynamic-space-size 128 ограничит использование памяти 128 МБ).

Чтобы узнать, кто использует память, вы можете позвонить (room) (функция, которая сообщает, сколько памяти используется) в разное время:при запуске, после загрузки всех библиотек, а затем во время работы (конечно, вызовите (sb-ext:gc :full t) перед помещением не измерять мусор, который еще не был собран).

Кроме того, можно использовать профилировщик SBCL для измерения распределения памяти.

Answer 2

Узнайте, что использует всю память (особенно если это библиотеки или я)

У Attila Lendvai есть некоторый специфичный для SBCL код, позволяющий выяснить, откуда берутся выделенные объекты.Обратитесь к http://article.gmane.org/gmane.lisp.steel-bank.devel/12903 и напишите ему личное письмо, если понадобится.

Обязательно попробуйте другую реализацию, предпочтительно с точным GC (например, Clozure CL), чтобы убедиться, что это не утечка, связанная с конкретной реализацией.

Ограничьте объем памяти, который разрешено использовать SBCL , чтобы избежать огромных объемов подкачки

Уже даны ответы другими.

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

256 МБ - это немного, но в любом случае:запланируйте повторяющийся (возможно, через 1 секунду) временной поток, который проверяет оставшееся свободное пространство.Если свободного места меньше X, то используйте exec() для замены текущего изображения процесса SBCL на новое.

Answer 3

Если у вас нет никаких объявлений типов, я бы ожидал, что 64-разрядный Lisp займет в два раза больше места, чем 32-разрядный.Даже простой (маленький) int будет использовать 64-битный фрагмент памяти.Я не думаю, что в нем будет использоваться меньше машинного слова, если вы не объявите его.

Я не могу помочь с # 2 и # 3, но если вы разберетесь с # 1, я подозреваю, что это не будет проблемой.Я видел экземпляры SBCL / Hunchentoo, запущенные целую вечность назад.Если я использую запредельный объем памяти, обычно это моя собственная вина.:-)

Answer 4

Я бы не удивился, если бы 64-разрядный SBCL использовал в два раза больше meory, поскольку он, вероятно, будет использовать 64-разрядную ячейку, а не 32-разрядную, но не мог бы сказать наверняка, фактически не проверив.

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