desempenho de dispositivo bruto estranho no Aerospike ASD 3.15.1.4

1

Eu tenho um cluster de 4 servidores. Um dos namespaces é baseado em dispositivo bruto. Os dispositivos residem em um disco rígido mecânico do SAS.

Agora aqui está a parte estranha da história. Estou executando um dos testes com pequenos registros (2x50 bytes = 100 bytes no total). Eu consigo escrever entre 150 - 200k OPS. Agora, quando se trata de leitura - o rendimento cai para 4k OPS !!! Sim, eu sei - isso pode ser estranho, e estou totalmente confuso.

Os servidores mostram muito pouca carga durante a leitura. O iotop e o nload não mostram nada que eu possa identificar como um problema.

Aqui está a configuração do dispositivo:

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
        } 
}

Qualquer ideia seria muito apreciada.

Felicidades,

Boris.

    
por Boris Epstein 31.01.2018 / 16:56

2 respostas

2

Você não deve usar um HDD como seu dispositivo de armazenamento principal junto com o Aerospike, pois você perderá todas as otimizações de baixo nível que segmentam SSDs. Os HDDs não são criados para lidar com um grande número de leituras simultâneas, pois essa é uma das principais vantagens dos SSDs. O único local em que um HDD é apropriado no Aerospike é como uma camada de persistência para um namespace em memória. Seu namespace armazena seus dados no dispositivo, esse dispositivo deve ser um SSD digno da classe corporativa (qualidade DC AKA). .

Veja Comparando o desempenho do SSD com base em "config recipe" e o seguinte, das Perguntas frequentes (FAQ) :

Can I store data on hard disk rather than SSD?

No. The Aerospike database is intended to be a high performance, low-latency database. Because of this, the physical limitations of rotational disks add an unacceptable amount of latency to the data.

Agora, para algumas soluções rápidas:

por 31.01.2018 / 19:02
0

... como seus registros têm apenas 100 bytes, provavelmente você está usando 256 bytes por registro (com limite de overhead e 128 bytes). Se o tamanho do bloco de gravação for, por padrão, 1 MB, você se encaixará em registros de 4K em 1 MB de RAM durante a gravação, que é liberado de forma assíncrona para o disco como um bloco de 1 MB. Na leitura, você está lendo um registro individual do disco em blocos de leitura de 128 bytes. Se você está lendo um registro atualizado recentemente, provavelmente está obtendo-o da fila de pós-gravação na RAM, do contrário você está acessando o disco. Portanto, seu atraso de leitura está vindo do desempenho lento do disco para os registros que precisam ser buscados no disco. Se o tamanho do bloco de gravação fosse 128K, você ajustaria cerca de 500 registros por bloco. Você pode brincar com o tamanho do bloco de gravação em um cluster de teste e ver se o desempenho é rastreado. Verifique o valor write-q no /var/log/aerospike/aerospike.log para ver se o disco está lento. Se o disco não for o gargalo, write-q será zero na taxa de transferência. Você tem um cache max-write muito grande - 8G - (64M é o padrão) que também está ajudando você com as gravações. Você também pode testar com a redução da fila de pós-gravação para um número muito pequeno e verificar se a taxa de transferência de leitura piora.

    
por 02.02.2018 / 06:22