Странное сырье устройства на Aerospike ASD 3.15.1.4
У меня кластер из 4 серверов. Одно из пространств имен является необработанным устройством. Устройства находятся на механическом жестком диске SAS.
Теперь вот странная часть истории. Я запускаю один из тестов с небольшими записями (2x50 байт = 100 байт всего). Я получаю писать на 150 - 200 тыс. ОПС. Теперь, когда дело доходит до чтения - пропускная способность падает до 4k OPS!!! Да, я знаю - это может быть странно, и я совершенно сбит с толку.
Во время чтения серверы показывают очень небольшую нагрузку. Iotop и nload не показывают ничего, что я могу определить как проблему.
Вот конфигурация устройства:
namespace test-raw {
replication-factor 4
memory-size 16G
default-ttl 7200
max-ttl 2D
high-water-disk-pct 80
high-water-memory-pct 60
stop-writes-pct 90
partition-tree-locks 64
partition-tree-sprigs 4096
storage-engine device {
device /dev/sdb1
write-block-size 1M
max-write-cache 8G
data-in-memory false
cold-start-empty true
}
}
Любое понимание будет высоко ценится.
Ура,
Борис.
2 ответа
Вы не должны использовать жесткий диск в качестве основного устройства хранения данных вместе с Aerospike, так как вам не хватает всех низкоуровневых оптимизаций для твердотельных накопителей. Жесткие диски не предназначены для обработки большого числа одновременных операций чтения, поскольку это является одним из основных преимуществ твердотельных накопителей. Единственное место, где жесткий диск подходит в Aerospike - это постоянный слой для пространства имен в памяти. Ваше пространство имен хранит свои данные на устройстве, это устройство должно быть SSD достойного уровня предприятия (качества AKA DC).
См. Сравнение производительности SSD на основе "Конфигурационного рецепта" и следующего из Часто задаваемых вопросов (FAQ):
Могу ли я хранить данные на жестком диске, а не на SSD?
Нет. База данных Aerospike предназначена для высокопроизводительной базы данных с низкой задержкой. Из-за этого физические ограничения вращающихся дисков добавляют недопустимую задержку к данным.
Теперь несколько быстрых исправлений:
- Внутри
storage-engine deviceблок вашей конфигурации пространства имен убедитесь, чтоscheduler-modeявно установлен наnoop, Смотрите FAQ - Какова цель планировщика дисков? - Максимизируйте свой
post-write-queue, установив его на 2048. См. Что происходит, когда клиент записывает запись в постоянное хранилище в базе данных Aerospike?, Вы можете настроить это динамически:asadm -e "asinfo -v 'set-config:context=namespace;id=test-raw;post-write-queue=2048' "
... так как ваши записи только 100 байтов, вы, вероятно, используете 256 байтов на запись (с накладными расходами и границей 128 байтов). Если размер блока записи по умолчанию равен 1 МБ, вы записываете около 4 КБ записей в 1 МБ в ОЗУ во время записи, которая асинхронно записывается на диск в виде блока 1 МБ. При чтении вы читаете отдельную запись с диска в 128-битных блоках чтения. Если вы читаете недавно обновленную запись, вы, вероятно, получаете ее из очереди после записи в ОЗУ, в противном случае вы обращаетесь к диску. Таким образом, ваша задержка чтения связана с низкой производительностью диска для записей, которые должны быть извлечены с диска. Если бы размер блока записи был 128 КБ, то вы бы поместили около 500 записей на блок. Вы можете поиграть с размером блока записи на тестовом кластере и посмотреть, будет ли производительность отслеживаться. Проверьте значение write-q в /var/log/aerospike/aerospike.log, чтобы увидеть, работает ли диск медленно. Если диск не является узким местом, write-q будет нулевым при пропускной способности записи. У вас очень большой max-write-cache - 8G - (по умолчанию 64M), который также помогает вам при записи. Вы также можете протестировать с уменьшением очереди после записи до очень небольшого числа и посмотреть, ухудшится ли пропускная способность чтения.