Тестирование производительности

• 1: Тестирование использования памяти хранилищем
• 2: Тестирование использования памяти наблюдателями
• 3: Тестирование производительности etcd v3
• 4: Тестирование памяти etcd v2.2.0-rc
• 5: Тестирование производительности etcd v2.2.0-rc
• 6: Тестирование производительности etcd v2.2.0
• 7: Тестирование производительности etcd v2.1.0

1 - Тестирование использования памяти хранилищем

Физическую память потребляют два компонента хранилища etcd. Для ускорения поиска ключей процесс etcd выделяет индекс в памяти. Управляемый операционной системой страничный кеш процесса хранит недавно прочитанные с диска данные для быстрого повторного использования.

Индекс в памяти хранит все ключи в структуре данных B-tree вместе с указателями на данные на диске — значения. Каждый ключ в B-tree может содержать несколько указателей на разные версии значения. Поэтому теоретическое потребление памяти индексом можно приблизительно оценить формулой:

N * (c1 + avg_key_size) + N * (avg_versions_of_key) * (c2 + size_of_pointer)

где c1 — накладные расходы метаданных ключа, а c2 — накладные расходы метаданных версии.

На схеме показана подробная структура B-tree индекса в памяти.

                                In mem index

                               +------------+
                               | key || ... |
  +--------------+             |     ||     |
  |              |             +------------+
  |              |             | v1  || ... |
  |   disk    <----------------|     ||     | Tree Node
  |              |             +------------+
  |              |             | v2  || ... |
  |           <----------------+     ||     |
  |              |             +------------+
  +--------------+       +-----+    |   |   |
                         |     |    |   |   |
                         |     +------------+
                         |
                         |
                         ^
                      ------+
                      | ... |
                      |     |
                      +-----+
                      | ... | Tree Node
                      |     |
                      +-----+
                      | ... |
                      |     |
                      ------+

Память страничного кеша управляется операционной системой и подробно в этом документе не рассматривается.

Среда тестирования

Версия etcd

• git head https://github.com/etcd-io/etcd/commit/776e9fb7be7eee5e6b58ab977c8887b4fe4d48db

Тип машины GCE n1-standard-2

• 7.5 GB памяти
• 2x CPU

Использование памяти индексом в памяти

В этом тесте измеряется только потребление памяти индексом. Цель — найти упомянутые выше c1 и c2 и понять жёсткий предел потребления памяти хранилищем.

Потребление вычисляется с помощью Go runtime.ReadMemStats как разница общего числа выделенных байтов до и после создания индекса. Это не идеально отражает память самого индекса, но показывает приблизительный характер потребления.

По результатам можно вычислить c1=120bytes и c2=30bytes. Для этого достаточно двух наборов данных, поскольку c1 и c2 — единственные неизвестные переменные в формуле. Значения c1=120bytes и c2=30bytes являются средними по 4 вычисленным наборам c1 и c2. Для небольших пар «ключ — значение» накладные расходы метаданных ключа всё ещё заметны (50%). Тем не менее это значительно лучше старого хранилища, где накладные расходы составляли не менее 1000%.

Общее использование памяти

Общее использование памяти показывает, сколько RSS потребляет etcd вместе с хранилищем. Размер значения почти не должен влиять на общее потребление памяти etcd, поскольку значения хранятся на диске, а в памяти остаются только горячие значения под управлением страничного кеша ОС.

Результаты показывают, что размер значения не оказывает существенного влияния на потребление памяти. Небольшой рост связан с увеличением объёма данных в страничном кеше ОС.

2 - Тестирование использования памяти наблюдателями

Одна из основных целей etcd — поддерживать очень большое число наблюдателей, выполняющих огромное количество наблюдений. etcd стремится поддерживать O(10k) клиентов, O(100K) потоков наблюдения (O(10) потоков на клиента) и O(10M) наблюдений в сумме (O(100) наблюдений на поток). На каждое отдельное наблюдение приходится наибольшая часть общего потребления памяти etcd, поэтому именно оно находится в центре текущей и будущей оптимизации.

