Estou tentando otimizar uma configuração de armazenamento em alguns hardwares da Sun com Linux. Qualquer pensamento seria muito apreciado.
Temos o seguinte hardware:
- Sun Blade X6270
- 2 * controladores SAS LSISAS1068E
- 2 * JBODs Sun J4400 com discos de 1 TB (24 discos por JBOD)
- Fedora Core 12
- 2.6.33 do kernel do FC13 (também testado com o kernel 2.6.31 mais recente do FC12, os mesmos resultados)
Aqui está a folha de dados para o hardware SAS:
http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf
Está usando PCI Express 1.0a, 8x pistas. Com uma largura de banda de 250 MB / s por faixa, poderemos fazer 2000 MB / s por controlador SAS.
Cada controlador pode executar 3 Gb / s por porta e possui dois PHYs de 4 portas. Conectamos os dois PHYs de um controlador a um JBOD. Portanto, entre o JBOD e o controlador, temos 2 PHYs * 4 portas SAS * 3 Gb / s = 24 Gb / s de largura de banda, que é mais do que a largura de banda do PCI Express.
Com o cache de gravação ativado e ao realizar grandes gravações, cada disco pode suportar cerca de 80 MB / s (próximo ao início do disco). Com 24 discos, isso significa que devemos conseguir 1920 MB / s por JBOD.
multipath {
rr_min_io 100
uid 0
multibus path_grouping_policy
manual de failback
path_selector "rodízio 0"
prioridades rr_weight
alias somealias
fila no_path_retry
modo 0644
gid 0
wwid somewid
}
Tentei valores de 50, 100, 1000 para rr_min_io, mas não parece fazer muita diferença.
Junto com a variação de rr_min_io, tentei adicionar algum atraso entre iniciar os dd's para impedir que todos escrevessem no mesmo PHY ao mesmo tempo, mas isso não fez nenhuma diferença, por isso acho que as E / Ss estão se espalhando adequadamente.
De acordo com / proc / interrupts, os controladores SAS estão usando um esquema de interrupção "IR-IO-APIC-fasteoi". Por alguma razão, apenas o núcleo nº 0 da máquina está lidando com essas interrupções. Posso melhorar um pouco o desempenho atribuindo um núcleo separado para lidar com as interrupções de cada controlador SAS:
eco 2> / proc / irq / 24 / smp_affinity eco 4> / proc / irq / 26 / smp_affinity
O uso do dd para gravar no disco gera "Interrupções de chamadas de funções" (não faço ideia do que sejam), que são tratadas pelo núcleo nº 4, portanto, também mantenho outros processos fora desse núcleo.
Eu corro 48 dd (um para cada disco), atribuindo-os a núcleos que não lidam com interrupções da seguinte forma:
conjunto de tarefas -c somecore dd se = / dev / zero de = / dev / mapper / mpathx oflag = direct bs = 128M
oflag = direct impede que qualquer tipo de cache de buffer se envolva.
Nenhum dos meus núcleos parece estar no limite. Os núcleos que lidam com interrupções são inativos e todos os outros núcleos aguardam E / S como seria de esperar.
Cpu0: 0,0% us, 1,0% sy, 0,0% ni, 91,2% id, 7,5% wa, 0,0% hi, 0,2% hi, 0,2% si, 0,0% st Cpu1: 0,0% us, 0,8% sy, 0,0% ni, 93,0% id, 0,2% wa, 0,0% wa, 0,0% hi, 6,0% si, 0,0% st Cpu2: 0,0% us, 0,6% sy, 0,0% ni, 94,4% id, 0,1% wa, 0,0% hi, 0,0% hi, 4,8% si, 0,0% st Cpu3: 0,0% us, 7,5% sy, 0,0% ni, 36,3% id, 56,1% wa, 0,0% hi, 0,0% si, 0,0% st Cpu4: 0,0% us, 1,3% sy, 0,0% ni, 85,7% id, 4,9% wa, 0,0% hi, 0,0% hi, 8,1% si, 0,0% st Cpu5: 0,1% us, 5,5% sy, 0,0% ni, 36,2% id, 58,3% wa, 0,0% hi, 0,0% si, 0,0% st Cpu6: 0,0% us, 5,0% sy, 0,0% ni, 36,3% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st Cpu7: 0,0% us, 5,1% sy, 0,0% ni, 36,3% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st Cpu8: 0,1% us, 8,3% sy, 0,0% ni, 27,2% id, 64,4% wa, 0,0% hi, 0,0% si, 0,0% st Cpu9: 0,1% us, 7,9% sy, 0,0% ni, 36,2% id, 55,8% wa, 0,0% hi, 0,0% si, 0,0% st Cpu10: 0,0% us, 7,8% sy, 0,0% ni, 36,2% id, 56,0% wa, 0,0% hi, 0,0% si, 0,0% st Cpu11: 0,0% us, 7,3% sy, 0,0% ni, 36,3% id, 56,4% wa, 0,0% hi, 0,0% si, 0,0% st Cpu12: 0,0% us, 5,6% sy, 0,0% ni, 33,1% id, 61,2% wa, 0,0% hi, 0,0% si, 0,0% st Cpu13: 0,1% us, 5,3% sy, 0,0% ni, 36,1% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st Cpu14: 0,0% us, 4,9% sy, 0,0% ni, 36,4% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st Cpu15: 0,1% us, 5,4% sy, 0,0% ni, 36,5% id, 58,1% wa, 0,0% hi, 0,0% si, 0,0% st
Dado tudo isso, a taxa de transferência relatada executando "dstat 10" está no intervalo de 2200-2300 MB / s.
Dada a matemática acima, eu esperaria algo na faixa de 2 * 1920 ~ = 3600+ MB / s.
Alguém tem alguma idéia de onde foi minha largura de banda perdida?
Obrigado!