"20 000 IOPS par nœud sont de bonnes performances avec une latence de 5 ms." Pour OLTP - non

La raison de la rédaction de cet article était un examen très utile de la façon dont nous avons testé VMware vSAN ... CROC. La critique en vaut la peine, mais elle contient une phrase avec laquelle je me bats depuis plus d'une décennie. Les administrateurs de stockage, les virtualiseurs et les intégrateurs répètent encore et encore: "Les délais de 5 ms sont un excellent indicateur." Même le chiffre de 5 ms pendant dix ans ne change pas. J'ai entendu cela en direct d'administrateurs très respectés pas moins d'une douzaine de fois. De moins respecté - des dizaines, et combien de fois j'ai lu sur Internet ... Non, non, non. Pour les charges OLTP de 5 ms, d'autant plus qu'elles sont généralement mesurées, ce sont des échecs épiques. J'ai dû expliquer les raisons de cela à plusieurs reprises, cette fois j'ai décidé de rassembler mes pensées sous une forme réutilisable.

Je dois dire tout de suite qu'il n'y a pas de telles erreurs dans l'article mentionné ci-dessus, plutôt que la phrase a fonctionné comme déclencheur.

Début typique

Tout ce qui est décrit dans cet article s'applique aux SGBD courants utilisés pour les OLTP d'entreprise classiques. Surtout, j'ai de l'expérience avec MS SQL Server, mais, au moins pour PostgeSQL, Oracle et Sybase, de nombreux points et conclusions resteront également vrais.

