Аэроспайк плохие задержки с AWS - PullRequest
Новая
       11

Аэроспайк плохие задержки с AWS

0 голосов
/ 10 мая 2018

У нас есть аэроспайк, работающий в слое Soft на голых металлических машинах в кластере из 2 узлов Средний размер нашего профиля составляет 1,5 КБ, и в пиковые периоды операции будут составлять около 6000 операций в секунду на каждом узле. С задержками все в порядке, а при пике> 1 мс будет около 5%.

Теперь мы планировали перейти на aws. Итак, мы загрузили 2 машины i3.xlarge. Мы запустили тест с размером объекта 1,5 КБ с нагрузкой 3x. результаты были удовлетворительными, то есть около 4-5% (> 1 мс). Теперь мы приступили к фактической обработке, задержки в пике подскочили до 25-30%, что составляет> 1 мс, и максимум, который он может вместить, составляет около 5 тыс. Операций в секунду. Таким образом, мы добавили еще один узел, мы сделали бенчмарк (размер объекта 4,5 КБ и загрузка 3x). Результаты были 2-4% (> 1 мс). Теперь после добавления в кластер пик снизился до 16-22%. Мы добавили еще один узел, и сейчас пик составляет 10-15%.

Версия в aws - aerospike-server-community-3.15.0.2, версия в Sl - Aerospike Enterprise Edition 3.6.3

Наша конфигурация выглядит следующим образом 

#Aerospike database configuration file.
service {
    user xxxxx 
    group xxxxx 
    run-as-daemon
    paxos-single-replica-limit 1 # Number of nodes where the replica count is automatically reduced to 1.
    pidfile /var/run/aerospike/asd.pid 
    service-threads 8 
    transaction-queues 8
    transaction-threads-per-queue 8
    proto-fd-max 15000
}

logging {

    #Log file must be an absolute path.
    file /var/log/aerospike/aerospike.log {
        context any info
    }
}

network {
    service {
        port 13000
        address h1 reuse-address
    }

    heartbeat {
        mode mesh
        port 13001
        address h1

        mesh-seed-address-port h1 13001
        mesh-seed-address-port h2 13001
        mesh-seed-address-port h3 13001
        mesh-seed-address-port h4 13001
        interval 150
        timeout 10
    }

    fabric {
        port 13002
        address h1
    }

    info {
        port 13003
        address h1
    }
}

namespace XXXX { 
    replication-factor 2
    memory-size 27G
    default-ttl 10d
    high-water-memory-pct 70
    high-water-disk-pct 60
    stop-writes-pct 90
    storage-engine device {
        device /dev/nvme0n1
        scheduler-mode noop
        write-block-size 128K
    }
}

Что нужно сделать, чтобы уменьшить задержки в aws?

1 Ответ

0 голосов
/ 12 мая 2018

Это объясняется разницей в характеристиках производительности твердотельных накопителей узлов i3 по сравнению с тем, что было у вас в Softlayer.Если вы запустите Aerospike на дискете , вы получите 0,5TPS.

В комментарии Пиюша упоминается ACT , инструмент с открытым исходным кодом, созданный Aerospike для сравнения твердотельных накопителей с реальнымирабочие нагрузки базы данных.Смысл ACT в том, чтобы найти устойчивую скорость, с которой можно рассчитывать на SSD для обеспечения требуемой задержки.Скорость пакетной передачи не имеет большого значения для баз данных.

Команда разработчиков Aerospike использовала ACT, чтобы выяснить, на что способен твердотельный накопитель i3 1900G, и опубликовала результаты в сообщении .Его рейтинг ACT равен 4x, что означает, что full 1900G SSD может выполнять чтение 8Ktps, запись 4Ktps со стандартным размером объекта 1,5K, размером блока 128K и оставаться на уровне 95% <1 мс, 99% <8 мс,99,9% <64 мс.<strong> Это не особенно хорошо для SSD .Для сравнения, у Micron 9200 PRO скорость 94,5x, почти в 24 раза выше нагрузка TPS.Более того, с i3.xlarge вы делите половину этого диска с соседом .Невозможно ограничить количество операций ввода-вывода в секунду, чтобы вы получили половину, есть только раздел хранилища.Это означает, что вы можете ожидать всплески задержки, возникающие у соседа.I3.2xlarge - это самый маленький экземпляр, который дает вам весь SSD.

Итак, вы берете информацию ACT и используете ее для планирования емкости .Основными факторами, которые вам нужно знать, являются средний размер объекта (вы можете найти это, используя objsz гистограмму ), количество объектов (опять же, доступных через asadm ), TPS чтения пиков и пикнапишите TPS (как упомянутые вами скорости 60Ktps распределяются между операциями чтения и записи?).

Проверьте в своих журналах значения cache-read-pct.Если они находятся в диапазоне 10% или выше, вам следует увеличить значение post-write-queue, чтобы улучшить задержки чтения (а также уменьшить давление IOPS от привода).

...