Melhor desempenho: 1 TB contra unidades maiores no aplicativo usando somente leitura / gravação sequencial

Question

Eu tenho um aplicativo personalizado que é multi-threaded; cada thread é executado em seu próprio núcleo lógico (a estação de trabalho é um dual xeon, com 12 núcleos físicos e 24 lógicos). Portanto, existem 24 threads em execução simultaneamente.

Estou pesquisando as várias opções de armazenamento nos últimos dois dias e minha cabeça está girando a cerca de 15k rpm.

O aplicativo tem dois modos, e eles são exclusivos: ler dados ou gravar dados; por isso quero dizer que eles não estarão fazendo leituras / gravações intercaladas. Cada thread estará apenas fazendo longas leituras ou gravações sequenciais. O armazenamento total que eu preciso é enorme: mais de 50 tbs (se você está lendo isso no ano de 2016, provavelmente você está tendo uma boa risada sobre a palavra "enorme").

Cada thread estará lendo ou escrevendo um arquivo com aproximadamente .8tb

Eu vou com jbod, porque se uma unidade falhar, tudo o que eu preciso fazer é trocá-la, e o aplicativo recriará os dados em aproximadamente 10 minutos.

Eu colocarei as unidades em uma torre ou rack externo, usando um controlador SATA ou SAS (ainda não descobri o +/- desses).

Então, minha pergunta: estou correto em assumir que o uso de unidades de 1 TB para esse aplicativo específico seria melhor desempenho sábio do que usar unidades 2, 3 ou 4 vezes esse tamanho? Parece que, a menos que uma unidade de 3 tb tenha uma taxa de leitura / gravação sequencial de 3x a unidade de 1 tb, a unidade menor é o caminho a seguir.

Obviamente, o uso de unidades de 3 TB reduz o número de unidades com as quais preciso me preocupar em 1/3, mas isso seria apenas uma consideração se eu conseguisse um desempenho que estivesse no mesmo patamar das unidades de 1 TB.

    

Answer 1

Mais importante, para melhor desempenho, você precisa de 24 unidades (ou mais, tenha paciência comigo), porque você tem 24 threads. Se houver menos discos que encadeamentos, você não terá operação sequencial. Considerando dois threads em um único disco, ele terá algumas buscas; cada busca é digamos 10 ms, portanto, uma perda de cerca de 1 MB de oportunidade de transferência. Com apenas 10 buscas por segundo, você tem 90 MB / s (2 x 45) em vez de 1 x 100 MB / s.

Acho que você seria melhor com 48 unidades de 1 TB cada. Unidades seriam emparelhadas, para obter 24 grupos despojados (aka RAID0). Você pode assumir que a remoção feita no nível do SO terá um impacto imperceptível, portanto, cada thread obterá uma taxa de transferência dupla de uma unidade de 1 TB.

Não vejo nenhum benefício possível dos drives de 3 TB no desempenho.

Ainda, o maior benefício de desempenho seria algo totalmente diferente. Apenas certifique-se de que o aplicativo transmite os dados de forma eficaz - que seriamente alimenta a fila no HDD com esses comandos de E / S. Se estiver escrito de uma maneira que espere que alguma E / S seja concluída antes de enfileirar outra E / S, isso tornaria a taxa de transferência severa.

• É melhor corrigi-lo no próprio aplicativo ou ...
• Para aliviar parcialmente isso, você precisaria investir muito dinheiro em uma matriz de disco com um enorme cache extra.

PS. Adoro a observação sobre o 2016, oi ai pessoal! Você já conseguiu essas pranchas de paquera?

    

Answer 2

Considerando que as operações são contenção sequencial e mínima, pode não haver muita diferença no desempenho de gravação entre o SATA e o SAS.

O desempenho de leitura é outra história. Eu não acho que você vai encontrar muitas unidades SATA 15k econo. As unidades SAS tendem a ter um nível mais alto e alto rpm, e os controladores SAS geralmente superam o SATA, mas se você estiver usando um econo não-RAID hba, pode não haver muita diferença.

Por que vale a pena, você deve conseguir atingir pelo menos 100 Mbytes / segundo desempenho de gravação usando uma única unidade SATA de 2 TB em um controlador não-array padrão. Pode ser mais com SATA de 6 Gbps. Para comparação, eu tenho um RAID0 com 4x2TB (6 Gbps) unidades SATA, e tem 500 Mbytes / segundo desempenho de gravação seqüencial.

    

