Настройка метафизики TiDB — одно из наших безжалостных направлений.В начале многие параметры в TiKV доставляли мне головную боль долгое время (большинство параметров конфигурации TiKV связаны с RocksDB). К счастью, значения многих параметров по умолчанию очень научны, что значительно снижает сложность нашей метафизической настройки. Ниже приведен процесс обнаружения узкого места, когда я обычно тестирую TiDB...
Возьмем в качестве примера тест sysbench, используемый тестовый скрипт:GitHub.com/обычное порно/упомянутое…Доступны четыре общедоступных машины, конфигурация машины: ЦП 16 ядер / Память 110 ГБ / Диск 1024 ГБ SSD
тест производительности оборудования
Перед тестом выполните базовые аппаратные тесты, такие как тест дискового fio, тест сетевой задержки и тест скорости сети, эти тесты помогают устранить некоторые факторы помех. В этом месте представлены несколько методов тестирования, которые уже были протестированы ранее и не будут тестироваться здесь.
Тестовый диск: рекомендую fio (fio нужно использовать с осторожностью, не пишите напрямую на голое устройство, автор прописал несколько дисков подряд, все кровь и слезы), dd, sysbench...
// fio
fio -ioengine=libaio -bs=32k -direct=1 -thread -rw=read -size=10G -filename=test -name="PingCAP max throughput" -iodepth=4 -runtime=60
// dd
dd bs=4k count=250000 oflag=direct if=/dev/zero of=./dd_test.txt
// sysbench
sysbench --test=fileio --file-num=16 --file-block-size=16384 --file-total-size=2G prepare
sysbench --test=fileio --file-num=16 --file-block-size=16384 --file-total-size=2G --num-threads=4 --max-requests=100000000 --max-time=180 --file-test-mode=seqwr --file-extra-flags=direct run
sysbench --test=fileio --file-num=16 --file-block-size=16384 --file-total-size=2G --num-threads=4 --max-requests=100000000 --max-time=180 --file-test-mode=seqwr --file-extra-flags=direct clean
Тестовая задержка: пропингуйте напрямую, чтобы просмотреть задержку и потерю пакетов
Тест скорости сети: простейшие dd+scp, dd+pv+nc, iperf
// scp
dd if=/dev/zero bs=2M count=2048 of=./test // 生成 4 GB 文件
scp ./test ip ip
// dd + pv + nc
dd if=/dev/zero bs=1M count=1024 of=./test
pv test| nc 10.0.1.8 5433 // 发送
nc -vv -l -p 5433 > test // 接收
// iperf
iperf -s // server
iperf -c 10.0.1.4 // client
Расположение узкого места теста sysbench oltp
Запустите тест sysbench oltp, sysbench default oltp одна транзакция содержит 18 SQL:
10 * point select
1 * simple range select
1 * sum range
1 * order range
1 * distinct range
1 * index update
1 * non index update
1 * insert
1 * delete
С точки зрения комбинации транзакций, это составляет большую часть степени.Опыт говорит нам, что первое чтение - это в основном операции с интенсивным использованием ЦП, и ЦП TiDB, скорее всего, станет узким местом.Сначала мы используем архитектуру 1 TiDB + 3 TiKV для проверки и наблюдения за работой.
использоватьtidb-ansibleРазвернуть кластер
Топология развертывания:
| ip | развертывать |
|---|---|
| 10.0.1.6 | tidb / pd / sysbench |
| 10.0.1.7 | tikv |
| 10.0.1.8 | tikv |
| 10.0.1.9 | tikv |
Процесс тестирования: подготовка -> запуск
Запустите тестовый скрипт, сначала наблюдайте за использованием процессора tidb / tikv (как правило, в oltp-тестах основное узкое место будет сосредоточено на процессоре tidb, и мы должны сосредоточиться на устранении неполадок)
Видно, что загрузка tidb машины достигла 20+. Это 15-ядерная машина. Такое ощущение, что процессор этой машины почти слился. Нам не нужно смотреть на другие узкие места. CPU Общая производительность была ограничена. Итак, что нам нужно сделать дальше, это устранить это узкое место,Самый прямой способ - обновить оборудование или добавить машины.Мы пытаемся увеличить количество машин, и в то же время обращаем внимание на повышение давления.. (Для проведения эксперимента лишней машины нет) Когда мы увеличим количество машин tidb до 3 и более, мы обнаружим, что узкое место сместилось, и узкое место будет перенесено из tidb. Переведенный в tikv, tikv имеет end-point-concurrency, например, для обработки запросов tidb, мы используем top -H для наблюдения
Соответствующий мониторинг графана
Когда параллелизм конечных точек считается узким местом? Конечная точка-параллелизм по умолчанию использует 4 потока, тогда мы можем думать, что когда top -H обнаруживает, что использование процессора этими четырьмя потоками превышает 90%, тогда можно считать, что конечная точка- параллелизм ограничен.Пропускная способность всей системы, следующее, что нам нужно сделать, это как устранить это узкое место.Если общее использование процессора машины tikv все еще очень простаивает, то мыУвеличьте количество потоков для этого параллелизма конечных точек., это будет изменено Параметры запуска tikv, это можно посмотреть в документе:GitHub.com/обычное порно/doc…. (Поток grpc также является узким местом. Метод улучшения аналогичен параллелизму конечных точек, напрямую увеличивая количество потоков)
Когда мы решим конечную точку-конкурентность, мы обнаружим, что общая пропускная способность системы улучшится, но в это время появится новое узкое место.По моему обычному опыту, следующее узкое место должно появиться в конце. нить точечной работы, почему она появляется в этой теме? На самом деле, если вы знаете, для чего используется этот поток, это будет легко понять. Этот сайт используется для планирования параллелизма конечных точек. узкое место в планировании, к сожалению. Дело в том, что конечная точка-работа однопоточная, мы должны решить это узкое место,Можно только увеличить мощность одноядерного процессора или увеличить количество tikv.
Summary
- узкое место
- ЦП TiDB, как правило, будет первым узким местом
- Поток конечной точки TiKV
- поток grpc
- Рабочий поток конечной точки TiKV
- оптимизация
- Чтобы добавить узел TiDB, вы можете попробовать добавить его на машину TiKV (достаточно процессора TiKV)
- Настройте параметр end-point-concurrency, чтобы увеличить количество потоков конечных точек.
- Настройте параметр grpc-concurrency, чтобы увеличить количество потоков grpc.
- Увеличьте кеш вacksdb
Позиционирование узкого места производительности sysbench oltp как раз об этом и говорит.В реальных ситуациях узкое место tidb не статично.Его нужно оптимизировать и подгонять под реальную ситуацию,иначе метафизикой это не назовешь 😄.
sysbench вставить тестовое место узкого места
Скрипт вставки в sysbench очень прост, он написан последовательно, поэтому давайте сначала рассмотрим основные понятия tikv.Наименьшие единицы в tikv — это регионы, и каждая таблица должна соответствовать этому отдельному региону, поэтому добавление нашего теста — единственно правильное. вставлять, сколько бы у нас ни было tikv, бесполезно (для этой задачи в настоящее время есть соответствующее решение, и я не очень в этом разбираюсь.) Поэтому мы тестируем, чтобы убедиться, что количество таблиц должно быть больше, чем количество узлов tikv (Конечно, чем больше, тем лучше), здесь я использовал в эксперименте 16 таблиц, и каждая таблица заранее подготовила 100w данных.
Запустив скрипт вставки, я также увижу загрузку процессора tidb / tikv / pd. Мы легко обнаружим, что наш ЦП TiDB не станет узким местом первым (не совсем) при вставке, но мы обнаружим, что давление TiKV все еще очень велико, нам нужно найти узкое место TiKV, если давление TiKV также очень маленький, тогда мы должны увидеть, есть ли проблема с дисковым вводом-выводом, проверить дисковый ввод-вывод, обычно я использую iostat для проверки ситуации с диском
Мы видим, что %util диска sde находится на уровне 70, что означает, что он очень загружен, но еще не достиг узкого места.Обычно, если он превышает 90 или более, можно считать, что этот диск был почти зажаты нами.
Плавание, подробный процесс позиционирования вставного теста будет написан в отдельной статье позже
Summary
- узкое место
- Резьба для плота ТиКВ
- Дисковый ввод-вывод, остановка или много ожидания ввода-вывода
- оптимизация
- Если диск не достигает узкого места, ЦП машины TiKV все еще очень богат, и на одной машине можно выполнить несколько развертываний.Обычно один экземпляр TiKV соответствует одному диску.
- Если есть узкое место в дисковом вводе-выводе, вы можете настроить метод сжатия и обменять ресурсы ЦП на ресурсы ввода-вывода.
- Обнаружено, что давление ввода-вывода в системе невелико, но ресурсы ЦП исчерпаны. Top -H обнаруживает, что выполняется большое количество потоков, начинающихся с bg (потоки уплотнения RocksDB). В это время вы можете рассмотреть уменьшение сжатия и использование ресурсов ввода-вывода в обмен на ресурсы ЦП
Небольшой намек
- Рекомендуется Sysbench версии 1.0 и выше.
- При количестве узлов TiKV в кластере больше 3, после завершения подготовки данных, необходимо дождаться равномерного распределения * количества лидеров и регионов на узлах TiKV После проведения различных бенчмарк-тестов можно использовать pd-ctl илиhttp://hosts:port/pd/api/v1/storesИли Grafana может отслеживать и просматривать распределение лидеров и регионов на каждом узле TiKV.
- При выполнении нескольких раундов тестирования, когда данные необходимо очистить, не выполняйте операцию DROP, вы можете использовать Ansible для физического удаления, а затем перезапустить кластер и повторно подготовить данные для тестирования.
- Когда TiDB и TiKV не достигли узкого места, количество потоков Sysbench можно непрерывно увеличивать.
Последнее слово
Это всего лишь небольшой пример.В процессе реального тестирования производительности всегда будут возникать различные ситуации, и возникающие узкие места не являются статичными.Моя так называемая метафизика - это не случайная настройка без основы, а анализ и проверить реальную ситуацию, а также собственное понимание системы TiDB и внести разумные коррективы в топологию развертывания и параметры конфигурации. Конечно, если вы заинтересованы в оптимизации программ TiDB/TiKV/PD, мы также можем использовать стресс-тест + мониторинг Grafan + Perf +FlameGraphНайдите узкие места внутри программы.
Ссылаться на
- Если вы хотите оптимизировать производительность, вы должны сначала заточить свои инструменты (1)
- Если вы хотите оптимизировать производительность, вы должны сначала заточить свои инструменты (2) - график пламени
- Три статьи, чтобы разобраться в технологии TiDB изнутри — поговорим о СХД
- Небольшая уборка sysbench
- Настройка параметров производительности TiKV