Нет, я решаю проблему GC другими способами*
	Нет, я использую Terracotta BigMemory, который меня полностью удовлетворяет
	Да, я жду с нетерпением выхода Apache DirectMemory
	Да, но я жду решения проверенного на больших объемах в крупных проектах

Проголосовало 135 человек. Воздержалось 443 человека.

Сколько раз мне приходилось настраивать GC, чтобы вылечить приложение, у которого время от времени случается приступ, и оно перестает временно выполнять свои функции. Работа, скажу, не самая занимательная и требует хорошего знания матчасти. В данном топике я опишу какие еще есть способы решения данной проблемы.

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

История 1

Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.

Издавна существует проблема, которая не позволяет делать двусторонние ссылки между объектами.
Это связано с работой сборщика мусора: объект уничтожается только после удаления последней ссылки на него, а так как объекты ссылаются друг на друга, сборщик не может удалить ни тот, ни другой объект.
Частично это решено в виде функции gc_collect_cycles. Но вызов нужно делать вручную и это жутко ресурсоемкая операция.

Речь пойдёт о сборке мусора и утечках памяти в разных браузерах.

В общем и целом эта тема уже много обсуждалась, я хочу рассмотреть один интересный случай c замыканиями.

Garbage Collection (GC) в Ruby отличается от сборщиков, о которых чаще всего приходится слышать, я имею ввиду Java, C# и иже с ним. И отличает его то, что в Ruby GC не generational, а точнее non-generational. Что это значит? А то, что GC в Ruby не делит объекты на поколения. Использование «поколений объектов» (GC в Java, к примеру) штука сама по себе не простая, суть сводится к тому, что вновь созданные объекты гораздо чаще становятся недостижимыми, чем те объекты, время жизни которых велико. Соответственно, GC, который учитывает поколения, сильно сокращает время выполнения сборки мусора, посколько количество просматриваемых объектов в ходе сборки не так уж и велико, поскольку сборщик обращает внимание только на «молодое» поколение, будучи уверенный в том, что остальные поколения он на славу почистил (существуют и другие поведенческие модели, но эта — основная). Такое деление на поколения и называется generational GC.

Как вы уже догадались, GC в Ruby очень дорогая операция, потому что ему приходится просматривать _все_ объекты в памяти, каждый раз, когда GC будет вызван. Я вам больше скажу, в случае с Ruby on Rails, код Rails хранится в AST (Abstract Syntax Tree) и, что естественно, его тоже приходится просматривать.

Столкнулся я недавно с небольшой проблемой: данные из сессии рандомно пропадали при простое сессии больше 24 (как выяснилось позже) минут.

Вот, что рассказал мне мануал:

Просроченные сессии на самом деле не подвергаются уничтожению сразу же по истечении 24 минут. Вот как все происходит: в начале каждого запроса, использующего сессию (вследствие предварительного вызова функции session_start( ) или установки session/auto_start в on), существует 1% возможности того, что PHP-интерпретатор отсканирует все сессии на сервере и удалит любую из просроченных. «1% возможности» в отношении компьютерной программы звучит совершенно непредсказуемо. Так оно и есть. Но подобная непредсказуемость повышает общую производительность. Интенсивно работающий сайт, занятый в начале исполнения каждого запроса поиском просроченных сессий в целях их удаления, станет расходовать слишком много ресурсов сервера.

Это объясняет «рандомность» удаляемых данных.
Но как решить эту проблему, поскольку в моем проекте время простоя запросто может быть больше 24 минут.