Управление сборкой мусора Java в режиме реального времени

Question

Мы используем систему RT в Java. Он часто использует относительно большие кучи (100 + ГБ) и обслуживает запросы, поступающие из очереди сообщений. Каждый запрос должен быть обработан быстро (< 100 мс) для удовлетворения SLA.

У нас возникли серьезные проблемы, связанные с GC, потому что часто бывает, что GC вызывает стоп-мировую коллекцию во время запроса (200 + мс), что приводит к сбою.

Один из наших разработчиков с разумным знанием GC провел некоторое время с настройкой параметров GC и попыткой использования разных GC. Через несколько дней он придумал некоторую параметризацию, которую мы в шутку называем «развитой генетическим алгоритмом». Это снижает паузы в GC, но по-прежнему далеки от удовлетворения требований SLA.

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

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

• Иногда называют Thread.sleep() в принимающем потоке, молясь за GC, чтобы сделать какую-то работу в Тем временем,
• Invoke System.gc() или Runtime.gc() между запросами, снова безнадежно молясь за него, чтобы помочь,
• Mess код полностью с Hacky узорами, как https://stackoverflow.com/a/6915221/1137187.

Последнее важное замечание, что мы стартап малобюджетный и коммерческие решения, такие как Zing® не вариант для нас, мы ищем некоммерческое решения.

Любые идеи? Мы полностью переписываем наш код на C++ (мы не знали, что GC может быть проблемой, а не решением в начале), но база кода слишком велика для этого.

Answer 1

Любые идеи?

Используйте другой JVM? Азул утверждает, что справляется с такими случаями. Redhat вносит свой вклад в openjdk с похожими целями, поэтому, возможно, вы можете попробовать экспериментальные сборки, если не хотите коммерческого решения.

Есть и другие JVM, ориентированные на приложения реального времени, но, как я понимаю, они фокусируются на более сложных требованиях реального времени к более мелким системам, а ваши звуки больше похожи на мягкие требования в реальном времени.

Еще одна вещь, которую вы можете попытаться, - значительно уменьшить выделение объектов (профилировать ваше приложение!), Используя предварительно выделенные объекты или более компактные представления данных, где это применимо. Снижение давления распределения при сохранении нового размера родов одинаково означает увеличение коэффициента смертности на каждый сбор, что должно ускорить работу молодых коллекций.

Выбор аппаратного обеспечения для максимальной пропускной способности памяти также может помочь.

Invoke System.gc() или Runtime.gc() между запросами, снова безнадежно молясь за него, чтобы помочь,

Это мощь работы в сочетании с -XX:+ExplicitGCInvokesConcurrent, в противном случае это вызовет однопоточная коллекция STW с CMS или G1 (я предполагаю, что вы используете один из них). Но этот подход кажется хрупким и требует много настроек и мониторинга.