Although Linux includes support for rawio, it is now a deprecated interface. If your application performs device access using this interface, Red Hat encourages you to modify your application to open the block device with the O_DIRECT flag. The rawio interface will exist for the life of Red Hat Enterprise Linux 5, but is a candi-
\ndate for removal from future releases.<\/em><\/p>\nLe b\u00e9n\u00e9fice du raw device n’est pas nouveau, que ce soit pour Adaptive Server ou Oracle, le fait d’\u00e9crire directement sur la partition brute a deux avantages majeurs pour les SGBD:
\n1 – Ca va plus vite.
\n2 – Ca garantit que ce que l’on \u00e9crit va bien sur le disque et non dans un buffer en m\u00e9moire. En effet, le syst\u00e8me de base de donn\u00e9es g\u00e8re lui-m\u00eame la bufferisation de ses pages de donn\u00e9es et d’indexes, et ne doit pas se reposer sur le syst\u00e8me pour \u00e7a.<\/p>\n
A partir du moment o\u00f9 le raw device cesse d’\u00eatre support\u00e9, on va devoir \u00e9crire dans un fichier, et qui dit \u00e9criture dans un fichier sous UNIX\/Linux dit \u00e9criture bufferis\u00e9e. C’est l\u00e0 o\u00f9 le crit\u00e8re 2 n’est plus garanti.<\/p>\n
Il reste alors deux solutions qui vont nous permettre de garantir cel\u00e0: DIRECTIO ou DSYNC. Ce sont en fait des arguments qui vont \u00eatre pass\u00e9s \u00e0 la primitive d’ouverture du fichier, le plus souvent open(), sous la forme de flags: O_DIRECT, O_DSYNC ou O_ASYNC.<\/p>\n
A travers Adaptive Server, ces arguments seront manipul\u00e9s lors de la cr\u00e9ation de devices avec la commande disk init:<\/p>\n
disk init name='PERFSTATS_data01', physname='\/sybase_data\/ASE1502\/userdb\/PERFSTATS_data01.dat',\r\nsize=512000,\r\ndirectio=true<\/pre>\nou<\/p>\n
disk init name='PERFSTATS_data01', physname='\/sybase_data\/ASE1502\/userdb\/PERFSTATS_data01.dat',\r\nsize=512000,\r\ndsync=true<\/pre>\nOn ne peut pas utiliser \u00e0 la fois directio=true et dsync=true pour le m\u00eame device, les options sont mutuellement exclusives.<\/p>\n
DIRECTIO<\/strong>:
\nLorsque directio est \u00e0 true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DIRECT:<\/p>\nopen(\"\/sybase_log\/ASE1502\/userdb\/PERFSTATS_data01.dat\", O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 17<\/pre>\nLorsque la primitive d’\u00e9criture est invoqu\u00e9e (write(), aiowrite()), l’\u00e9criture va directement sur le disque. Donc s\u00e9mantiquement \u00e9quivalent \u00e0 ce que donne une \u00e9criture sur un raw device, \u00e0 la fois en termes de performances et de garantie.<\/p>\n
DSYNC:<\/strong>
\nLorsque dsync est \u00e0 true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DSYNC:<\/p>\nopen(\"\/sybase_log\/ASE1502\/userdb\/PERFSTATS_data01.dat\", O_RDWR|O_DSYNC|O_LARGEFILE) = 17<\/pre>\nLorsque dsync est \u00e0 false, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_ASYNC:<\/p>\n
open(\"\/sybase_log\/ASE1502\/userdb\/PERFSTATS_data01.dat\", O_RDWR|O_ASYNC|O_LARGEFILE) = 17<\/pre>\nLorsque la primitive d’\u00e9criture est invoqu\u00e9e, l’\u00e9criture sera bufferis\u00e9e mais en fonction de la valeur pass\u00e9e \u00e0 disk init (true ou false), certains \u00e9l\u00e9ments vont \u00eatre synchronis\u00e9s sur disque avant que aiowrite() ne revienne au programme appelant.
\n– dsync=true<\/strong><\/em>: alors le flag O_DSYNC est pass\u00e9 \u00e0 open(). Ce flag garantit que write() reste en attente tant que les donn\u00e9es n’ont pas \u00e9t\u00e9 synchronis\u00e9es sur disque.
\n– dsync=false:<\/strong><\/em> alors le flag O_ASYNC est pass\u00e9 \u00e0 open(). Ce flag indique que write() rend la main une fois l’\u00e9criture bufferis\u00e9e mais AVANT la synchronisation sur disque, ce qui ne garantit pas notre crit\u00e8re 2.<\/p>\nOn recommandera toujours de mettre dsync=true pour les devices de donn\u00e9es et de journaux pour avoir la garantie d’\u00e9criture stabilis\u00e9e, et dsync=false pour les devices tempdb pour favoriser la perf.<\/p>\n
– Avantages \/ Inconv\u00e9nients pour le DSYNC: <\/strong>
\nAvantages<\/strong><\/em>: c’est compl\u00e8tement support\u00e9 par les file system.
\nInconv\u00e9nients<\/strong><\/em>: C’est moins performant en \u00e9criture.<\/p>\n– Avantages \/ Inconv\u00e9nients pour le DIRECTIO: <\/strong>
\nAvantages<\/strong><\/em>: c’est comme du raw device, sauf que c’est dans un fichier. C’est m\u00eame plus efficace en lecture.
\nInconv\u00e9nients<\/strong><\/em>: il faut que le filesystem le supporte (c’est le cas pour ext3), et d’apr\u00e8s Linus l’impl\u00e9mentation de directio au niveau du kernel est \u00e9pouvantable. Le probl\u00e8me c’est que ce qu’il indique comme contournement \u00e0 destination des d\u00e9veloppeurs ASE (Wim Ten Have et Dave Wein en t\u00eate) n’est pas vraiment applicable.<\/p>\nPas de doute, le DIRECTIO reste la meilleure option. Ce sera s\u00fbrement r\u00e9\u00e9crit un jour, mais pour l’instant on n’a pas trouv\u00e9 mieux.<\/p>\n
Un dernier mot sur le dsync=true sur les noyaux 2.6+, l’\u00e9criture asynchrone se transforme en \u00e9criture synchrone et les perfs chutent :-((( . Il faut vraiment utiliser directio sur les noyaux r\u00e9cents. Ce sera peut \u00eatre le sujet d’un prochain post sur ASE.<\/p>\n
A+ [ David B. ]<\/p>\n
![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>