Могу ли я использовать больше кучи, чем 32 ГБ, при сжатии

Ответ 1

У вас не может быть нескольких куч (у вас может быть несколько JVM, хотя это называется масштабированием, а не масштабированием).

JVM автоматически использует сжатые указатели объектов ниже 32 гигабайт памяти. Если вы понимаете, как это работает (снижая младшие три бита с каждого адреса, так как они всегда равны 0 из-за выравнивания памяти), вы поймете, что не можете идти дальше.

Есть интересный факт: если вы превысите эту границу 32 GiB, JVM перестанет использовать сжатые указатели объектов, эффективно уменьшая доступную память. Это означает, что вы увеличиваете свою кучу JVM выше 32 гигабайт, вы должны идти выше. В соответствии с большим Все, что я когда-либо узнал о настройке JVM Performance Tuning @twitter (около 13:00) увеличил кучу от 32 ГБ до чего-нибудь ниже 48 GiB фактически уменьшит количество доступной памяти (!), Поскольку сжатые указатели объектов больше не существуют.

Ответ 2

Если вам нужно больше 32 ГБ, я предлагаю вам использовать некоторые из памяти кучи. Это дает вам дополнительное пространство памяти, которое не использует много кучи.

Например, я обычно использую 200-800 ГБ, но только 1-2 ГБ - это куча. Это означает, что у меня есть наиболее эффективная форма сжатых Oops и практически неограниченная емкость. Примечание. Существуют три формы сжатого Oops,

• простая 32-разрядная неперемещенная (до ~ 2 ГБ)
• 32-битное смещение (до ~ 26 ГБ)
• 32-битное смещение и смещение (до ~ 32 ГБ)

Двумя способами использования памяти кучи являются прямая память ByteBuffers и файлы с отображением памяти. Прямой объем памяти составляет примерно 3/4 от объема вашей основной памяти. Файлы с отображением памяти хорошо масштабируются до размера вашего пространства на жестком диске (что обычно намного больше)

Здесь я применил много оптимизаций, так что в конце 80% пространства съедается ссылками, а не фактическими данными.

Похоже, вы не используете наиболее эффективные структуры данных. Вы можете использовать разные структуры данных, где данные больше используют пробелы или не менее 2/3rds.

Ответ 3

Вы можете использовать большие размеры кучи с дополнительным параметром: -XX:ObjectAlignmentInBytes=alignment

Этот параметр является фиксированной настройкой объектов Java. Значение по умолчанию - 8 (байты). Указанное значение должно быть двух, и находится в диапазоне от 8 до 256.

Предел размера кучи в байтах рассчитывается как:

4GB * ObjectAlignmentInBytes

Размер сжатых файлов объемом 64 ГБ будет доступен для сжатых указателей со следующей строкой:

-XX:ObjectAlignmentInBytes=16

В документации для более крупных размеров кучи есть примечание:

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

Ответ 4

Если бы я был на вашем месте, я бы изучил каждое из следующих событий:

• Не использовать сжатые сообщения.
• Сокращение потребления памяти приложения (профайлер памяти - чрезвычайно удобный инструмент для изучения использования памяти).
• Разделение рабочей нагрузки на несколько JVM, каждая с кучей под 32 ГБ.

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

80% пространства съедается ссылками, а не фактическими данными.

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

Ответ 5

Что такое характер данных?

Способ сделать это может состоять в том, чтобы хранить данные с кучи Java. Вы можете сделать это, захватив некоторую память из кучи, обычно используя direct ByteBuffer, а затем сохраняя в нем данные в форме байтов. Это имеет различные преимущества; объекты могут храниться очень компактно, вам не нужно иметь огромную кучу, и объекты не будут перемещаться сборщиком мусора. Недостатком является сложность и риск утечек памяти.

Есть библиотеки, которые могут вам помочь, в том числе:

• http://code.google.com/p/vanilla-java/wiki/HugeCollections
• http://directmemory.apache.org/