0

Mythe : ASYNC_IO_COMPLETION indique-t-il toujours une attente sur une IO asynchrone ?

twitterlinkedinmail

Ceux qui pensent que oui l√®vent la main… Perdu ūüôā

Pour rappel, ASYNC_IO_COMPLETION est un √©v√®nement d’attente utilis√© pour marquer les attentes li√©es √† des IO asynchrones hors activit√© buffer pool (qui elles sont marqu√©es avec PAGEIOLATCH_*). L’exemple le plus connu est le checkpoint, qui √©crit en faisant appel √† WriteFileGather et des IO asynchrones. Un moins connu est la lecture des fichiers de donn√©es pendant un backup.

Son oppos√© est IO_COMPLETION qui lui marque les attentes li√©es √† des IO synchrones. Pour la diff√©rence entre les deux, retourner √† l’article sur les¬†IO asynchrones.

Or nous avons vu dans l’article que ce n’est pas parce qu’on poste une IO¬†asynchrone qu’on a la garantie qu’elle sera bien asynchrone. C’est la raison pour laquelle on teste toujours¬†le code retour¬†de WriteFileGather ou ReadFileScatter :

– Si getlasterror retourne ERROR_IO_PENDING (997) : il s’agit bien d’une IO asynchrone.
– Si getlasterror retourne ERROR_SUCCESS (0) : il s’agit d’une IO synchrone.

Qu’est -ce qui pourrait bien causer la conversion d’une IO asynchrone en synchrone ? Comme l’indique Raymond Chen sur son¬†blog, par exemple lorsqu’une √©criture dans un fichier d√©clenche une extension sur disque, ou lorsqu’on √©crit sur un filesystem compress√© ou encrypt√©. Un plus grand nombre de causes sont list√©es dans un¬†KB.

Or comme l‚Äô√©v√©nement d’attente au niveau du code de SQL Server est d√©termin√© avant de poster l’IO, que celle-ci soit asynchrone ou non ne changera pas la nature de l’attente vue par SQL Server. Donc ne pas s’y fier absolument.

On en profite pour rappeler que Paul Randal a publi√© la semaine derni√®re son r√©f√©rentiel des¬†√©v√®nements d’attente.

Update 2016/07/01: Bob Dorr nous remonte une autre cause de blocage des IO asynchrones: lorsque le journal de transactions est zero-initialis√©, certains syst√®mes de stockage r√©cup√®rent l’espace car cela peut s’apparenter √† du thin provisionning. SQL Server doit r√©initialiser l’espace √† nouveau et l’IO sera post√©e en synchrone. SQL 2016 initialise avec 0xC0 √† la place de 0x00 pour √©viter ce probl√®me. Cf : https://blogs.msdn.microsoft.com/bobsql/2016/06/03/sql-2016-it-just-runs-faster-ldf-stamped/

A+

Continuez votre lecture sur le blog :

twitterlinkedinmail

David Baffaleuf

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.