Comments 21
Для понимани, что речь идёт о Java пришлось прочитать полстатьи.
-8
Так ведь название блога написано в h2 до текста статьи)
0
Просто Огромное спасибо Вам! Рабочий день начался хоть и поздно, но с хорошей статьи.
Очень пригодится в ближайшем будущем!
Очень пригодится в ближайшем будущем!
0
Оказывается, Java не решила проблемы управления памятью. Она просто сменила одну сложность на другую…
-1
К чему все эти сложности, есть же -XX:DisableGC, и никаких пауз в работе приложения?
+2
Только как Вы собираетесь справляться с заполняемой со временем памятью?
Или же просто чистить ее ручными вызовами GC отдельно?
Или же просто чистить ее ручными вызовами GC отдельно?
+1
Спасибо за статью, давно искал данную информацию в одном месте и структурированно, а то повсюду это только урывками упоминается/описывается.
0
> Если вы хотите, чтобы время печаталось не в относительных секундах от старта jvm, а по-человечески,
> можете воспользоваться парсером, который я написал на питоне.
Начиная с 1.6.06 доступно -XX:+PrintGCDateStamps, которое делает это из коробки (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301). Сейчас у Sun JVM в плане логов GC нет только ротации, все остальное они вроде допилили.
Azul у меня активно тестируют коллеги на commodity x64 железе, пока говорят что штука интересная и на первый взгляд косяков нет. Еще из этой серии есть Oracle JRocket Real Time JVM — они тоже обещают гарантированные задержки при сборке мусора, причем постулируют полную совместимость с Sun JVM вплоть до багов. Опыта с этой JVM у меня нет, живых отзывов не слышал. Если есть с ней опыт — интересно будет пообщаться.
Вообще, статья приятно удивила. Когда открывал, думал или очередной копипаст, или откровения начинающего изучать яву.
> можете воспользоваться парсером, который я написал на питоне.
Начиная с 1.6.06 доступно -XX:+PrintGCDateStamps, которое делает это из коробки (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6517301). Сейчас у Sun JVM в плане логов GC нет только ротации, все остальное они вроде допилили.
Azul у меня активно тестируют коллеги на commodity x64 железе, пока говорят что штука интересная и на первый взгляд косяков нет. Еще из этой серии есть Oracle JRocket Real Time JVM — они тоже обещают гарантированные задержки при сборке мусора, причем постулируют полную совместимость с Sun JVM вплоть до багов. Опыта с этой JVM у меня нет, живых отзывов не слышал. Если есть с ней опыт — интересно будет пообщаться.
Вообще, статья приятно удивила. Когда открывал, думал или очередной копипаст, или откровения начинающего изучать яву.
+1
Спасибо большое за комментарий, а то я уже расстроился, что ни одного нормального коммента нет.
Блин, опять я велосипед изобретал. -XX:+PrintGCDateStamps, конечно вещь, проставлю в ближайшем патче. Про то, что есть все кроме ротации — не согласен. Как минимум еще не хватает опции, дописывать в файл, а не перезаписывать его. А еще бы хотелось иметь возможность в UTC время писать, как мы делаем во всех остальных логах.
По поводу Azul. На работе ребят в соседнем проекте тоже жутко заинтересовал Azul, но на commodity hardware у нас в банке в продакшен выйти нет возможности. А для intel/amd x86-64 architectures, на самом деле есть только вариант с виртуальным боксе, у нас ребята им специально звонили выясняли подробности. Но виртуалки особо не перформят, я слышал, особенно когда касается обращения к памяти, так что ждем пока они на стандартное железо напрямую со своим решением выйдут. На счет совместимости вплоть до багов не уверен, но вроде JVM у них вся из себя сертифицирована.
Про Oracle JRocket Real Time JVM, к сожалению, ничего не могу сказать. Помнится работал я в одном проекте, где использовался WebLogic и, соответвстсвенно, JRocket. Ни на какие косяки не напарывались, но GC не меряли. Может потому-что там как раз все тип-топ с этим было? Хотя возможно вы имеете какое-то другое именно Real Time решение JRocket.
Блин, опять я велосипед изобретал. -XX:+PrintGCDateStamps, конечно вещь, проставлю в ближайшем патче. Про то, что есть все кроме ротации — не согласен. Как минимум еще не хватает опции, дописывать в файл, а не перезаписывать его. А еще бы хотелось иметь возможность в UTC время писать, как мы делаем во всех остальных логах.
По поводу Azul. На работе ребят в соседнем проекте тоже жутко заинтересовал Azul, но на commodity hardware у нас в банке в продакшен выйти нет возможности. А для intel/amd x86-64 architectures, на самом деле есть только вариант с виртуальным боксе, у нас ребята им специально звонили выясняли подробности. Но виртуалки особо не перформят, я слышал, особенно когда касается обращения к памяти, так что ждем пока они на стандартное железо напрямую со своим решением выйдут. На счет совместимости вплоть до багов не уверен, но вроде JVM у них вся из себя сертифицирована.
Про Oracle JRocket Real Time JVM, к сожалению, ничего не могу сказать. Помнится работал я в одном проекте, где использовался WebLogic и, соответвстсвенно, JRocket. Ни на какие косяки не напарывались, но GC не меряли. Может потому-что там как раз все тип-топ с этим было? Хотя возможно вы имеете какое-то другое именно Real Time решение JRocket.
0
Перезаписывание я тоже к ротации отношу, накопал даже свой вопрос на эту тему. Ответа так пока и не было )
В состав веблоджика в зависимости от редакции входит или JRocker JVM, или JRocker JVM RT. Несмотря на похожие названия, это два совсем разных продукта. Я, впрочем, не работал еще ни с тем ни с другим.
В состав веблоджика в зависимости от редакции входит или JRocker JVM, или JRocker JVM RT. Несмотря на похожие названия, это два совсем разных продукта. Я, впрочем, не работал еще ни с тем ни с другим.
+1
Sign up to leave a comment.
Как бороться с паузами GC