Comments 13
Не по теме статьи, но все же — кто как юзает кассандру? Мне она показалась жутко тормозной (по сравнению даже с мускулем, не говоря уж о монге), а на больших объемах она начинает выкидывать timeout exception, хоть и декларирует 100% успешность записи. Да и на запись она быстрее чтения не потому что запись быстрая, а потому что чтение аддски медленное, при этом жрет очень много памяти, потому что Java.
Неужели кто-то смог найти ей реальное применение?
Неужели кто-то смог найти ей реальное применение?
Список пользователей Cassandra — известных компаний planetcassandra.org/companies/. После обновления до Jelastic 2 мы постараемся написать статьи в infoboxcloud.ru/community и на Хабр по эффективному использованию Cassandra.
Вы ей памяти нормально дали, в соответствии с рекомендациями? На задаче, где мы её использовали всё уперлось в диски: 500-600 МБ/с был предел RAID0 из SSD.
Кстати Jelastic позволяет динамически выделять ресурсы в зависимости от нагрузки (и конечно можно ограничить лимиты сверху и снизу). В моменты простоя система масштабируется к минимальному потреблению ресурсов, экономя деньги. Если упретесь в ограничения по ресурсам на Jelastic — напишите в поддержку или лично мне trukhinyuri@infoboxcloud.ru и расширим доступные ресурсы для вашего аккаунта.
Накинуть памяти — первое что сделал, а какой объем она у вас записывает? Потому что касси тоже стала упираться в диск, а вот монга работает себе спокойно, кушая раз в 5 меньше памяти (хотя выделено ей те же 10 гигов, что и касси), и не нагружая настолько диск (из-за отложенной записи и многих других причин)
В нашем случае сначала было по 12-16G, потом подкрутили до 8G. На 8G работало прекрасно, на 12-16G была серьезная деградация производительности, регулярно ловили таймауты. Памяти на серверах было больше 24G.
10G может быть слишком много.
Объем записи и скорости у нас были небольшие (как мне кажется, 40-50G и не больше 50 Мбит/с на ноду).
Рекомендации здесь: www.datastax.com/documentation/cassandra/1.2/cassandra/operations/ops_tune_jvm_c.html?scroll=concept_ds_sv5_k4w_dk
Ещё есть прекрасная табличка тут: www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningAntiPatterns_c.html
10G может быть слишком много.
Объем записи и скорости у нас были небольшие (как мне кажется, 40-50G и не больше 50 Мбит/с на ноду).
Рекомендации здесь: www.datastax.com/documentation/cassandra/1.2/cassandra/operations/ops_tune_jvm_c.html?scroll=concept_ds_sv5_k4w_dk
Ещё есть прекрасная табличка тут: www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningAntiPatterns_c.html
Мне уже не актуально, передал ребятам, у которых рабочая касси, посмотрим как у них заработает. Но деградация производительности от увеличения размера кучи для меня сюрприз, хотя если бы читал исходники, не удивлялся бы так наверно.
Это для всех java приложений такое справедливо (большой размер кучи не всегда положительно сказывается на производительности), или только для кассандры? А то у меня еще один Java — сервер на ноде крутится, памяти пока гиг кушает, но в будущем вполне может стать прожорливей.
Это для всех java приложений такое справедливо (большой размер кучи не всегда положительно сказывается на производительности), или только для кассандры? А то у меня еще один Java — сервер на ноде крутится, памяти пока гиг кушает, но в будущем вполне может стать прожорливей.
Вообще о тюнинге GC пишут много и он очень сильно различается при большой и маленькой куче. Почитайте, например, статьи Алексея Рагозина. На хабре тоже что-то было по тюнингу JVM.
И большая куча (имеются ввиду значения больше 4-8G) в среднем может ухудшать отзывчивость приложения за счет бОльших пауз GC. Но всё, как всегда, сильно зависит от того какие паттерны создания и уничтожения объектов (распределения размеров, времени жизни и т. п.). Чем ближе приложение к модели мира generational GC, тем лучше будут работать GC такого типа: небольшие короткоживущие объекты, например, не должны попадать в OldGen, Eden/S1/S2 должны быть адекватного (поведению конкретной программы) размера и т. п. Есть ещё azul, обещающий мир без stop-the-world пауз, но мы его так и не попробовали.
Может malexejev что-нибудь дополнит, если захочет, конечно.
И большая куча (имеются ввиду значения больше 4-8G) в среднем может ухудшать отзывчивость приложения за счет бОльших пауз GC. Но всё, как всегда, сильно зависит от того какие паттерны создания и уничтожения объектов (распределения размеров, времени жизни и т. п.). Чем ближе приложение к модели мира generational GC, тем лучше будут работать GC такого типа: небольшие короткоживущие объекты, например, не должны попадать в OldGen, Eden/S1/S2 должны быть адекватного (поведению конкретной программы) размера и т. п. Есть ещё azul, обещающий мир без stop-the-world пауз, но мы его так и не попробовали.
Может malexejev что-нибудь дополнит, если захочет, конечно.
Планируете добавить поддержку Ruby (Rails)?
Уже есть бета-версия поддержки Ruby на нашей платформе (можно использовать). В Jelastic 2 поддержка Ruby станет релизом.
Хотелось бы попробовать, как это можно сделать? А когда зарелизится Jelastic 2?
Уже. На днях напишем анонс в infoboxcloud.ru/community и на Хабр. Работаем над поддержкой Python, node.js и .net infobox.ru/hosting/cloud/
Sign up to leave a comment.
Нет привязке к вендору! Поддержка OpenShift Cartridge Standard появится на платформе InfoboxCloud Jelastic