Colocando os logs refazer do Oracle no DRAM SSD para um banco de dados de gravação pesado?

Eu tenho um Sun M4000 conectado a uma matriz EMC CX4-120 com um banco de dados com muita gravação. Grava pico em torno de 1200 IO / se 12MB / s.

De acordo com a EMC, estou saturando o cache de gravação na matriz EMC.

Eu acho que a solução mais simples é mover os logs refazer para um SSD baseado em DRAM. Isso reduzirá a carga na matriz EMC pela metade e os aplicativos não verão o buffer de log aguardando. Sim, o DBWR pode se tornar um gargalo, mas os aplicativos não estarão esperando por ele (como fazem nos refazer confirmações!)

Atualmente, eu percorro cerca de 4 logs de refazer 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 substituído, os SSDs baseados em Flash provavelmente não são uma boa idéia.

O M4000 não possui lotes de unidades extras; portanto, uma placa PCI-E seria perfeita; eu poderia externo ou mover os volumes de inicialização para a EMC e liberar as unidades locais.

A Sun vende uma placa PCIe do Flash Accelerator F20, mas isso parece ser um cache para alguns discos SATA, não uma solução de DRAM SSD. Os detalhes são incompletos, ele não lista o M4000 como suportado e estou cansado de lutar contra a árvore telefônica da Sun em busca de ajuda humana. :(

Outros concordam que um DRAM SSD é o caminho a seguir? Alguma recomendação de hardware?

ATUALIZAÇÃO Além das informações em um comentário abaixo, tentei várias configurações para "commit_write" e isso não fez diferença.

Primeiro - acho que você tem muito poucos discos na matriz. O 1200IOPS pode ser facilmente suportado por 12 discos giratórios (100 IOPS por disco é muito razoável). Se o cache não puder lidar com isso, significa que sua taxa de gravação sustentada de 1200 IOPS é muito mais do que seus discos podem suportar.

De qualquer forma, o SSD para refazer logs provavelmente não ajudará. Primeiro, sua sessão espera principalmente pela instrução COMMIT? Verifique os principais eventos de espera no statspack / AWR para verificar. Eu acho que ~ 95% da sua E / S não é para os logs de 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 tem espaço para a linha), ler 5 blocos de índice (para atualizá-los), escrever 1 bloco de dados, 1 desfazer bloco e 5 blocos de índice (ou mais, se blocos não folha forem atualizados) e 1 bloco de refazer. Portanto, verifique o pacote de estatísticas e veja seus eventos de espera. Provavelmente, você está aguardando muitos READs e WRITEs por dados / índices. A espera de leituras diminui a velocidade do INSERT, e a atividade WRITE torna o READs ainda mais lento - são os mesmos discos (BTW - você realmente precisa de todos os índices? Largar aqueles que não são obrigatórios acelerará as inserções).

Outra coisa a verificar é a definição de RAID - é RAID1 (espelhamento - cada gravação é duas gravações) ou RAID 5 (cada gravação é 2 leituras e duas gravações para cálculo da soma de verificação). O RAID 5 é muito mais lento em carga intensiva de gravação.

BTW - se os discos não puderem conter a carga de gravação, o DBWR será um gargalo. Seu SGA estará cheio de blocos sujos e você não terá espaço para ler novos blocos (como blocos de índice que precisam ser processados ​​/ atualizados) até que o DBWR possa gravar alguns blocos sujos em discos. Mais uma vez, verifique o statspack / awr report / addm para diagnosticar qual é o gargalo, normalmente com base nos 5 principais eventos de espera.

dd não é nada comparado ao bloco de E / S.

Para outras visões, confira: anandtech.com fez um teste exaustivo (concedido com o MS SQL Server) com rotação do SAS vs SSD, em várias combinações, e o mundo Solaris tem o ZFS com o SSD SSD compondo várias partes (logs, cache, etc. )

Mas sim, se RAID 5 vs RAID 10 for o mesmo (para gravações), você está fazendo algo errado. Com gravações lineares, o RAID 5 pode ser mais rápido (ou seja, ele pode fazer a paridade na memória e gravar as faixas e a paridade de uma só vez), mas com um bloco pequeno aleatório (4-8k), você é morto atualizando faixas (como observado por outros), o ataque 10 deve ser duas vezes mais rápido, se não, algo está errado.

Você precisa se aprofundar antes de gastar dinheiro em hardware.

Vi um post sobre a montagem de partições UFS usando a opção "forceirectio" e definindo o parâmetro Oracle "filesystemio_options" para "setall".

Eu tentei e vi uma melhoria de 4-5x nas gravações do Oracle! Sim!

Os principais sintomas foram baixa taxa de transferência, mas bons tempos de resposta no disco. Isso parece ajudar algumas pessoas, mas não outras. Certamente fez o trabalho para mim.

Posso considerar os SSDs para novos servidores, mas este servidor está funcionando bem agora.

Robert

Se essa caixa tivesse sido apenas uma caixa x86 / 64 executando linux, eu recomendaria alegremente uma das placas de unidade FusionIO PCIe - elas são surpreendentemente rápidas e não "morrem" com gravações pesadas, como os SSDs fazem. Infelizmente, eles não são suportados pelo Sparc ou Solaris. Você pode entrar em contato com eles para discutir isso.

A placa PCIe F20e é semelhante à função Fusion I / O in. É basicamente apenas um SSD Flash conectado ao PCIe. Com a carga de trabalho pesada de gravação, você precisa se preocupar em manter blocos livres suficientes (através de algum tipo de coleta de lixo baseada em unidade) para não acabar com o ciclo Apagar / Programa no SSD, tornando-se um gargalo, bem como os ciclos limitados 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.