Mettre les journaux de rétablissement Oracle sur le SSD DRAM pour une base de données d'écriture lourde?

9

J'ai un Sun M4000 connecté à une baie EMC CX4-120 avec une base de données lourde en écriture. Écrit le pic à environ 1200 IO / s et 12 Mo / s.

Selon EMC, je sature le cache d'écriture sur la baie EMC.

Je pense que la solution la plus simple est de déplacer les journaux de rétablissement vers un SSD basé sur DRAM. Cela réduira de moitié la charge de la baie EMC et les applications ne verront pas les attentes du tampon de journal. Oui, le DBWR peut devenir un goulot d'étranglement, mais les applications ne l'attendront pas (comme elles le font lors des validations de rétablissement!)

Je passe actuellement en revue environ 4 journaux de rétablissement de 4 Go, donc même 20 Go environ de SSD feraient une grande différence. Comme il s'agit d'un stockage à court terme et qu'il est constamment remplacé, les SSD basés sur Flash ne sont probablement pas une bonne idée.

Le M4000 n'a pas de lots de disques supplémentaires, donc une carte PCI-E serait parfaite, je pourrais aller à l'extérieur ou déplacer des volumes de démarrage vers la CEM et libérer les disques locaux.

Sun vend une carte PCIe Flash Accelerator F20, mais cela semble être un cache pour certains disques SATA, pas une solution SSD DRAM. Les détails sont sommaires, il ne répertorie pas le M4000 comme pris en charge, et je suis fatigué de lutter contre l'arborescence téléphonique de Sun à la recherche d'une aide humaine. :(

Les autres conviennent-ils qu'un SSD DRAM est la solution? Des recommandations matérielles?

MISE À JOUR En plus des informations dans un commentaire ci-dessous, j'ai essayé divers paramètres pour "commit_write" et cela n'a fait aucune différence.

rmeden
la source
Archivez-vous les journaux quelque part? S'ils doivent finalement être copiés du SSD sur le disque, vous pouvez simplement déplacer le goulot d'étranglement vers l'archivage.
Gary
Oui ... les journaux de rétablissement sont archivés et les E / S augmentent en fait à environ 80 Mo / s pendant la copie du journal de rétablissement, car il s'agit d'une écriture séquentielle. J'ai toujours pensé que les journaux de rétablissement étaient séquentiels, mais ne le devinez pas.
rmeden

Réponses:

9

Premièrement - je suppose que vous avez très peu de disques dans le tableau. 1200IOPS peuvent être facilement pris en charge par 12 disques en rotation (100 IOPS par disque est très raisonnable). Si le cache ne peut pas le gérer, cela signifie que votre taux d'écriture soutenu de 1 200 IOPS est bien plus que ce que vos disques peuvent prendre en charge.

Quoi qu'il en soit, le SSD pour les journaux de rétablissement ne sera probablement pas utile. Tout d'abord, votre session attend-elle principalement sur l'instruction COMMIT? Vérifiez les principaux événements d'attente dans statspack / AWR pour le vérifier. Je suppose que ~ 95% de vos E / S ne sont pas du tout dans les journaux de rétablissement. Par exemple, une insertion de ligne unique dans une table avec 5 index peut faire 1 E / S pour lire un bloc de table (qui a de l'espace pour la ligne), lire 5 blocs d'index (pour les mettre à jour), écrire 1 bloc de données, 1 annuler bloc et 5 blocs d'index (ou plus, si les blocs non-feuilles sont mis à jour) et 1 bloc de rétablissement. Donc, vérifiez statspack et voyez vos événements d'attente, vous attendez probablement beaucoup de LECTURES et d'ECRITS pour les données / index. L'attente des lectures ralentit l'INSERT, et l'activité WRITE rend les LECTURES encore plus lentes - ce sont les mêmes disques (BTW - avez-vous vraiment besoin de tous les index? Abandonner ceux qui ne le doivent pas accélérera les insertions).

Une autre chose à vérifier est la définition RAID - est-ce RAID1 (mise en miroir - chaque écriture est deux écritures) ou RAID 5 (chaque écriture est 2 lectures et deux écritures pour le calcul de la somme de contrôle). RAID 5 est beaucoup plus lent en charge gourmande en écriture.

BTW - si les disques ne peuvent pas gérer la charge d'écriture, DBWR sera un goulot d'étranglement. Votre SGA sera plein de blocs sales et vous n'aurez plus de place pour lire de nouveaux blocs (comme les blocs d'index qui doivent être traités / mis à jour) jusqu'à ce que DBWR puisse écrire des blocs sales sur les disques. Encore une fois, vérifiez statspack / awr report / addm pour diagnostiquer quel est le goulot d'étranglement, généralement basé sur les 5 principaux événements d'attente.

Ofir Manor
la source
1
+1 - et je lui donnerais +10 si je le pouvais.
Helvick
2
+1 pour obtenir des conseils afin de voir où se trouve le goulot d'étranglement.
DCookie
Les attentes sont "synchronisation du fichier journal" et "espace tampon du journal". Je peux obtenir environ 150 Mo / s au volume en utilisant DD. Je soupçonne que le LGWR attend la fin d'un IO avant de soumettre le suivant. Le temps de service IO est d'environ 1 ms. L'EMC a un énorme 500 Mo de cache, qui selon EMC ne peut pas être augmenté sans mise à niveau de la boîte entière. Nous avons 22 To dans la baie, pourquoi ils offriraient quelque chose avec si peu de cache me dépasse. Les journaux de rétablissement sont actuellement dans un RAID 5 à 5 étendus, mais il n'y avait aucune différence avec RAID 10 (une autre raison de soupçonner le cache)
rmeden
BTW, s'il y avait plus de cache, le disque pourrait ne pas continuer. En déplaçant le REDO de la baie EMC, cela libère de la capacité pour les disques de données et réduit les E / S de moitié. Un petit SSD DRAM peut être le disque le moins cher et le plus performant car il peut être petit.
rmeden
meden - combien de reprises Oracle écrit-il par seconde? vous avez dit que le nombre total d'E / S est de 12 Mo / s et 1 200 IOPS, ce qui signifie beaucoup de petites E / S (10 Ko en moyenne). Si vous déplacez les journaux de rétablissement sur SSD, vous verrez simplement différents événements d'attente car le DBWR deviendra le goulot d'étranglement et INSERT attendra le tampon libre dans le SGA. Veuillez vérifier - quel type de RAID vous avez, quelle est la taille de la bande et quelle est la taille du bloc Oracle (aussi, vos fichiers de données sont-ils répartis sur tous les disques?). En outre, vérifiez dans statspack la source de la plupart des E / S - est-ce que c'est refaire ou autre chose - vérifiez les E / S par espace de table
Ofir Manor
2

dd n'est rien comparé aux blocs d'E / S.

Pour d'autres vues, vérifiez autour, anandtech.com a fait un test exaustif (accordé avec MS SQL server) avec SAS tournant vs SSD, dans diverses combinaisons, et le monde Solaris a ZFS avec SSD constituant diverses parties (journaux, cache, etc. ).

Mais oui, si RAID 5 vs RAID 10 est le même (pour les écritures), vous faites quelque chose de mal. Avec les écritures linéaires, diable RAID 5 pourrait être plus rapide (c'est-à-dire qu'il peut faire la parité en mémoire, puis écrire les bandes et la parité en une seule fois), mais avec un petit bloc aléatoire (4-8k), vous êtes tué en mettant à jour les bandes (comme noté par d'autres), le raid 10 devrait être plus de 2x plus rapide, sinon, quelque chose ne va pas.

Vous devez creuser plus avant de dépenser de l'argent en matériel.

Ronald Pottol
la source
2

J'ai vu un article sur le montage de partitions UFS en utilisant l'option "forcé directio" et en définissant le paramètre Oracle "filesystemio_options" sur "setall".

Je l'ai essayé et je vois une amélioration de 4 à 5 fois dans les écritures Oracle! Oui!

Les principaux symptômes étaient un faible débit mais de bons temps de réponse sur le disque. Cela semble aider certaines personnes mais pas d'autres. Cela a certainement fait le travail pour moi.

Je peux envisager des SSD pour de nouveaux serveurs, mais ce serveur fonctionne bien maintenant.

Robert

rmeden
la source
La vitesse que vous avez connue n'a probablement pas été provoquée par l'activation des E / S directes, mais par l'activation des E / S asynchrones. Dans Oracle, setall signifie direct + async.
kubanczyk
1

Si cette boîte n'avait été qu'une boîte x86 / 64 fonctionnant sous Linux, j'aurais volontiers recommandé l'une des cartes de lecteur FusionIO PCIe - elles sont incroyablement rapides et ne `` meurent '' pas avec des écritures lourdes comme le font les SSD. Malheureusement, ils ne sont pas pris en charge avec Sparc ou Solaris, vous pouvez cependant les contacter pour en discuter.

Chopper3
la source
1

La carte PCIe F20e est similaire à la fonction Fusion I / O. Il s'agit essentiellement d'un SSD Flash connecté en PCIe. Avec une charge de travail importante en écriture, vous devrez vous soucier à la fois de maintenir suffisamment de blocs libres (via une collecte de déchets basée sur un lecteur) afin de ne pas vous retrouver avec le cycle d'effacement / programme sur le SSD devenant le goulot d'étranglement, ainsi que les cycles d'écriture limités disponibles sur un SSD basé sur Flash. C'est définitivement rapide, mais ce n'est peut-être pas le meilleur kit pour ce travail.

John
la source
tks John. Je ne pensais pas que ça marcherait pour moi. De toute façon, Sun ne le prend même pas en charge sur un M4000. :(
rmeden