Answer 3

Bem, sua resposta não deve ser baseada na capacidade da unidade, mas sim no número de discos e sua densidade. Uma unidade de 7200 RPM que lê sequencialmente 100 GB de uma unidade de 1,5 TB composta por 3 bandejas de 500 GB será mais lenta do que a leitura dos mesmos 100 GB de uma unidade de 1,5 TB composta por dois discos de 750 GB, porque a densidade de dados é mais alta. / p>

O que você realmente precisa fazer é encontrar referências para todas as unidades em questão.

Eu arriscaria adivinhar que, em uma situação com ~ 18 discos rígidos de 3 TB armazenando 50 TB versus 50 discos rígidos de 1 TB, os discos de 3 TB seriam mais rápidos ao ler ou gravar um arquivo por vez ... mas, novamente, tudo depende do desempenho dos discos individuais.

    

Answer 4

Acho que há algum mérito em pelo menos tentar o RAID aqui. Existe alguma sobrecarga, e as reconstruções de RAID, quando acontecem, podem acabar sendo um show-stopper, mas existem alguns benefícios possíveis.

• Gerenciamento muito mais simples é o óbvio
• O desempenho de disco único atingirá o pico em algo como 50 a 70 MB / s por toda a unidade. Ele será mais rápido na borda externa (por exemplo, início do disco) e mais lento na borda interna (em meus testes, geralmente metade da taxa da borda externa) Se você estiver gravando em um único disco, você atingirá esse limite o tempo todo. Se você está escrevendo para um agregado de discos (no entanto, ele é gerenciado), você ainda atingirá esse limite (o desempenho sustentado de um RAID0 de 4 discos é simplesmente 4x o desempenho interno de um único disco), mas você têm maior taxa de transferência agregada.
• Conjuntos RAID aumentarão a contenção (se você estiver fazendo várias gravações / leituras). Eles também aumentarão a largura de banda disponível. Isso pode ou não ser importante para você, mas vale a pena tentar
• Parece que suas gravações basicamente transmitem dados em massa para o disco. Se for esse o caso, a sobrecarga RAID5 é razoavelmente baixa, porque se você estiver gravando pedaços de dados com largura de faixa RAID completos no disco, não há necessidade de fazer o ciclo de recálculo / gravação de leitura / paridade - seu controlador apenas gravará a nova faixa e paridade em um hit. (Paridade é barata, é o ciclo de leitura / gravação que dói)

Escrever 800 GB de dados de cada thread levará algo em torno de 2 a 3 horas. Assumindo que seu disco irá sustentar cerca de 120MB / seg na borda externa e cerca de 60MB / seg na borda interna. Com 120MB / s, seus 800 GB de dados levariam cerca de 111 minutos, com 60 MB / s seria o dobro disso. A queda no desempenho de gravação não é linear, mas é razoável supor que você gastará entre 2 e 3 horas escrevendo esse arquivo de 800 GB. A sugestão de @kubanczyk provavelmente diminui pela metade, mas não tenha medo de ir para agregações maiores (seja RAID0 ou RAID5 ou RAID5 + 0)

Eu não tenho uma boa idéia para isso (não tenho como fazer os testes), mas geralmente é considerado que os drives SAS têm melhor desempenho, mesmo quando a velocidade de rotação é a mesma (por exemplo, Seagate Constellation ES.2 SATA vs Seagate Constellation ES.2 SAS). Alguns dos benefícios incluem operação full-duplex para unidades SAS e maior profundidade de fila. O ponto full-duplex vs half-duplex deve significar que as operações simultâneas de leitura / gravação têm menos efeito geral. Você ainda incorrerá em buscas em disco, mas não estará bloqueando gravações de disco enquanto espera por uma leitura, por exemplo.

Eu construo muitos sistemas com matrizes de 16 discos. Dois conjuntos RAID5 (controladores RAID de hardware), com o software RAID Linux no topo. Temos um desempenho muito bom aqui: em algum lugar entre 750 e 850MB / seg suportado em todo o array, dependendo do modelo de disco usado. Jogar em vários escritores adiciona contenção e diminui a taxa de transferência geral, mas dependendo da frequência com que você está escrevendo seus dados antes de lê-los novamente, algo nesse sentido pode ajudar.

Espero não ter enlameado muito as águas aqui:)