Запуск 4-узлового кластера cassandra версии 2.0.9. В последнее время, начиная с месяца, мы наблюдаем огромный всплеск использования ЦП на всех узлах.
tpstats дает мне высокие Native-transport-requests. Прикрепляю скриншот для 3 узлов tpstats
Узел 1 
Узел 2 
Узел 3 
С чего начать отладку?
Также, если вы видите на первом рисунке, когда нагрузка становится высокой, чтение и запись становятся низкими. Это понятно, так как большинство запросов отбрасываются.
Как смягчить надгробия? Вероятно, я получаю этот вопрос от наших команд разработчиков дюжину раз в месяц. Самый простой способ — не выполнять DELETE, и я серьезно отношусь к этому. В противном случае вы можете смоделировать свои таблицы таким образом, чтобы лучше смягчить захоронения.
Например, допустим, у меня есть простая таблица для отслеживания статуса заказа. Поскольку заказ может иметь несколько разных статусов (ожидание, комплектация, отправлено, получено, возвращено и т. д.), ленивый способ состоит в том, чтобы иметь одну строку для каждого заказа и либо УДАЛИТЬ, либо запустить обновление на месте, чтобы изменить статус ( в зависимости от того, является ли статус частью вашего ключа). Лучший способ — преобразовать его во временной ряд и выполнить удаление через TTL. Таблица будет выглядеть примерно так:
CREATE TABLE orderStatus (orderid UUID,
updateTime TIMEUUID,
status TEXT,
PRIMARY KEY (ordered, status))
with CLUSTERING ORDER BY (updateTime DESC);
Допустим, я знаю, что меня действительно интересует только статус заказа в течение максимум 30 дней, поэтому все обновления статуса имеют TTL 30 дней...
INSERT INTO orderStatus (orderid,updateTime,status)
VALUES (UUID(),now(),'pending') USING TTL 2592000;
Эта таблица будет поддерживать запросы статуса заказа по orderid, отсортированные по убыванию времени обновления. Таким образом, я могу ВЫБРАТЬ из этой таблицы идентификатор с LIMIT 1 и всегда получать самый последний статус. Кроме того, эти статусы будут автоматически удалены через 30 дней. Теперь данные TTL по-прежнему создают надгробия. Но эти надгробия отделены от более новых порядков (тех, которые меня, вероятно, больше интересуют), поэтому мне обычно не приходится беспокоиться о том, что эти надгробия будут мешать моим запросам (поскольку все они сгруппированы в разделы, которые я не буду использовать). часто спрашиваешь).
Это только один пример, но я надеюсь, что идея моделирования защиты от надгробий ясна. В основном идея состоит в том, чтобы разделить вашу таблицу таким образом, чтобы захоронения хранились отдельно от данных, которые вы чаще всего запрашиваете.
Есть ли способ, с помощью которого мы можем отслеживать, какие запросы выполняются медленно на сервере?
Нет, на самом деле нет способа сделать это. Но вы должны иметь возможность запрашивать все запросы от ваших разработчиков для проблемных пространств ключей/таблиц. И это должно быть легко, потому что таблица действительно должна поддерживать только один или два запроса. Если ваши разработчики построили таблицу, которая поддерживает 5 или 6 различных запросов, они делают это неправильно.
Когда вы смотрите на запросы, вот несколько красных флажков, которые вы должны задать:
