2012-05-09 4 views
2

У нас есть следующая статистика по одному кассандре на одном экземпляре Amazon EC2/Rightscale m1.large с двумя эфемерными дисками с raid0. (Общая память 7,6 ГБ)Cassandra Amazon EC2, много IOWait

4 ГБ ОЗУ выделяется кустарнику cassandra, 800 МБ - размер кучи NEW.

следующие статы от OpsCenter сообщества 2,0

запросы на чтение 285 до 340 в секунду
запросы на запись 257 до 720 в секунду
OS Load 15.15 до 17.15
Написать запрос Latency 293 до 685 MICROS
OS Отправленный сетевой трафик от 18 Мбайт до 30 МБ в секунду
Полученный сетевой трафик от 22 МБ до 34 МБ в секунду
Размер очереди диска ОС от 23 до 26
Rea д просит До 8 до 20
запрос на чтение Задержка 69140 до 92885 MICROS
ОС диска задержка 37 до 42 мс
ОС диска Пропускная способность от 12 до 14 Мб в секунду
Disk IOPs Считывает 600 до 740 в секунду
Disk IOPs Записывает от 2 до 7 в секунду

IOWait от 60 до 70% CPU сред

холостого хода от 24 до 30% процессора сред

Rowcache отключен.

Являются ли вышеуказанные характеристики удовлетворительными с предоставленной конфигурацией .... ИЛИ как мы могли бы настроить его больше, чтобы получить меньше IOWait .........., потому что мы думаем, что мы испытываем много IOWait. .... как мы можем настроить его, чтобы получить лучшее.

Запросы на чтение неоднозначны ......... некоторые из одного семейства суперколонок, а один стандарт имеет более миллиона ключей ...... и переменный номер. супер столбцов max 14 с переменным №. из подколонн от 1 до 10000 и переменный №. столбцов max 14 в стандартном семействе столбцов ............... Подколонки очень тонкие по своей природе с 0 байтами значения .... 8 байтов для имени.

Процесс удаляет данные из семейства суперсетей и записывает обработанные данные на стандартный.

Would EBS диски работают лучше .... на Amazon EC2

ответ

4

Я не уверен, можно ли настроить ваш конфиг легко получить больше производительности диска, но с помощью Snappy сжатия может помочь много в принятии вашего приложение должно читать меньше всего. Это may также поможет использовать новый составный ключевой макет вместо суперколонн.

Одно можно сказать точно: EBS будет NOT работать лучше. Держитесь подальше от этого любой ценой, если вы заботитесь о латентности.

+0

Поблагодарите Paul ....... хорошо мы используем cassandra больше как хранилище необработанных данных, работающее с байтами .... и мы используем суперколонны в виде добавленного списка/очереди, модифицированных несколькими клиентами асинхронно .... ... и блок данных (подколонка) в очереди настолько мал, как 8 байтов .... так что я не думаю, что компрессия может работать здесь ... и если бы составные клавиши или столбцы обеспечивали вышеуказанное поведение, потому что они представлены как предопределенная структура SQL ... которых у нас нет. – Asim

+0

У меня вопрос ..... можем ли мы прочитать список всех подколонков для нескольких суперколонн против ключа в одном запросе .... потому что это уменьшит количество запросов ........... и здесь rowcache поможет ........ потому что мы читаем комбинацию клавиш + суперколонны один раз в нашем процессе. – Asim

+0

@AsimAli Да, композитный макет ключа может обеспечить такое поведение, и даже CQL не требует. С помощью CQL проще работать, но вы можете создавать композиты и работать с ними, используя простой сбережения, если это лучше подходит для вашего существующего кода. –