Quand il s'agit d'optimiser le système pour des performances maximales, il peut être très facile de faire des erreurs si vous appliquez imprudemment les pratiques des autres. L'une de ces pratiques consiste à spécifier nobarrier lors du montage de systèmes de fichiers.
Comment est née cette note
Je travaille en tant qu'ingénieur chez Mail.Ru Cloud Solutions et traite principalement toutes sortes de problèmes «autour et autour» du stockage en bloc sur lequel se trouvent les machines virtuelles de nos utilisateurs - et, en conséquence, des cas intéressants se posent souvent liés aux performances et à la stabilité des machines virtuelles fonctionnant dans applications - et en particulier les bases de données.
En règle générale, dans presque la moitié des cas pendant le «débriefing», nous voyons la même chose - un système de fichiers monté avec l'option nobarrier. Et quand nous demandons - "pourquoi avez-vous écrit cette option", alors nous obtenons presque toujours l'une des options de réponse "on m'a dit que c'était plus rapide / j'ai lu que c'était plus rapide / j'ai été configuré comme ça" - après quoi nous essayons poliment et soigneusement d'expliquer cela Donc pas besoin. Pourquoi? Parce que c'est la première étape confiante sur la voie de la perte de données.
Petite excursion
Système de fichiers - la structure est très complexe et très chargée. Pour garantir des performances maximales, la mise en cache et l'enregistrement parallèle sont activement utilisés dans le processus. En conséquence, une partie des données va dans le cache et est supprimée chaque fois que cela est possible / nécessaire ou «à la demande». Une barrière est une opération spéciale pour forcer le vidage de tous les caches sur le disque.
En ce qui concerne les bases de données, nous devons être sûrs que la transaction confirmée au client (application client) a été persistante et ne disparaîtra pas, d'une part, et d'autre part, les SGBD utilisent activement leur propre cache pour obtenir des performances maximales - et pour garantir la cohérence, la journalisation est utilisée - la modification est écrite dans le journal, le journal est «synchronisé», puis la modification est écrite dans les données (et lorsqu'elle est écrite, elle entre dans le cache). Lorsque le journal est plein, une synchronisation forcée est effectuée sur toutes les données du cache et le journal recommence à se remplir.
Opération de synchronisation
Lorsque la synchronisation est exécutée, le système d'exploitation vide non seulement le cache de page, mais envoie par défaut une commande pour vider tous les caches de disque (et, éventuellement, le fait à plusieurs reprises) - le soi-disant
rincer . L'opération de vidage des tampons est «coûteuse» et prend beaucoup de temps - mais elle est nécessaire, car dans les systèmes de fichiers, l'ordre d'écriture est important - s'il est violé, alors (par exemple) il peut s'avérer que lors d'un redémarrage soudain du fichier, il y aura des ordures au lieu de données - puisque l'appareil a décidé de réorganiser le disque. Et lorsque le rinçage vide tous les caches de force - cela garantit que tout ce qui est avant le rinçage est écrit, et ensuite seulement ce qui s'est passé après - c'est-à-dire qu'une «barrière» est créée divisant les entrées en «avant la barrière» et «après la barrière» (à partir d'ici et le nom «barrière d'écriture») - et cela permet de garantir que les enregistrements après la barrière ne seront pas appliqués plus tôt que les enregistrements avant la barrière.
Effet Nobarrier
L'option nobarrier désactive l'envoi de vidage forcé pendant que le système de fichiers est en cours d'exécution. Cela conduit au fait que les enregistrements peuvent être réorganisés - et si une défaillance se produit, le système de fichiers (et généralement les données dans le cas général) peut ne pas être cohérent - rappelons ce qui a été mentionné dans le paragraphe précédent sur l'ordre d'enregistrement.
Pourquoi cette option est-elle incluse? Pour les SSD à faible coût, l'opération de vidage est très coûteuse - par exemple, les SSD à faible coût (et de nombreux coûteux qui sont positionnés en tant que «serveurs») effectuent 10 à 20 000 opérations d'écriture par seconde sans vidage, et avec vidage activé, ils tombent à 1 à 2 000. Dans de tels cas, nobarrier fournit une amélioration significative des performances, créant les risques pour l'intégrité des données décrits ci-dessus.
Environnement virtuel
Dans le cas d'une machine virtuelle - si, par exemple, nous parlons de la configuration classique de machines virtuelles sur un hyperviseur Linux, nous avons QEMU - un processus qui est en fait responsable de l'émulation des E / S pour le système d'exploitation invité. Et surtout, si nous utilisons des disques non sauvegardés dans une machine virtuelle, le cache d'un tel disque virtuel (soudain!?) Se trouve dans l'espace utilisateur - dans l'espace adresse du processus QEMU correspondant. Et si ce processus se bloque - par exemple, selon SEGFAULT / SIGSEGV - alors tous ses caches mourront avec lui. Un exemple d'un tel pilote de périphérique de bloc est le pilote RBD (Ceph).
Et même si vous n'utilisez pas Ceph mais iSCSI / FC, par exemple, le niveau de défaillance ne disparaît pas - il passe simplement de QEMU au système d'exploitation hôte (hyperviseur). L'hyperviseur est tombé - son cache de page est mort (cela est vrai pour io = 'threads' en combinaison avec cache = 'writeback' ou cache = 'unsafe'). Oups
s / Cloud / Ordinateur étranger / g
Lorsque votre machine virtuelle est déployée dans le cloud ... Ensuite, vous ne savez pas comment l'hyperviseur est configuré, comment QEMU est configuré, quels pilotes de disque sont impliqués, si le cache de la page hôte fonctionne, etc., et vous ne pouvez pas influencer cela dans la grande majorité des cas. Et même si c'est votre cloud - où vous savez tout cela et le contrôlez plus ou moins, ce n'est pas du tout un fait que votre hyperviseur ne «tombera» pas - enterrant tout le cache de données.
Résumé
L'utilisation de nobarrier dans le cloud signifie que vous risquez fort de mettre vos données en danger. Êtes-vous sûr de vouloir réaliser des gains de productivité au prix de ces risques?