Физическую память потребляют три связанных компонента наблюдения etcd: каждый grpc.Conn, каждый поток наблюдения и каждый экземпляр операции наблюдения. grpc.Conn поддерживает фактическое TCP-соединение и другое состояние соединения gRPC. Каждый grpc.Conn потребляет O(10kb) памяти и может обслуживать несколько потоков наблюдения.

Каждый поток наблюдения является независимым HTTP2-соединением и потребляет ещё O(10kb) памяти. Несколько наблюдений могут совместно использовать один поток.

Наблюдение — это фактическая структура, отслеживающая изменения в хранилище ключей и значений. Каждое наблюдение должно потреблять менее O(1kb).

                                          +-------+
                                          | watch |
                              +---------> | foo   |
                              |           +-------+
                       +------+-----+
                       |   stream   |
      +--------------> |            |
      |                +------+-----+     +-------+
      |                       |           | watch |
      |                       +---------> | bar   |
+-----+------+                            +-------+
|            |         +------------+
|   conn     +-------> |   stream   |
|            |         |            |
+-----+------+         +------------+
      |
      |
      |
      |                +------------+
      +--------------> |   stream   |
                       |            |
                       +------------+

Теоретическое потребление памяти наблюдением можно оценить по формуле: memory = c1 * number_of_conn + c2 * avg_number_of_stream_per_conn + c3 * avg_number_of_watch_stream

Среда тестирования

Версия etcd

• git head https://github.com/etcd-io/etcd/commit/185097ffaa627b909007e772c175e8fefac17af3

Тип машины GCE n1-standard-2

• 7.5 GB памяти
• 2x CPU

Общее использование памяти

Общее использование памяти показывает, сколько RSS потребляет etcd с клиентскими наблюдателями. Результат может различаться на 10%, но всё равно полезен, поскольку цель — определить приблизительное потребление памяти и характер выделений.

По результатам тестирования можно приблизительно вычислить: c1 = 17kb, c2 = 18kb и c3 = 350bytes. Таким образом, каждое дополнительное клиентское соединение потребляет 17kb памяти, каждый дополнительный поток — 18kb, а каждое дополнительное наблюдение — лишь 350bytes. В обычных условиях один сервер etcd способен поддерживать миллионы наблюдений, располагая несколькими GB памяти.

3 - Тестирование производительности etcd v3

Физические машины

GCE тип машинного оборудования n1-highcpu-2

• 1x выделенный локальный диск SSD, подключённый под /var/lib/etcd
• 1x выделенный медленный диск для ОС
• 1.8 GB памяти
• 2x процессора
• версия etcd 2.2.0

etcd Кластер

1 участник etcd, работающий в режиме демонстрации v3

Тестирование

Используйте инструмент тестирования производительности etcd v3 .

Производительность

чтение одного ключа

Производительность почти такая же, как и у сервера с пустым обработчиком.

чтение одного ключа после записи

Производительность при пустом обработчике сервера не страдает от одного оператора put. Следовательно, понижение производительности должно быть вызвано пакетом хранения.

4 - Тестирование памяти etcd v2.2.0-rc

Физическая машина

Тип машины GCE n1-standard-2

• 1x выделенный локальный SSD, подключённый в /var/lib/etcd
• 1x выделенный медленный диск для ОС
• 7.5 GB памяти
• 2x CPU

etcd

etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64

Тестирование

Запускается кластер etcd из 3 участников, каждый из которых использует 2 ядра.

Длина имени ключа всегда составляет 64 bytes — это разумная средняя длина ключа.

Максимальное использование памяти

• etcd может использовать максимальный объём памяти, если один из последователей недоступен, а лидер продолжает отправлять снимки.
• max RSS — максимальный объём используемой памяти, зафиксированный в 3 запусках.

Порог объёма данных

• Когда etcd достигает порогового объёма данных, это может легко вызвать выборы лидера и потерю части предложений.
• В большинстве случаев кластер etcd должен работать стабильно, пока не достигнут порог. Если из-за нехватки ресурсов работа нарушается, уменьшите объём данных.

5 - Тестирование производительности etcd v2.2.0-rc

Физическая машина

Тип машины GCE n1-highcpu-2

• 1x выделенный локальный SSD, подключённый в /var/lib/etcd
• 1x выделенный медленный диск для ОС
• 1.8 GB памяти
• 2x CPU

Кластер etcd

3 участника etcd 2.2.0-rc, каждый работает на отдельной машине.

Точные версии:

etcd Version: 2.2.0-alpha.1+git
Git SHA: 59a5a7e
Go Version: go1.4.2
Go OS/Arch: linux/amd64

Кроме того, базовая производительность измеряется на кластере из 3 участников etcd 2.1.0 стадии alpha. Текущий коммит etcd — c7146bd5 , тот же, что использован в тестировании etcd 2.1 .

Тестирование

Запустите ещё одну машину и с помощью инструмента HTTP-тестирования hey отправляйте запросы каждому участнику etcd. Подробные инструкции приведены в руководстве по разработке тестов производительности .

Производительность

чтение одного ключа

запись одного ключа

объяснение изменений производительности

• QPS чтения в большинстве сценариев снизился на 5~8%. Причина в том, что etcd записывает метрики хранилища для каждой операции. Эти метрики важны для мониторинга и отладки, поэтому такое снижение приемлемо.

• QPS записи на лидер увеличился на 20~30%. Основной цикл Raft и цикл применения записей были разделены, что устранило взаимные блокировки.

• QPS записи на все серверы увеличился на 30~80%, поскольку последователи раньше получают последний зафиксированный индекс и быстрее фиксируют предложения.

6 - Тестирование производительности etcd v2.2.0

Физические машины

Тип машины GCE n1-highcpu-2

• 1x выделенный локальный SSD, используемый как каталог данных etcd
• 1x выделенный медленный диск для ОС
• 1.8 GB памяти
• 2x CPU

Кластер etcd

3 участника etcd 2.2.0, каждый работает на отдельной машине.

Точные версии:

etcd Version: 2.2.0
Git SHA: e4561dd
Go Version: go1.5
Go OS/Arch: linux/amd64

Тестирование

Запустите ещё одну машину вне кластера etcd и примените инструмент HTTP-тестирования hey с патчем повторного использования соединений для отправки запросов каждому участнику кластера etcd. Патч и шаги для воспроизведения процедуры приведены в инструкции по тестированию .

Производительность вычислена по результатам 100 раундов тестирования.

Производительность

Производительность чтения одного ключа

Производительность записи одного ключа

Изменения производительности

• Поскольку etcd теперь записывает метрики для каждого вызова API, в большинстве сценариев QPS чтения немного снизился. Это минимальное влияние на производительность признано разумной платой за широкий набор данных для мониторинга и отладки.

• QPS записи на лидерах кластера немного увеличился. Основной цикл и циклы применения записей были разделены в логике Raft etcd, что устранило несколько блокировок между ними.

• QPS записи на всех участниках значительно увеличился, поскольку последователи теперь раньше получают последний зафиксированный индекс и быстрее фиксируют предложения.

7 - Тестирование производительности etcd v2.1.0

Физические машины

Тип машины GCE n1-highcpu-2

• 1x выделенный локальный SSD, подключённый в /var/lib/etcd
• 1x выделенный медленный диск для ОС
• 1.8 GB памяти
• 2x CPU
• etcd версии 2.1.0 alpha

Кластер etcd

3 участника etcd, каждый работает на отдельной машине

Тестирование

Запустите ещё одну машину и с помощью инструмента HTTP-тестирования hey отправляйте запросы каждому участнику etcd. Подробные инструкции приведены в руководстве по разработке тестов производительности .

Производительность

чтение одного ключа

запись одного ключа