¿Poner Oracle rehace registros en DRAM SSD para una base de datos de escritura pesada?

Tengo un Sun M4000 conectado a una matriz EMC CX4-120 con una base de datos con gran capacidad de escritura. Escribe pico a alrededor de 1200 IO / sy 12MB / s.

Según EMC, estoy saturando el caché de escritura en la matriz EMC.

Creo que la solución más simple es mover los registros de rehacer a un SSD basado en DRAM. Esto reducirá la carga en la matriz EMC a la mitad y las aplicaciones no verán esperas de búfer de registro. Sí, el DBWR puede convertirse en un cuello de botella, pero las aplicaciones no lo estarán esperando (¡como lo hacen en los compromisos de rehacer!)

Actualmente paso por unos 4 registros de rehacer de 4 GB, por lo que incluso 20 GB de SSD marcarían una gran diferencia. Como se trata de almacenamiento a corto plazo y se sobrescribe constantemente, los SSD basados ​​en Flash probablemente no sean una gran idea.

El M4000 no tiene lotes de unidades adicionales, por lo que una tarjeta PCI-E sería perfecta, podría ser externa o mover volúmenes de arranque al EMC y liberar las unidades locales.

Sun vende una tarjeta PCIe Flash Accelerator F20, pero parece ser un caché para algunos discos SATA, no una solución DRAM SSD. Los detalles son incompletos, no enumera el M4000 como compatible, y estoy cansado de luchar contra el árbol telefónico de Sun en busca de ayuda humana. :(

¿Están de acuerdo otros en que un DRAM SSD es el camino a seguir? ¿Alguna recomendación de hardware?

ACTUALIZACIÓN Además de la información en un comentario a continuación, probé varias configuraciones para "commit_write" y no hizo la diferencia.

Primero, supongo que tienes muy pocos discos en la matriz. 1200IOPS se puede admitir fácilmente en 12 discos giratorios (100 IOPS por disco es muy razonable). Si el caché no puede manejarlo, significa que su tasa de escritura sostenida de 1200 IOPS es mucho más de lo que sus discos pueden soportar.

De todos modos, es probable que SSD para rehacer registros no ayude. Primero, ¿su sesión espera principalmente en la declaración de COMPROMISO? Verifique los principales eventos de espera en statspack / AWR para verificar. Supongo que ~ 95% de su E / S no está en los registros de rehacer en absoluto. Por ejemplo, una inserción de una sola fila en una tabla con 5 índices puede hacer 1 E / S para leer un bloque de tabla (que tiene espacio para la fila), leer 5 bloques de índice (para actualizarlos), escribir 1 bloque de datos, 1 deshacer bloque y 5 bloques de índice (o más, si se actualizan bloques que no son hojas) y 1 bloque de rehacer. Por lo tanto, revise el paquete de estadísticas y vea sus eventos de espera, es probable que esté esperando muchos READs y WRITEs para datos / índices. La espera de lecturas ralentiza el INSERT, y la actividad de ESCRITURA hace que las LECTURAS sean aún más lentas: son los mismos discos (por cierto, ¿realmente necesita todos los índices?

Otra cosa a verificar es la definición RAID: RAID1 (duplicación, cada escritura es dos escrituras) o RAID 5 (cada escritura es de 2 lecturas y dos escrituras para el cálculo de la suma de verificación). RAID 5 es mucho más lento en la carga de escritura intensiva.

Por cierto, si los discos no pueden manejar la carga de escritura, DBWR será un cuello de botella. Su SGA estará lleno de bloques sucios, y no tendrá espacio para leer nuevos bloques (como los bloques de índice que deben procesarse / actualizarse) hasta que DBWR pueda escribir algunos bloques sucios en los discos. Nuevamente, revise statspack / awr report / addm para diagnosticar cuál es el cuello de botella, generalmente basado en los 5 principales eventos de espera.

dd no es nada comparado con el bloque de E / S.

Para algunas otras vistas, verifique, anandtech.com realizó una prueba exhaustiva (otorgada con el servidor MS SQL) con SAS rotando frente a SSD, en varias combinaciones, y el mundo de Solaris tiene ZFS con SSD que compone varias partes (registros, caché, etc. )

Pero sí, si RAID 5 vs RAID 10 es el mismo (para escrituras), está haciendo algo mal. Con escrituras lineales, heck RAID 5 podría ser más rápido (es decir, puede hacer la paridad en la memoria, luego escribir las franjas y la paridad de una vez), pero con un pequeño bloque aleatorio (4-8k), te matan al actualizar las franjas (como señalado por otros), la incursión 10 debería ser más de 2 veces más rápida, si no, algo está mal.

Debe profundizar antes de gastar dinero en hardware.

Vi una publicación sobre el montaje de particiones UFS utilizando la opción "forceirectio" y configurando el parámetro de Oracle "filesystemio_options" en "setall".

¡Lo probé y veo una mejora de 4-5x en las escrituras de Oracle! ¡Sí!

Los síntomas clave fueron bajo rendimiento pero buenos tiempos de respuesta en el disco. Esto parece ayudar a algunas personas pero no a otras. Ciertamente hizo el trabajo por mí.

Puedo considerar SSD para nuevos servidores, pero este servidor está funcionando bien ahora.

Robert

Si esta caja solo hubiera sido una caja x86 / 64 con Linux, habría recomendado una de las tarjetas de unidad FusionIO PCIe: son increíblemente rápidas y no 'mueren' con grabaciones pesadas como lo hacen las SSD. Desafortunadamente, no son compatibles con Sparc o Solaris, sin embargo, es posible que desee contactarlos para discutir esto.

La tarjeta PCIe F20e es similar a la E / S Fusion en función. Básicamente es solo un SSD Flash conectado a PCIe. Con una gran carga de trabajo de escritura, deberá preocuparse por mantener suficientes bloques libres (mediante algún tipo de recolección de basura basada en la unidad) para que no termine con el ciclo Borrar / Programa en el SSD convirtiéndose en el cuello de botella, así como los ciclos de escritura limitados disponibles en un SSD basado en Flash. Definitivamente es rápido, pero podría no ser el mejor kit para este trabajo.