У меня кластер из 4 серверов. Одно из пространств имен основано на необработанном устройстве. Устройства размещаются на механическом жестком диске SAS.
А теперь самое странное. Я запускаю один из тестов с небольшими записями (2x50 байт = всего 100 байт). Я могу написать от 150 до 200 тысяч операций в секунду. Теперь по чтению - пропускная способность падает до 4к ОПС !!! Да, я знаю - это может показаться странным, и я полностью запутался.
Серверы показывают очень небольшую нагрузку во время чтения. 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
}
}
Любое понимание будет очень признательно.
Привет,
Борис.
Вы не должны использовать жесткий диск в качестве основного устройства хранения вместе с Aerospike, так как вы упустите все низкоуровневые оптимизации, нацеленные на SSD. Жесткие диски не предназначены для обработки большого количества одновременных операций чтения, что является одним из основных преимуществ твердотельных накопителей. Единственное место, где жесткий диск подходит в 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), который также помогает вам с записью. Вы также можете протестировать сокращение очереди после записи до очень небольшого числа и посмотреть, не ухудшится ли пропускная способность чтения.