Блог

Я изучаю варианты, которые помогут моему приложению, требующему много памяти, и при этом я наткнулся на BigMemory от Terracotta. Насколько я понимаю, они используют преимущества «собственной памяти», не собираемой без мусора, вне кучи, и, по-видимому, это примерно в 10 раз медленнее, чем хранилище кучи, из-за проблем с сериализацией / десериализацией. До прочтения о BigMemory я никогда не слышал о «встроенной памяти» за пределами обычного JNI. Хотя BigMemory — интересный вариант, который заслуживает дальнейшего рассмотрения, я заинтригован тем, чего можно было бы достичь с помощью встроенной памяти, если бы проблему сериализации можно было обойти.

Является ли встроенная память Java быстрее (я думаю, это влечет за собой ByteBuffer объекты?) чем традиционная память кучи, когда нет проблем с сериализацией (например, если я сравниваю ее с огромным byte[] )? Или выполнять капризы сборки мусора и т.д. сделать этот вопрос неопровержимым? Я знаю, что «измерить это» — это распространенный ответ здесь, но, боюсь, я бы не стал настраивать репрезентативный тест, поскольку я еще недостаточно знаю о том, как работает встроенная память в Java.

Прямая память быстрее при выполнении ввода-вывода, потому что она позволяет избежать одной копии данных. Однако для 95% приложений вы не заметите разницы.

Вы можете хранить данные в прямой памяти, однако это будет не быстрее, чем хранение данных POJOS. (или такой же безопасной, читаемой или поддерживаемой) Если вы беспокоитесь о GC, попробуйте создать свои объекты (должны быть изменяемыми) заранее и повторно использовать их, не отбрасывая. Если вы не удалите свои объекты, собирать будет нечего.

Является ли встроенная память Java быстрее (я думаю, это влечет за собой объекты ByteBuffer?) чем традиционная память кучи, когда нет проблем с сериализацией (например, если я сравниваю ее с огромным byte [])?

Прямая память может быть быстрее, чем использование байта [], если вы используете use non bytes like int , поскольку она может считывать / записывать целых четыре байта, не превращая данные в байты. Однако это медленнее, чем использование POJOs, поскольку оно должно проверять границы каждого доступа.

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

Скорость не имеет ничего общего с GC. GC имеет значение только при создании или отбрасывании объектов.

Кстати: Если вы сведете к минимуму количество объектов, которые вы отбрасываете, и увеличите размер Eden, вы можете предотвратить даже незначительный сбор данных в течение длительного времени, например, целого дня.

Смысл BigMemory не в том, что встроенная память быстрее, а скорее в том, чтобы уменьшить накладные расходы сборщика мусора, требующего усилий по отслеживанию ссылок на память и ее очистке. По мере увеличения размера вашей кучи увеличиваются и ваши интервалы GC и загрузка процессора. В зависимости от ситуации это может создать своего рода «стеклянный потолок», когда куча Java становится настолько большой, что GC превращается в «борова», потребляющего огромное количество процессорной мощности при каждом запуске GC. Кроме того, многие алгоритмы GC требуют определенного уровня блокировки, что означает, что никто ничего не может сделать, пока эта часть алгоритма отслеживания ссылок GC не завершится, хотя многие JVM намного лучше справляются с этим. Там, где я работаю, с нашим сервером приложений и JVM, мы обнаружили, что «стеклянный потолок» составляет около 1,5 ГБ. Если мы попытаемся настроить кучу больше, чем это, процедура GC начнет потреблять более 50% общего процессорного времени, так что это очень реальные затраты. Мы определили это с помощью различных форм GC-анализа, предоставляемых нашим поставщиком JVM.

BigMemory, с другой стороны, использует более ручной подход к управлению памятью. Это уменьшает накладные расходы и как бы возвращает нас к необходимости выполнять нашу собственную очистку памяти, как мы делали в C, хотя и в гораздо более простом подходе, похожем на HashMap. Это по существу устраняет необходимость в традиционной процедуре сборки мусора, и в результате мы устраняем эти накладные расходы. Я полагаю, что люди из Terracotta использовали встроенную память через ByteBuffer, поскольку это простой способ выйти из-под Java garbage collector.

Следующий технический документ содержит некоторую полезную информацию о том, как они спроектировали BigMemory, и некоторую информацию о накладных расходах GC: http://www.terracotta.org/resources/whitepapers/bigmemory-whitepaper.

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

Я думаю, что ваш вопрос основан на ложном предположении. AFAIK, невозможно обойти проблему сериализации, о которой они здесь говорят. Единственное, что вы могли бы сделать, это упростить объекты, которые вы помещаете в BigMemory, и использовать пользовательский код сериализации / десериализации, чтобы уменьшить накладные расходы.

Хотя тесты могут дать вам приблизительное представление о накладных расходах, фактические накладные расходы будут сильно зависеть от приложения. Мой совет был бы:

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

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

• Будьте готовы потратить некоторое время на (повторную) настройку вашего кода кэширования, чтобы получить хорошую производительность с BigMemory.

• Если ваши структуры данных сложны, ожидайте пропорционально больших затрат времени выполнения и усилий по настройке.