интересный подход. мы думали над подобным. в нашей реализации можно создать к примеру два окружения — test и prod. При удачном прохождении тестов удобно будет иметь возможность менять ролями окружения. Т.е. переключить роль test на prod, а prod на test.
> JVM-то операционке ничего не отдала
отдала, и если надо потом обратно возмет и еще раз отдаст. как-то был один человек, который на High-Load++ во время моей демонстрации кричал — это невозможно!!! я не зря сделал теги с топику «невозможное возможно».
На графиках показано потребление памяти операционной системой, это не heap JVM, а именно системная память.
> И нормального решения не нашлось
вот наша задача и дать хорошее решение, или хотя бы максимально упростить жизнь. Мы тоже натыкались на эти вопросы и не раз. Мы проводим «фундаментальные» исследования в этой области.
Горизонтальное решение тоже планируется, никуда от него не деться, нет одного универсального решения. Одним надо одно, другим другое.
другие инстанцы, которые автоматом поднимаются (балансировка нагрузки — LB) и кластеризация (высокая доступность — HA) это отличительные вещи. Чтобы обезопасить от 500 ошибок во втором релизе будет возможность поднять резервную ноду, выбрать HA топологию приложения.
супер! спасибо за вопросы, большинство из них попадет в FAQ.
> Правильно ли я понял вы говорите что у вас одно приложение работает целиком на одном хосте?
правильно. но это только один из возможных вариантов построения топологии приложения, самый простой.
> Как быть с тем что этот один хост упадет?
для этого надо выбрать HA топологию, с резервными нодами, естественно будет стоит дороже. Доступность в платформе таких топологий появится во втором релизе, через месяц.
> А как быть с GC и скоростью выделения памяти на 16Гб куче?
отличный вопрос. все хорошо с этим делом. пока не могу ответить полноценно. у нас есть секретный соус, но детально распишу после второго релиза. посмотрите на график, скорость роста очень резкая. Все юзеры пришли практически одновременно. Горизонтальное масштабирование может не справится с такими скоростями роста.
> Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
отличный вопросище! ответ — срочная евакуация, миграция на более свободные ресурсы.
> Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
никаких проблем, вы можете выставить свой требуемый PermGen. В добавок Hot redeploy мы не разрешаем, при редеплое сервер рестартует, дабы не было утечек. В связке с HA топологией рестарт нод идет последовательно.
Привет, Артем! А что нужно с ними решать? они себе работают как работали, это рост в пределах одной тачки, синхронизация не нужна. В этом преимущества вертикального vs горизонтальное. Ну соотв-но дешевле выходит для потребителя.
Вообще тема интереса с чисто технологической точки зрения, мы как-то в команде активно на эту тему рассуждали. Более того есть решения, которые виртуализируют ОС и проксируют логику на дополнительном кармане с памятью. Т.е. к примеру у вас сервер был на 8Гб, вы можете подключить комп-карман на 100Гб, но все равно это будет одна неделимая железка.
С другой стороны, какова реальная необходимость подобной задачи? я персонально не знаю ни одного такого неделимого java приложения, но отрицаю что они могут быть…
Почему не очень интересно? Смотря для каких задач, большинству проектов этого достаточно.
Опишите детальнее что означает в вашем понимании «неделимое». Лучше на примере. Порассуждаем…
1) а откуда взята такая информация? есть где подробно почитать про рассказанное вами?
2) в таком случае точно не стоит хранить какие либо статус состояния в памяти инстанса, кстати еще где-то читал что следующий запрос от одного пользователя может попадать совершенно в другой инстанс.
а чем плох способ догружать данные только по мере необходимости их на клиенте? ведь уровни вложенности могут быть глубокими, и заранее все подгружать не всегда эффективно.
обычный перехват события того, что данные не загружены. Можно и не ловить исключение, а просто проверить есть ли они ли нет другим образом — что само собой происходит перед выбросом LazyIniExc.
никакой проблемы не вижу, в чем конкретно проблема?
В одном из проектов на строне клиента с помощью cglib переопределил методы у проксирующих хибернейтовских классов (на подобии PersistCollection, PersistSet, ...) методы доступа к лейзи объектам, при выбросе исключения LazyIniExc производится автодозапрос с сервера недостающих данных и ложится в нужное место проксирующего класса. Т.о. работа на клиенте становится идентичной работе на сервере с открытой сессией, дозагрузка недостающих данных происходит только при обращению к ним на клиенте.
Если интересен код реализации, могу скинуть чз 2 дня как вернусь с командировки, пишу с телефона.
возможно ли заюзать подобное в сборе отельных данных для anthil ;) с учетом большого количества запросов. не проверял на том глючном сайте с яваскриптом?
на данный момент слово «облако» действительно используют где только можно, тем не менее есть уже устоявшиеся деления на группы о которых можно почитать в статье «API Облачных сервисов» habrahabr.ru/blogs/cloud_computing/109088/
Кстати спасибо за вопрос, очень правильный.
отдала, и если надо потом обратно возмет и еще раз отдаст. как-то был один человек, который на High-Load++ во время моей демонстрации кричал — это невозможно!!! я не зря сделал теги с топику «невозможное возможно».
На графиках показано потребление памяти операционной системой, это не heap JVM, а именно системная память.
вот наша задача и дать хорошее решение, или хотя бы максимально упростить жизнь. Мы тоже натыкались на эти вопросы и не раз. Мы проводим «фундаментальные» исследования в этой области.
Горизонтальное решение тоже планируется, никуда от него не деться, нет одного универсального решения. Одним надо одно, другим другое.
> Правильно ли я понял вы говорите что у вас одно приложение работает целиком на одном хосте?
правильно. но это только один из возможных вариантов построения топологии приложения, самый простой.
> Как быть с тем что этот один хост упадет?
для этого надо выбрать HA топологию, с резервными нодами, естественно будет стоит дороже. Доступность в платформе таких топологий появится во втором релизе, через месяц.
> А как быть с GC и скоростью выделения памяти на 16Гб куче?
отличный вопрос. все хорошо с этим делом. пока не могу ответить полноценно. у нас есть секретный соус, но детально распишу после второго релиза. посмотрите на график, скорость роста очень резкая. Все юзеры пришли практически одновременно. Горизонтальное масштабирование может не справится с такими скоростями роста.
> Как быть с тем что одно приложение может съесть всю память JVM и остальным не достанется?
отличный вопросище! ответ — срочная евакуация, миграция на более свободные ресурсы.
> Как насчет PermGen? Особенно если часто проиходит redeploy большого приложения?
никаких проблем, вы можете выставить свой требуемый PermGen. В добавок Hot redeploy мы не разрешаем, при редеплое сервер рестартует, дабы не было утечек. В связке с HA топологией рестарт нод идет последовательно.
С другой стороны, какова реальная необходимость подобной задачи? я персонально не знаю ни одного такого неделимого java приложения, но отрицаю что они могут быть…
Опишите детальнее что означает в вашем понимании «неделимое». Лучше на примере. Порассуждаем…
2) в таком случае точно не стоит хранить какие либо статус состояния в памяти инстанса, кстати еще где-то читал что следующий запрос от одного пользователя может попадать совершенно в другой инстанс.
а можно немного детальнее в этом месте?
никакой проблемы не вижу, в чем конкретно проблема?
Если интересен код реализации, могу скинуть чз 2 дня как вернусь с командировки, пишу с телефона.