> Mais quel différence entre mettre la barrière de synchro au niveau de l'OS ou de tricher au niveau disque ?
Je ne sais pas... mais il faut dire que je n'ai pas compris la question ;)
> J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.
Je réitère la remarque ci-dessus : s'il ne les honore pas, il perds des données qu'il a prétendu écrire en cas de crash système ou de cable d'alim (UPS ou pas). La panne électrique n'est pas le seul malheur qui peux frapper un serveur écrivant en asynchrone.
Avec ext3, l'intervalle par défaut de commit des dirty pages est de 5 secondes : ça peux représenter un bon paquet de transactions perdues...
Un autre aspect à évoquer : les SGBDS s'efforcent de garantir la persistance de toutes les données commitées (le D de ACID) via fsync() (et c'est bien ce qui les rends gourmands en IOPS). Mais en pratique, pour une application donnée, il n'est pas rare que ce besoin de garantie de persistance ne soit vraiment impérieux que pour une toute petite fraction des écritures. Par ex. sur une appli web de commerce, c'est souvent une garantie nécessaire lorsqu'un utilisateur valide un achat en ligne, souvent moins nécessaire lorsqu'il met à jour des infos sur son profile, poste un commentaire, lorsqu'on stocke les stats de visites par page, etc. (moins impérieux = au sens où on la perte de quelques minutes de données tout les un ou deux ans (interval de crash système) n'est pas un drame si elle permet en contrepartie de multiplier les perfs du système par 10). La tradition et les applications classiques utilisant un SGBD tendent à tout stocker de façon synchrone, sans distinction, ce qui est souvent un gros gaspillage de ressources les plus précieuses (les I/O), bien sûr.
D'où l'émergence de solutions mixtes (SGBD relationnel + stockage asynchrone), ou l'utilisation d'extensions comme le "insert delayed" de mysql (mais n'a pas d'équivalent pour update et delete)... Je rejoint donc ta remarque sur l'utilité d'une marge de tricherie en disant qu'il serait bien utile de pouvoir, transaction par transaction, indiquer à l'OS s'il doit vraiment honorer une écriture de façon synchrone ou pas. Les besoins d'une appli de type "web social" à fort traffic ne sont généralement pas exactement ceux d'un système bancaire.
[^] # Re: Stockage en RAM
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 3.
Je ne sais pas... mais il faut dire que je n'ai pas compris la question ;)
> J'ai l'impression que l'OS voyant des fsync() partout se sent obliger des les honorer rapidement, alors qu'il y en aurait pas besoin avec un APS.
Je réitère la remarque ci-dessus : s'il ne les honore pas, il perds des données qu'il a prétendu écrire en cas de crash système ou de cable d'alim (UPS ou pas). La panne électrique n'est pas le seul malheur qui peux frapper un serveur écrivant en asynchrone.
Avec ext3, l'intervalle par défaut de commit des dirty pages est de 5 secondes : ça peux représenter un bon paquet de transactions perdues...
Un autre aspect à évoquer : les SGBDS s'efforcent de garantir la persistance de toutes les données commitées (le D de ACID) via fsync() (et c'est bien ce qui les rends gourmands en IOPS). Mais en pratique, pour une application donnée, il n'est pas rare que ce besoin de garantie de persistance ne soit vraiment impérieux que pour une toute petite fraction des écritures. Par ex. sur une appli web de commerce, c'est souvent une garantie nécessaire lorsqu'un utilisateur valide un achat en ligne, souvent moins nécessaire lorsqu'il met à jour des infos sur son profile, poste un commentaire, lorsqu'on stocke les stats de visites par page, etc. (moins impérieux = au sens où on la perte de quelques minutes de données tout les un ou deux ans (interval de crash système) n'est pas un drame si elle permet en contrepartie de multiplier les perfs du système par 10). La tradition et les applications classiques utilisant un SGBD tendent à tout stocker de façon synchrone, sans distinction, ce qui est souvent un gros gaspillage de ressources les plus précieuses (les I/O), bien sûr.
D'où l'émergence de solutions mixtes (SGBD relationnel + stockage asynchrone), ou l'utilisation d'extensions comme le "insert delayed" de mysql (mais n'a pas d'équivalent pour update et delete)... Je rejoint donc ta remarque sur l'utilité d'une marge de tricherie en disant qu'il serait bien utile de pouvoir, transaction par transaction, indiquer à l'OS s'il doit vraiment honorer une écriture de façon synchrone ou pas. Les besoins d'une appli de type "web social" à fort traffic ne sont généralement pas exactement ceux d'un système bancaire.