Найти утечку памяти в очень сложном приложении Ruby

Question

каждый!

Приятно работать с Ruby и написать немного кода.Но в конце этой недели я заметил, что у нас есть некоторые проблемы в нашем приложении.Использование памяти растет как функция O (x * 3).

Наше приложение очень сложное, оно основано на EventMachine и других внешних библиотеках.Более того, он работает под amd64-битной версией FreeBSD с использованием Ruby 1.8.7-p382

Я сам пытался найти способ найти утечку памяти в нашем приложении.Я нашел много инструментов и библиотек, но они не работают под FreeBSD'64bit, и я понятия не имею, как найти утечки в огромном Ruby-приложении.Это нормально, если у вас мало файлов с 200-300 строками кода, но здесь у вас есть около 30 файлов со средним числом строк 200-300.

Я просто понимаю, мне нужно слишком много времени, чтобы найтите утечки, делающие глупые действия: верьте / исследуйте / предполагайте, что некоторая часть этого кода может быть действительно утечка и обертывают некоторый код отслеживания, как при использовании техники драгоценных камней ruby-prof.Но это очень болезненно медленный путь, потому что, как я сказал, у нас слишком много кода.

Итак, мой вопрос, как найти утечку памяти в очень сложном приложении Ruby и не вкладывать всю свою жизнь в эту работу?

Спасибо заранее

Answer 1

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

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

Одним из способов избежать создания мусора является более эффективное использование памяти. Не создавайте хэши, когда массивы будут выполнять эту работу, не создавайте массивы, когда достаточно одной строки, и так далее. Будет важно профилировать ваше приложение, чтобы увидеть, какие объекты загромождают вашу кучу, прежде чем вы начнете случайным образом взламывать.

Если вы можете, попробуйте и используйте 1.9.2, который значительно улучшил управление памятью. Ruby Enterprise Edition также является опцией, если вам нужна совместимость с 1.8.7, так как это, по сути, лучший сборщик мусора для этой версии.

Answer 2

Насколько сложно будет запустить ваше приложение на Linux?Если у вас нет таких проблем с памятью, вероятно, это что-то особенное в вашей среде исполнения ruby.Если у вас возникли те же проблемы, вы можете использовать все инструменты и библиотеки, которые есть только в Linux.

Другая альтернатива - можете ли вы обернуть свои модульные тесты некоторым кодом отслеживания памяти?Большинство структур модульных тестов позволяют легко добавлять код перед / после каждого теста.Или вы можете просто запустить каждый тест 1000000000 раз и посмотреть, выйдет ли память из-под контроля?если это произойдет, вы знаете, что что-то, что происходит в этом тесте, вызывает утечку, и вы можете продолжать устранять проблему.

Answer 3

Вы пытались подсчитать количество имеющихся у вас объектов, используя ObjectSpace.each_object ?Хотя вы собираетесь использовать небольшие партии, возможно, у вас есть только больше объектов, чем вы думаете.

count = ObjectSpace.each_object() {}
# => 7216