Cassandra write benchmark, низкий (20%) Использование ЦП

Question

Я создаю Cassandra 3x m1.large кластер на Amazon EC2. Я использовал DataStax Auto-Clustering AMI 2.5.1-pv, с Cassandra DataStax Community версии 2.2.0-1.

При выполнении контрольных показателей записи, по данным «производства», кажется, что кластер может обрабатывать от 3 до 5 тыс. Запросов на запись в секунду без нагрузки на чтение. Почти все время узлы делают:

• уплотнению system.hints
• уплотнению mykeyspace.mybigtable
• компактирования mybigtable индекса

Однако то, что меня беспокоит, это низкая загрузка процессора , У всех трех узлов потребление ЦП составляет от 17% до 24%. Разве слишком мало использования ЦП? Разве это не ограничивает мою скорость записи? Это может быть на 100% для меня.

BTW. Как я могу проверить, что ограничивает (процессор, память, сеть, диски) мою производительность записи?

Вот некоторые статистические данные:

Edit:

• Я вставляя данные хорошо распределены вокруг кластера
• Я использую уровень консистенции One

Answer 1

Прежде всего, центральный процессор не 20%. В то время как процессорная система составляет 20%, пользовательский процессор составляет около 70%. Вот объяснение между процессором пользователя и системным процессором: User CPU time vs System CPU time?

Во-вторых, iostat, вызванный без аргументов, не самый лучший способ взглянуть на использование диска. От: Basic I/O Monitoring on Linux

Без указанного интервала, IOSTAT отображает статистику, так как система была вверх, затем выходит, что не является полезным в нашем случае.

Для более всестороннего взгляда на систему, используйте

dstat -rcdgilmnps 60 

Теперь мы ясно видим, средние от последней минуты. Простаивание процессора составляет 1-4%, у нас есть ~ 340 ios с 15-мегапиксельной скоростью записи.

Следующая полезным инструментом является nodetool cfstats:

Где мы можем увидеть некоторые статистические данные для конкретной таблицы. Статистика записи задержек особенно интересна и равна 1,5 мс.

Наконец, выполнение трассировки для записи:

id: 12345 -> host NodeAsked:9042, achieved consistency: LocalOne 
Sending MUTATION message to /NodeA on NodeAsked[MessagingService-Outgoing-/NodeA] at 0 
Sending MUTATION message to /NodeB on NodeAsked[MessagingService-Outgoing-/NodeB] at 0 
REQUEST_RESPONSE message received from /NodeA on NodeAsked[MessagingService-Incoming-/NodeA] at 0 
Processing response from /NodeA on NodeAsked[SharedPool-Worker-32] at 0 
MUTATION message received from /NodeAsked on NodeA[MessagingService-Incoming-/NodeAsked] at 12 
Determining replicas for mutation on NodeAsked[SharedPool-Worker-45] at 114 
Appending to commitlog on NodeAsked[SharedPool-Worker-45] at 183 
Adding to mytable memtable on NodeAsked[SharedPool-Worker-45] at 241 
Appending to commitlog on NodeA[SharedPool-Worker-5] at 5360 
Adding to mytable memtable on NodeA[SharedPool-Worker-5] at 5437 
Enqueuing response to /NodeAsked on NodeA[SharedPool-Worker-5] at 5527 
Sending REQUEST_RESPONSE message to /NodeAsked on NodeA[MessagingService-Outgoing-/NodeAsked] at 5739 

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

Голосовать, если вы согласны.

Answer 2

Это вопрос последовательности. Когда вы вставляете данные, а уровень согласованности - это кворум в вашем случае, драйвер ждет, пока все узлы не ответят, что данные доступны при вставке, выполните согласованность одного, что даст вам лучшую производительность. Что касается характеристик уплотнения, см. Следующую статью: http://www.datastax.com/dev/blog/ec2-series-doc

Другой причиной, по которой ваши записи плохо работают, может быть дизайн стола. Если вы не установите правильные ключи разделов (в зависимости от ваших данных), вы можете получить длинные строки, которые в большинстве случаев занимают больше времени при уплотнении. Если вы хотите, вы можете предоставить свою модель таблицы (схему) и образец своих данных, чтобы этот вопрос можно было ответить более подробно.

Также имейте в виду, что C * был разработан для работы на товарном оборудовании. Он редко использует системные ресурсы в полной мере, то есть доступной мощности процессора. Однако Кассандра может - при чтении - использовать столько памяти, сколько вы ее кормите! Что касается пропускной способности записи, есть инструмент под названием CCM (https://github.com/pcmanus/ccm), который может сравниться с вашей установкой ...

Answer 3

Является ли приложение, используемое вами для сравнения доступным (с открытым исходным кодом) в любом месте? Это шанс, если ваше приложение делает что-то вроде последовательной отправки запросов о том, что ваша пропускная способность может быть затруднена при латентности (закон ограниченности) в реальных пределах вашего кластера. ЦП должен быть ограничивающим фактором в производительности записи, поэтому 20% имеют однопоточное приложение.

Theres инструмент cassandra-stress, который может имитировать большинство видов нагрузок, которые будут полностью использовать вашего клиента.