Les SGBD de performance sont généralement mécontents de tout le monde. S'il y a un SGBD dans un grand système - et il est soudainement presque toujours là - alors ce SGBD est un goulot d'étranglement. Eh bien, ou cela deviendra immédiatement un goulot d'étranglement si vous commencez à optimiser tout le reste. Et donc, le client vient et dit d'une voix humaine: "Aide! Économise! Ils ont payé $ NNNNNNNN pour le serveur et le stockage, mais la vitesse n'augmente pas! Oh, et l'administrateur s'est installé et le vendeur a consulté, mais ne bouge toujours pas." Si les développeurs du système correspondent à la définition de Lavrov (nous pouvons nous passer d'un devis exact) et que les spécialistes de l'exploitation et de la maintenance «luttent contre les incidents en redémarrant le serveur», alors le problème est souvent simple et sans prétention: il n'y a pas d'index, de requêtes tordues, d'erreurs de configuration fatales (à propos desquelles la documentation est en gras il dit "vous ne pouvez pas faire ça !!!" ), des verrous excessifs, des blocages et autres bêtises simples et claires. Il existe de nombreux cas de ce type, la plupart, mais pas tous. Si le système, en complexité ou en charge, a franchi une limite invisible, alors il mourra de ces problèmes ou passera au niveau suivant.

À ce niveau, le serveur n'est plus sous la table du directeur, les disques ne sont plus à l'intérieur du serveur, mais dans le système de stockage, les développeurs connaissent les index et les administrateurs connaissent déjà PowerShell, et les responsables informatiques commencent à dire des mots intelligents comme SLA et RPO / RTO. Une situation intéressante se présente à ce niveau:

• Le SGBD est un goulot d'étranglement.
• Le serveur semble être suffisant à tous égards.
• Le SGBD peut être encore amélioré par programme, mais il est difficile (soit de passer à des licences plus chères, soit de passer à la "zone rouge de la courbe Shipilev" pour l'optimisation)
• Le système de disques est acheté cher et, semble-t-il, est même en quelque sorte configuré.

Mais non. Le crocodile n'est pas pris, la noix de coco ne pousse pas et les performances du système sont identiques ou inférieures à celles de l'ancien serveur. Je regarde dans sys.dm_os_waitsats et vois WRITELOG , PAGEIOLATCH_SH et PAGEIOLATCH_EX en haut, le temps d'attente moyen est de 5+ ms. Eh bien, typique, cho: "Hé, les administrateurs et DBA, ici vous avez un système de disque - goulot d'étranglement" et ici commence une vieille chanson d'environ 5 ms:

• Nous avons 5 ms pour SLA
• Oui, nous avons un régiment de 20 000 IOPS
• Le vendeur nous a dit que tous les fichiers de base de données peuvent être sur une seule partition
• Nous avons la virtualisation et l'hyperconvergence et nous ne pouvons pas allouer de disques séparés sous la base de données
• Selon nos données, utilisation du serveur 5%
• Tout est configuré selon les recommandations
• Vos bases de données n'ont pas besoin de beaucoup de performances, elles ne font pas plus de 300 IOPS (et nous avons une étagère pour 20 000 IOPS)

Soit dit en passant, tout ce qui précède, non seulement sur "leurs" serveurs, mais aussi sur les services cloud et la virtualisation. Il y a un tas de ses spécificités, mais le tableau clinique typique est à peu près le même: base de données modérément optimisée, personnel de développement et de maintenance intelligent, il y a une réserve pour le processeur et la mémoire, le "pot d'échappement" des investissements futurs est presque nul.

Alors voilà. Toute cette chanson sur "5 ms" est un non-sens et un non-sens. Si vous le dites vous-même, lisez cet article. Et s'ils vous le disent, préparez les arguments. Avant, quand j'ai entendu ces mots, j'étais en colère, mais je ne suis plus en colère. Moi, comme ce pot avec un pétunia du Guide de l'auto-stoppeur de la galaxie, je n'ai qu'une seule pensée: "Eh bien, encore une fois ...".

Qui est à blâmer?

Pourquoi la base de données est-elle si lente? Eh bien, il semblerait qu'un serveur typique avec 20 à 64 cœurs à une fréquence de 2 à 3 GHz est capable d'effectuer 50 à 150 milliards d'opérations simples, et les tests de base de données (synthétiques) maximaux ne montrent sur ces machines que 10 000 à 5 000 transactions par seconde. Hé! Eh bien, cela représente un million à une douzaine de millions de transactions possibles par transaction. Ce n'est pas seulement beaucoup, c'est beaucoup à ressentir.
Ces frais généraux ont coûté les exigences ACID pour les transactions.

• Une tomicité - soit l'ensemble de la transaction est terminée, soit l'ensemble n'est pas terminé.
• Cohérence - à l'entrée et à la sortie d'une transaction, le système est dans un état cohérent
• I solation - les transactions ne voient pas les états intermédiaires de l'autre
• D urabilité - si la transaction a été effectuée avec succès (validée), alors, quelles que soient les circonstances, les modifications apportées doivent rester dans le système.

Soit dit en passant, lettre par lettre, ces exigences ne sont pas remplies presque partout et jamais, mais simplement jamais dans les systèmes distribués (le théorème CAP interfère). Pour notre situation, l'exigence «D» est plus susceptible d'être plus chère que d'autres, cette exigence est fournie par le mécanisme clé de tous les SGBD OLTP courants: WAL, journal d'écriture anticipée (PostgeSQL), c'est aussi un journal de transactions (SQL Server), alias journal REDO (Oracle). Le voici - une pierre sur le goulot de la productivité, et c'est le fondement des transactions de durabilité.

Qu'est-ce que le WAL?

Oublions un instant les SSD modernes, les systèmes de stockage sympas. Supposons que nous ayons un serveur, il a un ou plusieurs disques.
Toute transaction, même l'insertion d'un enregistrement, est au moins potentiellement, mais en fait presque toujours et de manière réaliste une action non atomique. Nous devons presque toujours changer non seulement la page où se trouve l'enregistrement, mais aussi les pages d'index, éventuellement les pages de service. De plus, dans la même transaction, la même page peut changer plusieurs fois. De plus, d'autres transactions peuvent être effectuées en parallèle avec nous. De plus - les transactions voisines dans le temps "tirent" constamment les mêmes pages. Si nous attendons que chaque page soit écrite sur le disque avant de continuer, ce qui est essentiellement ce que la durabilité exige, nous devrons écrire plusieurs fois plus et attendre que chaque enregistrement soit terminé sur un support non volatile. Pas de caches, pas de réarrangement des opérations dans la file d'attente, sinon il n'y aura pas d'intégrité! De plus, nous devons en quelque sorte noter quelles données sont déjà sur des transactions fixes et lesquelles ne le sont pas encore (et quelles données étaient antérieures). Pour la compréhension - un disque dur unique typique (HDD) dans ce mode donnera 50-100 IOPS et cela a été une constante pendant 20 ans. Une petite transaction nécessitera 5 à 10 opérations d'écriture. Ah oui, pour savoir quoi enregistrer, il faut le lire. Même les systèmes OLTP très, très inscriptibles lisent 3 fois plus qu’ils n’écrivent. Ainsi, notre transaction coûte entre 20 et 40 E / S, ce qui signifie 0,2 à 0,8 seconde par disque.
2 transactions par seconde. Pas assez? Essayons de disperser les disques? Oh, mais nous devons encore attendre que le précédent soit enregistré et qu'il n'y ait pas de parallélisme à la fin. Comment être Et commençons un fichier journal dans lequel nous enregistrerons séquentiellement toutes les opérations d'écriture dans la base de données et les marques de transaction! Avantages:

• Les informations sur l'opération peuvent être beaucoup plus compactes que l'enregistrement de la page entière (une taille de page typique est de 8 Ko, les informations écrites dans le journal sont souvent de 0,5 à 1 Ko).
• Au lieu d'écrire si la transaction est enregistrée ou non directement sur la page, il y a suffisamment d'étiquettes sur le début et la fixation de la transaction dans le journal.
• Les pages ne peuvent pas être écrites après chaque transaction - plusieurs fois moins. Le processus de lecture / écriture des données est complètement "délié" du journal.
• L'essentiel. Si nous plaçons notre journal sur un disque séparé et écrivons des enregistrements séquentiellement, du fait que vous n'avez pas besoin de repositionner constamment les têtes de disque, même un disque dur domestique dans ce mode réduit jusqu'à 1000 IOPS, étant donné que les petites transactions "coûtent" 2-4 entrées de journal, alors vous pouvez presser 200-400 TPS
• En cas d'échec, l'état du fichier de données peut être restauré à l'aide d'un tel journal et si une transaction est annulée, les modifications peuvent être annulées.

Un tel journal est appelé journal d'écriture anticipée / journal des transactions / journal REDO.

Hourra! Super! Il y avait 2 transactions par seconde, il est devenu 300 - amélioré 150 fois. Et à quel prix? Il s'avère que le prix est important:

• Dans tous les SGBD courants, la journalisation est strictement cohérente. Un thread est responsable de l'écriture dans le journal. Avez-vous 100 processeurs? Cool. Et le journal écrit toujours un thread. La profondeur de la file d'attente est exactement une.
• Toujours - pas de caches OS, pas de permutations d'opérations. Les exigences de durabilité sont restées. Opérations d'écriture: jusqu'à ce que le disque réponde "J'ai écrit, je l'ai écrit directement à la surface, pas dans le cache, c'est sûr" Le SGBD ne continue pas de fonctionner.
• Si vous placez le fichier journal sur le disque de données, presque tous les avantages de l'enregistrement séquentiel seront perdus. De plus - pour de bon, s'il y a plusieurs bases de données sur le serveur, puis plusieurs disques pour les magazines.
• Restauration de transaction (au moins dans MS SQL Server) - lisez le journal et restaurez-en l'état. Il s'agit d'autant d'opérations d'écriture, voire plus, que d'opérations d'écriture dans la transaction. Le retour en arrière coûte cher!

Cette explication est très simplifiée, "sur les doigts". Cela suffit pour notre sujet. Le WAL est un mécanisme clé et fondamental pour garantir la transactionnalité, il est nécessairement écrit, l'accès est monothread uniquement pour l'enregistrement séquentiel, du point de vue du stockage, la profondeur de la file d'attente est de 1.

Le sujet de la journalisation en écriture anticipée dans la base de données doit être au moins minimal connu de toute personne qui, d'une manière ou d'une autre, administre le SGBD ou l'infrastructure du SGBD ou développe des bases de données.

WAL et SHD

Les fabricants de stockage «dès la naissance» sont confrontés au SGBD. C'est pour les bases de données que les entreprises achètent ces complexes incroyablement chers: à partir des stockages de prix de rue de Dell-EMC, HP, Hitachi, NetApp, lors de la conception d'un budget, les yeux sont remplis de larmes de la plupart des cadres supérieurs, à moins, bien sûr, qu'ils n'obtiennent un pourcentage de ce prix. Mais il y a un conflit d'ingénierie et de marketing. Je vais l'expliquer en utilisant l'exemple de Dell-EMC, mais uniquement parce que je me souviens où ils ont la documentation.

Donc:

1. Journal à fil unique
2. Le journal d'écriture, c'est-à-dire la latence, est "éternel" par rapport aux performances du processeur
3. Les charges OLTP sont beaucoup de transactions relativement petites,
4. La plupart des autres charges SGBD sont parallèles d'une manière ou d'une autre.

La loi d'Amdahl nous dit sans pitié qu'une charge basse performance à un seul thread rendra inutile l'ajout de processeurs, et les performances seront déterminées par le journal. De plus, en ce moment, nous ne nous soucierons pas des performances de stockage dans les IOPS, et seule la latence deviendra importante.
Mais ne négligez pas les autres opérations sur le disque - lecture et écriture dans les fichiers de données et tempdb . La lecture est également une opération "en attente". Tant qu'une page de données n'est pas lue du disque dans la mémoire, le processeur ne peut pas la traiter. Mais pour ces opérations, de grandes files d'attente et la permutation des opérations dans cette file d'attente sont possibles: le SGBD sait souvent quelles pages charger en mémoire, quelles pages à vider et met beaucoup de files d'attente pour la lecture à la fois. Étant donné que dans ce scénario, il est important lorsque la dernière opération du bundle se termine, dans cette charge, au contraire, l'IOPS est plus important pour nous que la latence d'une seule opération. Pour comprendre la portée: les opérations de lecture dans un système OLTP typique sont de 85% à 95%. Oui, oui, oui, les opérations d'écriture sont un ordre de grandeur moins.

Les ingénieurs de stockage des fournisseurs travaillent en étroite collaboration avec les fournisseurs de SGBD et connaissent bien toutes les nuances techniques du fonctionnement d'un SGBD avec un sous-système de disque. Une bonne planification, partitionnement et allocation des ressources disque pour le SGBD est une compétence complexe et importante de l' administrateur du système de stockage . Le même Dell-EMC a même le livre blanc de base H14621 et H12341 pour les recommandations de partitionnement pour SQL Server - plus d'une centaine de pages. Hé! Ce n'est pas un dock détaillé, c'est le livre blanc le plus courant! Il y en a encore plein de spécifiques ( h15142 , h16389 ... il y a de l'obscurité là-bas). Les «contigus» de VMware - Architecture de Microsoft SQL Server sur VMware vSphere ne sont pas loin derrière. Veuillez noter que ces documents ne sont pas seulement et pas tant pour les administrateurs de base de données que pour les administrateurs d'infrastructure et de stockage.
Je note également que dans tous ces documents, des LUN séparés sont coupés pour les données, les journaux et tempdb . Oui, quelque part dans les derniers documents, ils disent clairement que pour les solutions All-Flash, cela n'a aucun sens de séparer les journaux sur des supports physiquement séparés, mais les LUN proposent toujours de les couper séparément. Si vous transférez des données et vous connectez dans un LUN, du point de vue du système d'exploitation, ce sera une file d'attente IO. Et il y aura un problème. Les opérations de latence auront immédiatement un ordre de grandeur de plus. Et du fait que des opérations de journalisation non déplaçables apparaîtront dans la file d'attente, IOPS glissera sur les fichiers de données et tempdb . Ce n'est pas une "découverte du siècle", c'est une vérité élémentaire de travailler avec la base de données. Il n'est pas obsolète ni annulé avec l'avènement de All-Flash. Oui, les retards dans les opérations avec les disques SSD sont plus rapides d'un ordre de grandeur que dans les opérations avec les disques durs, mais toujours deux fois plus lents que les opérations avec mémoire. IO est toujours le goulot d'étranglement du SGBD.
Et les documents techniques soulignent correctement que dans les journaux de transactions, le nombre d'IOPS n'est pas important, mais il est important que la latence soit minimale (dans les temps modernes, il est écrit moins de 1 ms).

Mais les commerçants doivent vendre. Hyperconvergence! Virtualisation! Flexibilité de déploiement! Déduplication! Configuration facile! Beaucoup, beaucoup d'IOPS! Belles présentations, voix confiante, costumes formels. Mais comment vendre autrement une solution avec un prix de 6 à 7 chiffres en dollars? Pour cela, on oublie en quelque sorte que la latence ou le débit peuvent être obtenus à partir du système de stockage, mais pas les deux à la fois, qu'une sorte de licence pour l'équilibreur de charge est comme une autre étagère, que si l'enregistrement intensif dure plus d'une heure, alors la RAM des contrôleurs ce n'est pas suffisant et la productivité descendra "comme s'il n'y avait pas de cache", que la formation des employés du client coûte encore 100 000 roubles pour la première année, eh bien, de telles astuces ...

5 ms

Soit avoir beaucoup entendu parler de la lecture des spécialistes du marketing, soit de la paresse, soit à cause d'une sorte de cafards, mais pour une raison quelconque, les administrateurs de stockage font souvent quelque chose comme ça. Nous prenons une grande étagère, combinons le tout en quelque chose de plat, le coupons en LUN provisionnés fins et le distribuons par LUN au serveur. Ou deux, parce que "la partition système est bien dédupliquée". Et quand, je vois qu'avec le sous-système de disque du côté de l'enfer-enfer-enfer SQL, alors la chanson commence que "5 ms est un excellent indicateur", que "100000 IOPS", "Votre charge de stockage est inférieure à 5%"

Non .

• Pour les systèmes OLTP sur une partition avec WAL / journaux de transactions de 5 ms, il s'agit d'un indicateur non valide. Sur le morceau de fer "presque marchandise" pour un prix de 1000 (en mots: mille) fois moins cher, l'indicateur normal sera désormais 0,1-0,3 ms. Et demain - 0,01 ms. La vitesse, comme celle du disque dur 2008, au prix de toute une entrée d'appartements à Moscou, n'est pas nécessaire. Aucune «facilité d'entretien» n'en vaut la peine.
• Le fournisseur écrit-il que les journaux de transactions n'exigent pas d'IOPS et peuvent-ils être placés sur le disque dur? Oui. Mais pour cela, il est nécessaire qu'aucun de ces disques contagion En plus d'écrire des journaux, le SGBD n'a pas touché la tâche. Et pour que le système de stockage réponde au serveur que les données sont écrites, immédiatement lorsque les données sont entrées dans la mémoire non volatile (c'est beaucoup plus tôt qu'elles ne seront écrites)
• Les disques minces pour les vraies bases de données OLTP sont mauvais.
• Pour WAL, il n'est absolument pas intéressant de savoir combien d'IOPS peut être compressé à une profondeur de file d'attente de 10 ou 20. Il n'y a pas de profondeur là-bas.
• Pour WAL, ce n'est absolument pas un indicateur que la file d'attente d'E / S dans le système d'exploitation est «seulement environ 1». Elle ne sera plus.
• Non, les développeurs DBA et DB ne sont pas des "pics excentriques qui ne peuvent pas correctement configurer pour écrire sur le parallèle WAL" (avis réel de l'administrateur)
• La logique des fans de considérer le recyclage "puisque votre système que nous avons configuré de manière tordue dans une partition ne fait pas 10 000 IOPS, alors il doit être déplacé d'une baie haut de gamme vers le milieu de gamme" - c'est une logique incorrecte.
• Si le serveur à 40 cœurs a une charge de processeur de 2,5%, cela ne signifie pas qu'il n'a rien à faire, mais, très probablement, signifie qu'il existe une sorte de tâche qui bloque tout le monde.

Lorsque le chargement de certaines données sur l'ordinateur portable du développeur prend 5 minutes, et sur le 40e serveur nucléaire avec 1 TiB de RAM et un stockage pour un demi-million de dollars, la même tâche est effectuée pendant une heure, même les clients les plus patients auront des questions sur la faisabilité des coûts.

Que faire

Conseils d'administration et DBA

Pour OLTP, arrêtez de compter «recyclage» et IOPS. Séparément, je note - ne regardez pas du tout les IOPS avec de grandes profondeurs de file d'attente: même sur les partitions de données, les grandes files d'attente ont généralement une courte rafale ou quelque chose qui n'affecte pas les performances réelles d'OLTP.

Le partage d'espace disque par LUN n'est pas un caprice DBA. La base de données possède plusieurs profils de chargement de sous-système de disque différents. Au minimum, on peut distinguer:

• Travaillez avec des fichiers de données. Il s'agit généralement de lire et d'écrire avec des blocs aléatoires de 8/64 Ko. Lectures 80-95%. Des files d'attente surviennent: pendant les périodes de service, pendant les périodes de chargement en vrac, sur des demandes inefficaces ou massives, et pendant le point de contrôle. La performance est affectée par la réactivité à la lecture. Il est important que l'alignement des blocs 8/64 KiB «à travers» passe par l'ensemble du système de stockage.
• Travailler avec tempdb est le même que travailler avec des fichiers de données, mais les lectures sont généralement de 40 à 75% et la réactivité en écriture peut être importante. Dans les systèmes MS SQL modernes, cette base de données peut être chargée plusieurs fois plus fort que les bases de données. Dans une configuration de SGBD non en cluster, cette section doit être exclue de toute réplication de stockage. Son contenu après le redémarrage du service sera toujours détruit.
• Travailler avec des données archivées / DWH. Les lectures sont proches de 100%. La taille d'un bloc de lecture est généralement de 64 Ko. Les demandes sont lues beaucoup et d'affilée, de sorte que la file d'attente peut sauter jusqu'à 1000 ou plus.
• Travaillez avec les journaux de transactions. La lecture est uniquement destinée à la maintenance (sauvegarde, réplication, etc.), les performances des applications ne sont affectées que par l'écriture. Enregistrement en blocs de 0,5 à 64 Ko. Sans file d'attente, dans un seul fil. Le délai est critique pour les applications.
• Sauvegarde et restauration. Du point de vue de la base de données, on lit en gros blocs (souvent 1 Mio). Il est important que cette charge puisse reposer sur les canaux / bus (FC et Ethernet) et sur les performances des processeurs de stockage dans certains cas. La sauvegarde d'un serveur peut affecter les performances des autres serveurs du même SAN / SHD.
• Travailler avec des fichiers d'application: ce sont les journaux, la trace par défaut, les fichiers binaires, etc. Cette charge est rarement importante et n'est importante qu'au début du système.

Il existe d'autres types de charge, mais ils sont légèrement exotiques (par exemple, il peut y avoir un référentiel de fichiers stockés dans la base de données sous la forme du répertoire FileStream). Tous ces types de charges ont des exigences de disque différentes, souvent conflictuelles. S'ils sont tous empilés sur une partition, vous dégrade non seulement les performances, mais il est très important que vous perdiez la capacité de comprendre pourquoi le système ralentit, et vous perdez également la possibilité d'améliorer uniquement la partie qui a besoin d'amélioration sans améliorations / mises à niveau globales du stockage. Par conséquent, la principale recommandation:

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . C'est correct. . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

C’est tout. . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .