{"id":5286,"date":"2016-05-12T16:39:16","date_gmt":"2016-05-12T15:39:16","guid":{"rendered":"http:\/\/blog.capdata.fr\/?p=5286"},"modified":"2019-09-13T13:12:52","modified_gmt":"2019-09-13T12:12:52","slug":"pas-de-la-tarte","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/pas-de-la-tarte\/","title":{"rendered":"Pas de la tarte"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Non vraiment, \u00e7a va pas \u00eatre de la tarte. Et si vous vivez dans une grotte depuis le d\u00e9but de l’ann\u00e9e, vous ne savez peut \u00eatre pas encore que SQL Server doit \u00eatre port\u00e9 sur Linux<\/a>.<\/p>\n

D’ailleurs mister Slava Oks<\/a>, le grand gourou de l’allocation m\u00e9moire dans SQLOS, est revenu au bercail<\/a> pour pr\u00eater main-forte \u00e0 l’\u00e9norme chantier pr\u00e8s de 10 ans apr\u00e8s avoir quitt\u00e9 la dream team du building 35. C’est un signe qui ne trompe pas.<\/p>\n

On a une id\u00e9e relative du quand<\/em> (mi-2017), on a d\u00e9j\u00e0 beaucoup \u00e9voqu\u00e9 le pourquoi<\/em>. Il est encore trop t\u00f4t pour parler du comment<\/em>. Tout ce qu’on peut formuler pour l’instant ce sont des hypoth\u00e8ses. C’est ce qu’on va faire, essayer de voir o\u00f9 peuvent \u00eatre les grandes difficult\u00e9s de porter SQL Server sur linux, de notre humble point de vue d’utilisateur – disons –\u00a0\u00e9clair\u00e9<\/em> du produit.<\/p>\n

Pourquoi \u00e7a semble compliqu\u00e9:<\/span><\/strong><\/p>\n

Parce que globalement le code de SQL Server a une adh\u00e9rence tr\u00e8s forte avec les primitives win32, et le sous-syst\u00e8me du m\u00eame nom (subsystem win32 = kernel32.dll + advapi32.dll + gdi32.dll + user32.dll). Ces primitives exposent \u00e0 SQL Server tout un framework pour adresser des appels au noyau par exemple :<\/p>\n

– Ouvrir, \u00e9crire, lire, \u00e9tendre, r\u00e9duire un\u00a0fichier…
\n– Ouvrir une socket TCP, \u00e9couter sur un port TCP.
\n– Allouer et acc\u00e9der \u00e0 des pages en m\u00e9moire.
\n– Synchroniser les acc\u00e8s \u00e0 des ressources partag\u00e9es (principalement des listes cha\u00een\u00e9es de ressources, par exemple les BUFs<\/em>, mais aussi des IO r\u00e9seau ou disque…)<\/p>\n

La plupart de ces actions ne peuvent pas se faire au niveau utilisateur (en ring 3<\/a>), donc Windows fournit un ensemble de primitives qui sont ensuite ‘traduites<\/em>‘ en quelque sorte par ntdll.dll en language noyau. C’est ainsi que WriteFile()<\/a> qui est expos\u00e9e par kernel32.dll est link\u00e9e \u00e0 une fonction ZwWriteFile()<\/a> qui ne peut \u00eatre ex\u00e9cut\u00e9e qu’en mode noyau (ring 0), qui contient du code sp\u00e9cifique \u00e0 l’architecture (x64) et un appel au dispatcher parmi d’autres choses.<\/p>\n

On comprend vite que l’ensemble du code est intimement li\u00e9 \u00e0 l’impl\u00e9mentation du C sous win32. Typiquement il n’existe pas d’IO Completion Port\u00a0sous Linux. Pour chaque composant on va trouver un \u00e9quivalent mais qui ne fonctionne pas tout \u00e0 fait de la m\u00eame fa\u00e7on.<\/p>\n

Opposition de styles ?<\/h2>\n

On serait tent\u00e9 d’imaginer que, m\u00eame si Linux et Windows partagent aujourd’hui la m\u00eame plateforme d’ex\u00e9cution qu’est le x86_64, ils sont tr\u00e8s diff\u00e9rents de conception. En fait ils ne sont pas si diff\u00e9rents que \u00e7a.<\/p>\n

Windows tel qu’on le connait aujourd’hui a \u00e9t\u00e9 con\u00e7u \u00e0 partir de 1989,\u00a0principalement par Dave Cutler<\/a> qui sortait en 1988 d’un projet avort\u00e9 chez Digital (MICA\/Prism) et qui avait d\u00e9j\u00e0 une bonne id\u00e9e de comment devait fonctionner un operating system, dans la mesure o\u00f9 il avait d\u00e9j\u00e0 travaill\u00e9 sur VMS pendant 13 ans. Linux a vu le jour \u00e0 peu pr\u00e8s \u00e0 la m\u00eame \u00e9poque que NT, Linus Torvalds terminant la v0.02 aux alentours de 1991, donc dans le m\u00eame contexte technologique, avec le monde des PC d\u00e9j\u00e0 bien \u00e9tabli. Plus troublant encore, leurs origines respectives sont \u00e9galement align\u00e9es sur la m\u00eame p\u00e9riode, le milieu des ann\u00e9es 70 (UNIX pour Linux, et VMS pour Windows NT).<\/p>\n

Vu du 8i\u00e8me \u00e9tage, les services in-core des deux noyaux semblent assez similaires, par exemple :<\/p>\n

– Tout le code du noyau est ex\u00e9cut\u00e9 dans un seul et m\u00eame espace m\u00e9moire (contrairement aux micro-kernels), donc les services (object manager, memory manager, etc…) partagent le m\u00eame pr\u00e9 carr\u00e9 et n’ont pas besoin de faire transiter de l’information d’un espace \u00e0 un autre.
\n– Il y a bien une s\u00e9paration induite par x86 entre l’espace m\u00e9moire r\u00e9serv\u00e9e au noyau et celui r\u00e9serv\u00e9 aux applications, m\u00eame si le d\u00e9coupage est diff\u00e9rent.
\n– Le processus a son propre espace d’adressage.
\n– Le noyau abstrait le mat\u00e9riel que ce soit SMP, HT, NUMA, etc…<\/p>\n

A y regarder d’un peu plus pr\u00e8s il existe quand m\u00eame quelques diff\u00e9rences d’impl\u00e9mentation des services syst\u00e8mes, qu’il faut prendre en consid\u00e9ration pour porter le code de SQL Server vers Linux.<\/p>\n

Gestion de la m\u00e9moire :<\/h2>\n

La question du 32 bits \u00e9tant \u00e9vacu\u00e9e, que peut-on dire de la gestion de la m\u00e9moire ? L\u00e0 o\u00f9 les choses ont \u00e9t\u00e9 bien faites d\u00e8s le d\u00e9part (et hommage soit rendu \u00e0 Slava) c’est que la plupart des m\u00e9thodes d’allocation ont \u00e9t\u00e9 abstraites via des classes expos\u00e9es par le framework de SQLOS : cachestores, userstores, pools, etc… Donc ce code-l\u00e0 ne devrait pas bouger. C’est plus ce sur quoi reposent ces classes qui peuvent \u00eatre revues (HeapAlloc \/ VirtualAlloc).<\/p>\n

Pour ce qui est du support des Locked Pages, qui devient presque un standard de fait sur x64, il y a un \u00e9quivalent sur Linux dans la famille de fonctions mlock et mlockall<\/a>, mais il faudrait creuser franchement dans la fonctionnalit\u00e9 car en plus de la garantie de non-pagination, l’int\u00e9r\u00eat des Locked Pages pour SQL Server est aussi li\u00e9 au fait qu’il ne n\u00e9cessite qu’un seul appel au PFN Database lock<\/a>, c’est donc aussi une question de performance. Il n’est pas certain que le comportement soit similaire sur Linux.<\/p>\n

Pour le support des Large Pages<\/em> sur Windows, il y a l’\u00e9quivalent Huge Pages<\/em><\/a> sur Linux.<\/p>\n

SQLOS \/ Scheduling:<\/h2>\n

L\u00e0 il y a quelques diff\u00e9rences notables entre ce que permet Linux par rapport \u00e0 Windows, notamment sur la notion de process<\/em> et de thread<\/em>.<\/p>\n

Sous Windows, un processus est concr\u00e8tement repr\u00e9sent\u00e9 par un espace m\u00e9moire et au moins 1 thread, qu’on appelle thread 0. C’est ce thread qui porte l’ex\u00e9cution du code sur le CPU. Un process peut cr\u00e9er plusieurs threads.<\/p>\n

Historiquement, sous Linux, c’est le processus qui porte l’ex\u00e9cution du code. Il y a eu un d\u00e9but de support des threads POSIX dans le milieu des ann\u00e9es 90 (pThreads<\/em> \/ LinuxThreads<\/em> ) mais l’impl\u00e9mentation fait qu’\u00e0 chaque pthread<\/em> sous linux un processus de type LightWeight Process<\/em> \u00e9tait cr\u00e9\u00e9 au niveau du noyau. Et c’est ce LWP<\/em> qui ex\u00e9cutait le code, ce qui fait ressembler le tout davantage aux fibers plut\u00f4t qu’aux threads win32. Parmi les limitations principales on peut citer le manque d’utilisation de la m\u00e9moire locale au thread (les registres), le fait qu’on soit oblig\u00e9 de cr\u00e9er un thread sp\u00e9cifique pour concentrer la gestion des signaux et respecter la norme POSIX (manager thread<\/em>) et surtout le manque de primitive de synchronisation qui a fait que toute l’impl\u00e9mentation repose sur les signaux. C’est pourquoi la plupart des \u00e9diteurs de bases de donn\u00e9es sous Linux n’ont (pratiquement) jamais chang\u00e9 leur mod\u00e8le multi-processus \/ m\u00e9moire partag\u00e9e (Oracle jusqu’\u00e0 la 12c, postgreSQL et Sybase jusqu’\u00e0 la 15.7, MySQL \u00e9tant une exception).<\/p>\n

Vers 2005, Red Hat (Ulrich Drepper \/ Ingo Molnar) proposa une alternative appel\u00e9e Native POSIX Thread Library (NPTL<\/a>) pour am\u00e9liorer le support des threads en version 2.5 \u00a0du noyau, bien plus prometteuse notamment sur la synchronisation, avec l’apparition des futexes<\/a>\u00a0(Fast Userspace Mutexes). L’utilisation de NPTL est maintenant g\u00e9n\u00e9ralis\u00e9e.<\/p>\n

Depuis le noyau 2.6, la s\u00e9mantique se rapproche de Windows dans la mesure o\u00f9 l’unit\u00e9 d’ex\u00e9cution est bien devenue le thread. Un thread a un Thread ID et un Thread\u00a0Group ID qui correspond grosso-modo au PID. Lorsqu’on appelle clone<\/em> ou fork<\/em> depuis un autre thread, soit on va cr\u00e9er un nouveau couple (TGID,TID), donc un nouveau process, soit un nouveau TID en conservant le TGID du cloneur, donc un nouveau thread dans le processus courant. La notion de process est devenue plus un espace m\u00e9moire et un ensemble de threads sous le m\u00eame TGID aujourd’hui.<\/p>\n

Si on en revient \u00e0 SQL Server, on peut se demander quelle sera la strat\u00e9gie adopt\u00e9e. J’imagine mal que soient sortis les workers syst\u00e8mes (CHECKPOINT, LOG MANAGER, SIGNAL HANDLER, RESSOURCE MONITOR, les TASK MANAGERs, etc…), du process address space de l’ex\u00e9cutable principal et discuter via de la m\u00e9moire partag\u00e9e. \u00c7a serait pire qu’un grand coup de pied dans la fourmili\u00e8re. D’ailleurs, les t\u00e2ches syst\u00e8me dans Sybase ASE par exemple, qui est un peu le faux jumeau de SQL Server, sont int\u00e9gr\u00e9s \u00e0 base de threads. Ce sont les schedulers, les engines dans le jargon, qui avaient \u00e9t\u00e9 sortis sous forme de processus, mais ils peuvent \u00eatre r\u00e9int\u00e9gr\u00e9s sous forme de threads depuis la version 15.7.<\/p>\n

Donc il y a fort \u00e0 parier que les workers seront port\u00e9s sur NPTL qui est la version la plus aboutie du support des threads POSIX sur Linux. Quant aux fibers, ils pourraient \u00eatre remplac\u00e9s par des threads POSIX version LinuxThreads mais vu les limitations, ils pourraient carr\u00e9ment ne pas \u00eatre port\u00e9s du tout.<\/p>\n

Pour ce qui est du scheduler coop\u00e9ratif, tout se passe en usermode donc on ne voit pas bien ce qui pourrait poser probl\u00e8me. La valeur des quantums est presque \u00e9quivalente entre les 2 OS.<\/p>\n

J’ai remarqu\u00e9 un fait int\u00e9ressant en comparant le quantum interne de SQLOS de 4ms et celui de Sybase ASE (timeslice de \u00a0100ms + plus une p\u00e9riode de grace de 500 ticks d’horloge par d\u00e9faut), et la diff\u00e9rence est ENORME. Il faut dire que le timeslice sur ASE n’a pas \u00e9volu\u00e9 depuis \u00e0 peu pr\u00e8s 10 ans alors que la fr\u00e9quence des processeurs \u00e0 continu\u00e9 de progresser. Donc le probl\u00e8me serait-il plut\u00f4t c\u00f4t\u00e9 Sybase ? \u00a0On verra bien \u00a0si les 4ms de SQL Server \u00a0tiennent toujours sur Linux. Je suis d’avis que \u00e7a ne changera pas.<\/p>\n

On risque de voir quelques diff\u00e9rences toutefois sur tout ce qui est pr\u00e9empt\u00e9. Lorsque l’ex\u00e9cution va \u00e9chapper \u00e0 SQLOS sous Linux, le thread va h\u00e9riter d’une priorit\u00e9 et d’un quantum qui vont fluctuer selon sa consommation CPU. Plus le thread consomme de la CPU, plus sa priorit\u00e9 va baisser par rapport aux autres (decay<\/em>) et plus son quantum par contre va augmenter (entre 10 et 100ms). C’est l\u00e0 une diff\u00e9rence avec Windows car un thread win32 h\u00e9rite de la priorit\u00e9 de base du processus puis peut augmenter mais ne peut jamais repasser sous sa priorit\u00e9 de d\u00e9part.<\/p>\n

C’est une mani\u00e8re \u00e9l\u00e9gante pour Linux de permettre un acc\u00e8s \u00e9quitable aux ressources entre les diff\u00e9rentes applications, en infligeant une p\u00e9nalit\u00e9 aux threads qui consomment le plus, tout en leur autorisant une plus grande plage de travail lors de leur prochaine ex\u00e9cution. Le martinet et le bonbon, en quelque sorte…<\/p>\n

Quelques exemples de primitives \u00e0 substituer:<\/h2>\n

Un autre point cl\u00e9 du d\u00e9veloppement va \u00eatre de trouver des rempla\u00e7ants \u00e0 certaines fonctionnalit\u00e9s du type :<\/p>\n

WaitForSingleObject \/\u00a0WaitForMultipleObject<\/strong> :<\/h3>\n

Sur Windows, un thread peut bloquer sur n’importe quel handle : un fichier, un event, un mutex, un process, un s\u00e9maphore, un timer, une notification, etc… Il appelle l’une de ces deux primitives en lui passant le handle de l’objet, plus quelques autres informations comme le timeout par exemple (SQL Server utilise massivement INFINITE pour ce param\u00e8tre). \u00a0Typiquement un thread est associ\u00e9 \u00e0 un event par exemple, et l’initialise \u00e0 False, puis bloque dessus avec un timeout \u00e0 INFINITE. Un autre thread signale le premier en passant son event \u00e0 True, et celui-ci peut commencer \u00e0 travailler. C’est comme \u00e7a que fonctionne la yield routine au niveau SQLOS, le worker sortant signale le premier worker en runnable list.<\/p>\n

Sous Linux, les processus et les threads utilisent principalement des signaux pour discuter. Les signaux sont de simples interruptions logicielles utilis\u00e9es pour qu’un programme puisse discuter avec un autre.\u00a0Par exemple, les processus backends PostgreSQL (qui mat\u00e9rialisent les connexions utilisateur) correspondent avec le processus postmaster (le processus initial) via des signaux, comme SIGINT, \u00e9quivalent de Ctrl+C, pour annuler une requ\u00eate en cours d’ex\u00e9cution.<\/p>\n

Comme on part du principe que ce ne sera pas du multiprocess mais bien toujours du multithread, \u00e0 base de NPTL, on suppose que les workers se signaleront entre eux via les futexes, qui vont permettre de se rapprocher de ce que donnent les events sur win32. Les futexes supportent des notions telles que le timeout y compris l’\u00e9quivalent d’INFINITE (timeout \u00e0 NULL) et la synchronisation sur plus d’un \u00e9v\u00e9nement comme WaitForMultipleObjects.<\/p>\n

Interlocked :<\/h3>\n

Les fonctions Interlocked<\/a> permettent de construire ce qu’on appelle en usermode des spinlocks<\/a>, des outils de synchronisation entre threads. La diff\u00e9rence entre un spinlock et un event par exemple, est qu’un spinlock est une construction purement applicative, et ne fait pas r\u00e9f\u00e9rence \u00e0 un objet du noyau (donc pas de transition user -> kernel). Donc elle est beaucoup plus l\u00e9g\u00e8re \u00e0 ex\u00e9cuter.<\/p>\n

Les spinlocks dans SQL Server permettent de prot\u00e9ger principalement des listes cha\u00een\u00e9es de structures, comme les BUFs, ces structures qui d\u00e9crivent les pages pr\u00e9sentes en Buffer Pool. Il existe tout un tas de listes de structures pour les m\u00e9tadatas, le plan cache, les verrous, les FCB, etc… Faire un select name from <\/em>sys.dm_os_spinlock_stats<\/em>\u00a0<\/a>pour l’exhaustivit\u00e9.<\/p>\n

Ces ressources sont uniques dans tout l’espace d’adresse de SQL Server, et sont accessibles potentiellement par de multiples workers donc il faut que l’on puisse garantir une s\u00e9quentialisation des acc\u00e8s. Lorsque l’on sait que la ressource ne va \u00eatre d\u00e9tenue que pendant un temps tr\u00e8s court, il peut \u00eatre plus int\u00e9ressant de br\u00fbler de la CPU dans une boucle et v\u00e9rifier \u00e0 chaque tour si la ressource est disponible plut\u00f4t que de bloquer et se mettre en attente. Si la ressource est volatile on a de grandes chances de pouvoir la verrouiller au prochain tour. En revanche, si on bloque, on va devoir attendre d’\u00eatre reschedul\u00e9.<\/p>\n

A l’int\u00e9rieur de la boucle, on va en m\u00eame temps tester une variable et tenter de modifier sa valeur :<\/p>\n

Boucle tant que (teste_et_initialise (a,1) != 1)<\/pre>\n
Dans la plupart des langages, il existe des fonctions qui font ce travail de mani\u00e8re atomique (en garantissant qu’il n’y a qu’un seul thread sur tous les processeurs capable de modifier la valeur), mais en d\u00e9finitive ces fonctions font toutes r\u00e9f\u00e9rence \u00e0 une instruction du processeur cod\u00e9e en langage assembleur (CMPXCHG , CMPXCHG8B par exemple pour x86). Dans le monde Windows ce sont les fonctions de la famille Interlocked qui font ce travail. Dans le monde linux, il y a des \u00e9quivalent comme les fonctions type atomic<\/a>, ou seqlocks<\/a> en kernel 2.6.<\/p>\n
IOCP :<\/h3>\n
L\u00e0 c’est ultra-chaud. Je ne vois qu’un seul endroit ou les IO completion ports<\/a> sont utilis\u00e9s, c’est sur la gestion des connexions sur chaque CPU node, ou NUMA node.<\/p>\n
L’int\u00e9r\u00eat d’un IOCP est de permettre de synchroniser des threads sur des IO asynchrones tout en n’autorisant qu’un certain nombre \u00e0 s’ex\u00e9cuter en parall\u00e8le. Si on a 8 CPU et qu’on a 150 demandes de connexions simultan\u00e9es, on va en traiter 8 en m\u00eame temps mais les autres seront toutes visibles par le scheduler windows et rien ne va l’emp\u00eacher de changer le contexte (context switch<\/em>) des t\u00e2ches en ex\u00e9cution pour permettre \u00e0 chacune de disposer d’une m\u00eame quantit\u00e9 de temps CPU.<\/p>\n
Donc comme pour le scheduling coop\u00e9ratif dans SQLOS, il faut limiter le nombre de connexions visibles par Windows au nombre de CPU disponibles, via un IOCP et une propri\u00e9t\u00e9 de concurrence: on va dire \u00e0 l’IOCP que seulement 8 connexions peuvent passer en m\u00eame temps. La premi\u00e8re IO qui est termin\u00e9e \u00e9met un paquet de fin de traitement qui est notifi\u00e9 au thread en attente pendant que le suivant peut encha\u00eener sur une autre IO, etc… On ne conserve ainsi que le nombre optimal de threads ex\u00e9cutables \u00e0 un instant donn\u00e9. L’autre avantage est que l’IOCP g\u00e8re ses propres m\u00e9canismes de notification et est plus scalable<\/em> qu’un fonctionnement \u00e0 base de SetEvent \/ WaitForSingleObject.<\/p>\n
Or cet objet du noyau n’existe pas sous Linux. Il y a potentiellement epoll<\/a>\u00a0qui peut \u00eatre \u00e9tudi\u00e9, mais il y a plusieurs diff\u00e9rences dans le fonctionnement de base:<\/p>\n
– Un IOCP fonctionne avec des IO asynchrones : on effectue un appel \u00e0 une fonction sans \u00eatre bloqu\u00e9 (asynchrone), puis on re\u00e7oit une notification que l’op\u00e9ration est termin\u00e9e plus tard. Alors que sous Linux, l’approche est diff\u00e9rente, on attend qu’une donn\u00e9e soit disponible en lecture sur par exemple une socket, et on lit le contenu sans avoir \u00e0 attendre puisqu’il est disponible imm\u00e9diatement.
\n– Il n’y a pas de notion de concurrence max comme dans un IOCP. Avec epoll il n’y a qu’un seul thread qui travaille \u00e0 chaque fois. Il faut alors cr\u00e9er de multiples epoll pour arriver au m\u00eame principe de concurrence.<\/p>\n
Une \u00e9tude comparative r\u00e9cente<\/a> montre notamment qu’epoll serait plus consommateur en CPU que IOCP, mais qu’en dehors de \u00e7a les capacit\u00e9s de traitement sont comparables.<\/p>\n
Entr\u00e9es \/ sorties (disque):<\/h2>\n
L\u00e0 aussi, compliqu\u00e9. Il y a plusieurs aspects des entr\u00e9es \/ sorties qui sont \u00e0 v\u00e9rifier:<\/p>\n
La durabilit\u00e9 des \u00e9critures:<\/h3>\n
Il y a plusieurs fa\u00e7ons de faire. Par exemple sur Sybase ASE<\/a>\u00a0ou MySQL (innodb_flush_method), les fichiers de donn\u00e9es et journaux de transactions peuvent \u00eatre ouverts en O_DSYNC ou en O_DIRECT quand le file system le permet. Sur PostgreSQL, la durabilit\u00e9 est assur\u00e9e via des appels r\u00e9p\u00e9t\u00e9s \u00e0 fsync()<\/a>. Au fil des versions des optimisations ont \u00e9t\u00e9 faites pour limiter le nombre d’appels \u00e0 fsync dans le code mais il reste toujours des workloads o\u00f9 cette approche est impactante.<\/p>\n
Or sur Windows l’ouverture du fichier est faite via un \u00e9quivalent \u00e0 O_DIRECT en quelque sorte, via deux flags pass\u00e9s lors du CreateFile()<\/a>. Donc il y aura n\u00e9cessairement des pr\u00e9conisations quant aux file systems support\u00e9s et aux options \u00e0 positionner pour avoir un \u00e9quivalent.<\/p>\n
Les entr\u00e9es \/ sorties asynchrones :<\/h3>\n
La plupart des entr\u00e9es \/ sorties sont asynchrones<\/a> dans SQL Server. \u00a0Il y a deux impl\u00e9mentations des IO asynchrones sur Linux:<\/p>\n
– Les POSIX asynchronous IO:<\/strong> dans ce cas, l’IO est vue non bloquante par celui qui l’initie mais dans les faits il clone un nouveau thread qui lui va bloquer \u00e0 sa place. Donc bon …<\/p>\n
– Les Kernel asynchronous IO (ou libaio)<\/strong> : dans ce cas, il s’agit d’une approche plus comparable avec ce que propose Windows. Elle est support\u00e9e depuis la 2.6 et a fait l’objet de tests plut\u00f4t concluants<\/a> notamment chez MySQL AB \u00e0 l’\u00e9poque, et qui ont conduit \u00e0 son impl\u00e9mentation dans InnoDB. La contrainte dans ce cas est que le fichier doit \u00eatre ouvert en O_DIRECT ce qui semblerait donc orienter le choix sur la question de la durabilit\u00e9.<\/p>\n
WriteFileGather \/ ReadFileScatter :<\/h3>\n
Lorsque le checkpoint doit \u00e9crire des pages modifi\u00e9es sur disque, il ex\u00e9cute une routine WriteMultiple dans laquelle il va aller r\u00e9cup\u00e9rer un certain nombre de pages marqu\u00e9es comme dirty dans le Buffer Pool, puis ex\u00e9cute un appel \u00e0 WriteFileGather() qui va les \u00e9crire sur disque. L’avantage de WriteFileGather par rapport \u00e0 WriteFile est que l’on n’est pas oblig\u00e9 d’avoir \u00e0 faire des I\/O s\u00e9par\u00e9es pour des blocks discontig\u00fcs en m\u00e9moire. SQL 2014 peut envoyer jusqu’\u00e0 32 pages dans une seule op\u00e9ration d’\u00e9criture avec cette technique, et SQL 2016 jusqu’\u00e0 128 (soit 1Mb). M\u00eame chose dans l’autre sens avec ReadFileScatter. On n’est pas oblig\u00e9 d’avoir un segment contig\u00fc de 64K de m\u00e9moire pour placer un prefetch de 8 pages. C’est comme cela que les pages sont remont\u00e9es du disque dans le Buffer Pool.<\/p>\n
Sur Linux, on va utiliser les IO vectoris\u00e9es (vectored IO) avec readv<\/a> et writev<\/a>. Leur fonctionnement est en apparence semblable \u00e0 leurs cousines win32, elles passent un tableau de buffers \u00e0 \u00e9crire ou lire (iovec sous Linux, FILE_SEGMENT_ELEMENT sous Windows). Actuellement le nombre de buffers discontigus \u00e0 passer \u00e0 readv \/ writev est limit\u00e9 \u00e0 1024 ce qui est toujours au-dessus de ce que transmet SQL Server. (IOV_MAX dans limits.h<\/a>). Une diff\u00e9rence r\u00e9side dans le fait que sur Windows on indique une quantit\u00e9 d’octets \u00e0 \u00e9crire ou lire \u00a0alors que sur Linux, on indique un nombre de segments iovec \u00e0 traiter.<\/p>\n
Autre note int\u00e9ressante, WriteFileGather \/ ReadFileScatter d\u00e9clarent une structure Overlapped dans leur signature, donc les IO sont n\u00e9cessairement asynchrones. Sur Linux, les Kernel asynchronous IO ont \u00e9t\u00e9 \u00e9tendues aux IO vectoris\u00e9es dans un patch qui daterait de la 2.5, donc aio_write et aio_read ont chacune une signature qui inclue un iovec<\/a>\u00a0depuis ce patch.<\/p>\n
NTFS vs ext4:<\/h2>\n
Un certain nombre de fonctionnalit\u00e9s sont \u00e9galement li\u00e9es aux possibilit\u00e9s offertes par NTFS, parmi lesquelles on peut citer:<\/p>\n
– Les sparse files AKA<\/em> Database Snapshots.
\n– La possibilit\u00e9 de z\u00e9ro – initialiser (dans le cas des journaux de transactions) ou non ( dans le cas des fichiers de donn\u00e9es) les portions de fichiers allou\u00e9es sur disque.
\n– La possibilit\u00e9 de r\u00e9duire un fichier sur disque.<\/p>\n
Il y a peut \u00eatre des pistes \u00e0 creuser en regardant ce que font truncate<\/a> \/ fallocate<\/a> par exemple. Truncate doit permettre de cr\u00e9er des sparse files et de r\u00e9duire des fichiers sur ext4. Fallocate doit permettre de faire l’\u00e9quivalent de SetEndOfFile<\/a> pour l’initialisation instantan\u00e9e.<\/p>\n
Pour retrouver l’\u00e9quivalent du cluster size NTFS \u00e0 64K, il existe une option bigalloc<\/a> qui est utilis\u00e9e lors du mkfs, attention toutefois l’option n’est disponible qu’\u00e0 partir des noyaux 3.2, et rencontrerait toujours pas mal de probl\u00e8mes jusqu’en 3.7. Sachant que les noyaux 3.2 rencontrent eux-m\u00eames pas mal de probl\u00e8mes<\/a>\u00a0, \u00e7a risque donc de ne pas \u00eatre pour tout de suite.<\/p>\n
Il est \u00e9galement possible d’utiliser mkfs.ext4 -T largefile pour le formatage, cela permet de diminuer le nombre d’inodes pour les gros fichiers (1 inode pour 1Mb au lieu de 1 inode pour 16K).<\/p>\n
Autres points cl\u00e9s :<\/h2>\n
D’autres points qui peuvent \u00eatre compliqu\u00e9s \u00e0 traduire dans le monde Linux:<\/p>\n