Le noyau synchronize le mmap sur disque dans l'ordre qu'il veut, sa méthode est foireuse de base. Il faut qu'il duplique toute ses opérations d'écriture séquentiellement dans un fichier à côté (+crc), aka un "journal", et fasse des msync(SYNC) régulier de son mmap + fsync/close de son journal, et après il peut continuer. C’est une DB RAM-only, ça a été codé en plein de version dans quasiment toutes les industries & start-up du monde. Il existe plein de variantes pour gérer la transition (le… commit). Dès qu'il aura de la pression mémoire (dirty_ratio toussa), il va commencer à voir tout ça. Jusqu’ici il n'a mesuré que le débit de sa RAM (dans le meilleur des cas). Il va aussi voir que MADV_NOSYNC n'est disponible que sous BSD (donc devoir faire finalement un MAP_ANONYMOUS et gérer les I/O lui-même).
Bref, une base ACID en 200 lignes de code, threadsafe avec les latences/débits annoncés, c'est pas le bon jour.
[^] # Re: Ai-je bien compris ?
Posté par riba . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 8.
Le noyau synchronize le mmap sur disque dans l'ordre qu'il veut, sa méthode est foireuse de base. Il faut qu'il duplique toute ses opérations d'écriture séquentiellement dans un fichier à côté (+crc), aka un "journal", et fasse des msync(SYNC) régulier de son mmap + fsync/close de son journal, et après il peut continuer. C’est une DB RAM-only, ça a été codé en plein de version dans quasiment toutes les industries & start-up du monde. Il existe plein de variantes pour gérer la transition (le… commit). Dès qu'il aura de la pression mémoire (dirty_ratio toussa), il va commencer à voir tout ça. Jusqu’ici il n'a mesuré que le débit de sa RAM (dans le meilleur des cas). Il va aussi voir que MADV_NOSYNC n'est disponible que sous BSD (donc devoir faire finalement un MAP_ANONYMOUS et gérer les I/O lui-même).
Bref, une base ACID en 200 lignes de code, threadsafe avec les latences/débits annoncés, c'est pas le bon jour.