По кешированию.
Насколько я понял по картинке, отдельной фермы кеширующих серверов нет, т.е. используются in-memory EhCache инстансы на серверах-шардах. Таким образом, кеши существуют в рамках отдельных шард и помещаются в память отдельной машины (не потому ли там столько памяти?).
Используете ли вы EhCache как кеш второго уровня Hibernate, или у вас собственный слой перед DAO-уровнем, где вы программно работаете с EhCache, или кеш включен как-то иначе?
В целом и короче говоря, было бы интересно узнать о деталях принятой у вас стратегии кеширования, а также верны ли мои предположения выше.
И все-таки я не понял момент с памятью.
Запустили вы JVM с -Xms1G -Xmx16G, приложение поработало с вечерней загрузкой, отъело у ОС 12 гигабайт, например. Затем наступила ночь и фактическое потребление упало обратно до 1 гига (то есть оно сначала упало, а потом когда-то там GC сделал очистку, после чего мы установились на 1 гигабайте хипа).
JVM-то операционке ничего не отдала, так каким образом вы сделали тарификацию по фактическому потреблению памяти? Предположу, что это как-то связано с cloudlet-ами, но одноименная страничка на сайте технического содержит мало. У меня есть смутное подозрение, что приложения работают внутри одной 16-гиговой JVM, но это, кхм, выходит shared-хостинг для явы.
Перезаписывание я тоже к ротации отношу, накопал даже свой вопрос на эту тему. Ответа так пока и не было )
В состав веблоджика в зависимости от редакции входит или JRocker JVM, или JRocker JVM RT. Несмотря на похожие названия, это два совсем разных продукта. Я, впрочем, не работал еще ни с тем ни с другим.
а карточки Tesla вообще используются в этих решениях? а то большинство статей, что я читал про работу с CUDA, говорили об использовании обычных видеокарт и слабом приросте в реальных задачах по сравнению с CPU.
> Если вы хотите, чтобы время печаталось не в относительных секундах от старта jvm, а по-человечески,
> можете воспользоваться парсером, который я написал на питоне.
Azul у меня активно тестируют коллеги на commodity x64 железе, пока говорят что штука интересная и на первый взгляд косяков нет. Еще из этой серии есть Oracle JRocket Real Time JVM — они тоже обещают гарантированные задержки при сборке мусора, причем постулируют полную совместимость с Sun JVM вплоть до багов. Опыта с этой JVM у меня нет, живых отзывов не слышал. Если есть с ней опыт — интересно будет пообщаться.
Вообще, статья приятно удивила. Когда открывал, думал или очередной копипаст, или откровения начинающего изучать яву.
В общем, у меня где-то такие же данные. Но Вы можете озвучить какие-то цифры, чтобы разговор был предметным?
Скажем, в виде Python / C / Java /… [Senior] Engineer — столько-то рублей NET, бонусы есть или нет. Можно личным сообщением, если что.
Насколько я понял по картинке, отдельной фермы кеширующих серверов нет, т.е. используются in-memory EhCache инстансы на серверах-шардах. Таким образом, кеши существуют в рамках отдельных шард и помещаются в память отдельной машины (не потому ли там столько памяти?).
Используете ли вы EhCache как кеш второго уровня Hibernate, или у вас собственный слой перед DAO-уровнем, где вы программно работаете с EhCache, или кеш включен как-то иначе?
В целом и короче говоря, было бы интересно узнать о деталях принятой у вас стратегии кеширования, а также верны ли мои предположения выше.
Запустили вы JVM с -Xms1G -Xmx16G, приложение поработало с вечерней загрузкой, отъело у ОС 12 гигабайт, например. Затем наступила ночь и фактическое потребление упало обратно до 1 гига (то есть оно сначала упало, а потом когда-то там GC сделал очистку, после чего мы установились на 1 гигабайте хипа).
JVM-то операционке ничего не отдала, так каким образом вы сделали тарификацию по фактическому потреблению памяти? Предположу, что это как-то связано с cloudlet-ами, но одноименная страничка на сайте технического содержит мало. У меня есть смутное подозрение, что приложения работают внутри одной 16-гиговой JVM, но это, кхм, выходит shared-хостинг для явы.
сколько выходит requests/second?
В состав веблоджика в зависимости от редакции входит или JRocker JVM, или JRocker JVM RT. Несмотря на похожие названия, это два совсем разных продукта. Я, впрочем, не работал еще ни с тем ни с другим.
> можете воспользоваться парсером, который я написал на питоне.
Начиная с 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 у меня нет, живых отзывов не слышал. Если есть с ней опыт — интересно будет пообщаться.
Вообще, статья приятно удивила. Когда открывал, думал или очередной копипаст, или откровения начинающего изучать яву.
Скажем, в виде Python / C / Java /… [Senior] Engineer — столько-то рублей NET, бонусы есть или нет. Можно личным сообщением, если что.
Насколько я слышал, она там вполне высоко-рыночная. Во всяком случае в области Java разработки.