Как проанализировать фрагментацию памяти в Java?
5 ответов
"Обратите внимание, что C1 и C2 не обязательно будет по 50% каждая. В значение может меняться в зависимости от их содержание. Мне также нужны все предметы в эти ячейки независимо от количества строк должны выстроиться так же, как они будет в таблице. "
Вышеупомянутое невозможно в кроссбраузерном режиме без использования таблицы (вы можете смоделировать макет таблицы с помощью CSS:" display: table ", но это не работает в IE6 или IE7) .
Я бы посоветовал вам думать немного по-другому при проектировании с использованием CSS вместо таблиц, невозможно просто заменить «tr» и «td» на «div» и заставить все волшебным образом работать, как раньше. Я предлагаю вам установите ширину нижних «ячеек» и используйте один из вариантов, которые вам дали выше.
Надеюсь, что это поможет!
Это скажет вам, собираете ли вы старое или новое поколение, и сколько времени занимает сбор.Пауза в «несколько минут» звучит необычно. Вы уверены, что работаете не просто со слишком маленьким размером кучи или на машине с недостаточным объемом физической памяти?
Если ваша куча слишком близка к заполнению, GC будет запущен снова и снова, в результате ваш сервер тратя большую часть своего процессорного времени на GC. Это будет отображаться в GC журналы.
Если вы используете большую кучу на машине с нехваткой физической памяти, полный сборщик мусора может вызвать твою машину «лупить», тратя большую часть времени безумно движущийся виртуальный страницы памяти на диск и с диска. Вы это можно наблюдать с помощью системы инструменты мониторинга; например, наблюдая вывод консоли из "vmstat 5" на типичная система UNIX / Linux.
FOLLOWUP
Вопреки мнению OP, включение журнала GC вряд ли существенно повлияет на производительность.
Понимание Concurrent Mark Страница Sweep Garbage Collector Logs на сайте Oracle должна быть полезной при интерпретации журналов GC.
Наконец, заключение OP о том, что это проблема «фрагментации», маловероятно и (IMO) не подтверждается фрагментами свидетельств того, что он предоставил. Скорее всего, это что-то другое.
Я использовал YourKit для хорошего эффекта для этого типа проблем.
В Java нет фрагментации памяти; во время выполнения GC области памяти уплотняются.
Поскольку вы не видите высокой загрузки ЦП, GC тоже не работает. Значит, причиной ваших проблем должно быть что-то еще. Вот несколько идей:
Если база данных вашего приложения находится на другом сервере, могут быть проблемы с сетью
Если вы работаете в Windows и подключили сетевые диски, один из дисков может заблокировать ваш компьютер ( опять проблемы с сетью). То же самое и с дисками NFS в Unix. Проверьте системный журнал на наличие сетевых ошибок.
Не загружает ли компьютер много данных на диск? Поскольку загрузка ЦП низкая, причиной проблемы могло быть то, что приложение было выгружено на диск, а запуск GC принудительно вернул его в ОЗУ. Это займет много времени, если ваш сервер не t достаточно реальной оперативной памяти, чтобы сохранить все приложение Java в ОЗУ.
Кроме того, другие процессы могут вынудить приложение из ОЗУ. Проверьте реальное использование памяти и использование пространства подкачки.
Чтобы понять вывод журнала GC, может помочь этот пост .
[РЕДАКТИРОВАТЬ] Я все еще не могу разобраться в "низком уровне ЦП" и "остановках сборщика мусора". Эти двое обычно противоречат друг другу. Если сборщик мусора останавливается, вы должны увидеть 100% загрузку ЦП. Если ЦП простаивает, то сборщик мусора блокируется чем-то еще. У вас есть объекты, которые перегружают finalize () ? Если финализация блокируется, сборщик мусора может занять вечность.
Виталий, есть проблема фрагментации. Мое наблюдение: Если есть объекты небольшого размера, которые часто обновляются, то в этом случае создается много мусора. Хотя CMS собирает память, занимаемую этими объектами, эта память фрагментирована. Теперь появляется поток Mark-Sweep-Compact (остановите мир) и пытается сжать эту фрагментированную память, вызывая долгую паузу.
Напротив, если размер объектов больше, он генерирует менее фрагментированную память и
Mark-Swap-Compact требует меньше времени для сжатия этой памяти. Это может снизить пропускную способность, но поможет сократить длительную паузу, вызванную уплотнением GC.
Чтобы узнать, как Виталий, вероятно, справился с этим, см. Общие сведения о журналах сборщика мусора одновременной очистки меток .