Eu tenho um Sun M4000 conectado a um array EMC CX4-120 com um banco de dados pesado. Escreve pico em torno de 1200 IO / se 12MB / s.
De acordo com a EMC, estou saturando o cache de gravação no array EMC.
Acho que a solução mais simples é mover os redo logs para um SSD baseado em DRAM. Isso reduzirá a carga do array EMC pela metade e os aplicativos não verão as esperas do buffer de log. Sim, o DBWR pode se tornar um gargalo, mas os aplicativos não estarão esperando por ele (como fazem em refazer commits!)
Eu atualmente percorro cerca de 4 redo logs de 4 GB, então até 20 GB ou mais de SSD faria uma grande diferença. Como esse é um armazenamento de curto prazo e está sendo constantemente sobrescrito, os SSDs baseados em Flash provavelmente não são uma ótima ideia.
O M4000 não tem nenhum lote extra de unidades, portanto, uma placa PCI-E seria perfeita, eu poderia ir para o exterior ou mover os volumes de inicialização para o EMC e liberar as unidades locais.
A Sun vende uma placa PCIe Flash Accelerator F20, mas isso parece ser um cache para alguns discos SATA, não uma solução DRAM SSD. Os detalhes são incompletos, não listam o M4000 como suportado e estou cansado de combater a árvore de telefones da Sun procurando ajuda humana. :(
Os outros concordam que um SSD DRAM é o caminho a percorrer? Alguma recomendação de hardware?
UPDATE Além da informação em um comentário abaixo, eu tentei várias configurações para "commit_write" e isso não fez diferença.
Eu vi uma postagem sobre a montagem de partições UFS usando a opção "forcedirectio" e definindo o parâmetro "filesystemio_options" do Oracle como "setall".
Eu tentei e vi uma melhoria de 4-5x na Oracle escreve! Sim!
Os principais sintomas foram baixo rendimento, mas bons tempos de resposta no disco. Isso parece ajudar algumas pessoas, mas não outras. Certamente fez o trabalho para mim.
Eu posso considerar SSDs para novos servidores, mas esse servidor está funcionando bem agora.
Robert
Primeiro, acho que você tem poucos discos no array. O 1200IOPS pode ser facilmente suportado em 12 discos giratórios (100 IOPS por disco é muito razoável). Se o cache não puder manipulá-lo, isso significa que sua taxa de gravação sustentada de 1200 IOPS é muito maior do que os seus discos podem suportar.
De qualquer forma, o SSD para redo logs provavelmente não ajudará. Primeiro, a sua sessão espera principalmente na instrução COMMIT? Verifique os principais eventos de espera no statspack / AWR para verificar. Eu acho que ~ 95% do seu I / O não é para os logs refazer. Por exemplo, uma inserção de linha única em uma tabela com 5 índices pode fazer 1 E / S para ler um bloco de tabela (que possui espaço para a linha), ler 5 blocos de índice (para atualizá-los), gravar 1 bloco de dados, 1 desfazer bloco e 5 blocos de índice (ou mais, se os blocos não folha forem atualizados) e 1 bloco refazer. Então, verifique statspack e veja seus eventos de espera, você provavelmente está esperando muito por READs e WRITEs por dados / índices. A espera por leituras desacelera o INSERT, e a atividade WRITE torna os READs ainda mais lentos - são os mesmos discos (BTW - você realmente precisa de todos os índices? Soltar os que não devem ter acelerará as inserções).
Outra coisa a verificar é a definição de RAID - RAID1 (espelhamento - cada gravação é de duas gravações) ou RAID 5 (cada gravação é de 2 leituras e duas gravações para cálculo de soma de verificação). O RAID 5 é muito mais lento em carga intensiva de gravação.
BTW - se os discos não puderem abranger a carga de gravação, o DBWR será um gargalo. Sua SGA estará cheia com blocos sujos e você não terá espaço para ler novos blocos (como blocos de índice que precisam ser processados / atualizados) até que a DBWR possa gravar alguns blocos sujos nos discos. Novamente, verifique statspack / awr report / addm para diagnosticar qual é o gargalo, normalmente baseado nos 5 principais eventos de espera.
dd não é nada comparado ao bloco i / o.
Para algumas outras visualizações, verifique ao redor, anandtech.com fez um teste exaustivo (concedido com MS SQL server) com SAS rotativo vs SSD, em várias combinações, e o mundo Solaris tem ZFS com SSD fazendo várias partes (logs, cache, etc).
Mas sim, se o RAID 5 vs RAID 10 for o mesmo (para gravações), você está fazendo algo errado. Com gravações lineares, o RAID 5 poderia ser mais rápido (isto é, ele pode fazer a paridade na memória, escrever as listras e a paridade de uma só vez), mas com um pequeno bloco aleatório (4-8k), você é morto atualizando listras (como anotado por outros), o ataque 10 deve ser mais de 2x mais rápido, se não, algo está errado.
Você precisa ir mais fundo, antes de gastar dinheiro em hardware.
Se esta caixa tivesse sido apenas uma caixa x86 / 64 executando linux, eu teria recomendado uma das placas de drive PCIe FusionIO - elas são surpreendentemente rápidas e não "morrem" com gravações pesadas como SSDs. Infelizmente, eles não são compatíveis com Sparc ou Solaris, mas você pode entrar em contato para discutir isso.
A placa PCIe F20e é semelhante à função Fusion I / O in. É basicamente apenas um SSD Flash conectado em PCIe. Com muita carga de trabalho, você precisa se preocupar em manter blocos livres suficientes (por meio de algum tipo de coleta de lixo) para que você não termine com o ciclo Erase / Program no SSD se tornando o gargalo, assim como os limitados ciclos de gravação disponíveis em um SSD baseado em Flash. É definitivamente rápido, mas pode não ser o melhor kit para este trabalho.