SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds en ERRORLOG

Por gracia o desgracia, para muchos será habitual encontrar el siguiente mensaje en el ERRORLOG de SQL Server, quizás siempre sobre el mismo fichero, quizás aleatoriamente sobre los distintos ficheros de las distintas bases de datos, etc.

SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds en ERRORLOG to complete on file [F:\MSSQL\DATA\tempdb.mdf] in database [tempdb] (2). The OS file handle is 0x00001124. The offset of the latest long I/O is: 0x000000abcd0000

Este nuevo mensaje de advertencia, ha causado furor entre los administradores de SQL Server, pues causa cierta preocupación en los mismos. La principal causa de esta situación, es le hecho de que SQL Server solicita operaciones de lectura o escritura de forma asíncrona. Sin embargo, éste no es un error de SQL Server, es decir, SQL Server cuando necesita completar una operación de entrada/salida a disco, se limita a solicitar dicha operación al Sistema Operativo (habitualmente Windows Server 2003 o Windows 2000 Server, a fecha de hoy), siendo el Sistema Operativo quién solicite a su vez dicha operación al subsistema de entrada/salida, a través de los controladores y del hardware de que disponga el servidor. Es decir, SQL Server se limita a realizar llamadas a funciones API de Microsoft Windows, como es el caso de las funciones WriteFile, ReadFile, WriteFileScatter, y ReadFileGather. Las solicitudes de entrada/salida, son a su vez gestionadas por Microsoft Windows como Paquetes de Solicitud de E/S (I/O Request Packet o IRP). Sin embargo, en muchos casos suele verse como un Problema de Rendimiento en SQL Server, ya que al fin de cuentas, es SQL Server el afectado (aunque el problema realmente esté fuera).

En el caso de redes de almacenamiento SAN, entran más elementos en juego, como puedan ser los propios conmutadores de red (típicamente los switches de las Fabric SANs como los Brocade o los McData) y los propios Storages (las cabinas de almacenamiento como las EVA de HP o los Shark de IBM), y en consecuencia, nos pueden impactar las distintas configuraciones que se pueden realizar entre estos elementos (ej: quizás exista algún cuello de botella en algún puerto de algún switch de nuestras fabrics, quizás se requiera de una configuración de zoning/masking, etc), versiones de firmware, problemas de hardware o del propio cableado, etc. No es extraño encontrarnos que tenemos un único servidor de almacenamiento (el Storage) con quizás 4 puertos de fibra, para dar servicio a múltiples servidores, cada uno de los cuales quizás disponga de 2 ó 4 fibras (en caso de grandes servidores, serán decenas de fibras), existiendo cuellos de botellas para el acceso al Storage (o en los puertos de Storage o en los switches).

Es importante tener en cuenta que el tiempo ordinario para la realización de una operación de lectura o escritura es del orden de 10 ms. Evidentemente, 15 segundos sin que una operación de entrada/salida se concluya está fuera de lugar.

En cualquier caso, ¿a qué puede ser debido este error? Es importante comprobar:

• Errores y advertencias de Hardware. Comprobar alternativas de configuración, disponibilidad de nuevas versiones de BIOS, etc. Por ejemplo, si tenemos varias tarjetas HBA configuradas en modo failover con un alto tiempo de timeout previo a la utilización de caminos redundantes, cabe la posibilidad que ante una pérdida de conectividad a la SAN a través del camino principal, se pierda una alta cantidad de tiempo antes de empezar a utilizar el camino alternativo, generándose mientras tanto, retrasos en las operaciones de entrada/salida (en este escenario, sería interesante reducir dicho tiempo de timeout para mejorar el funcionamiento del failover).
• Errores, advertencias y versiones de Firmware. Comprobar la existencia de nuevas versiones por parte del fabricante, alternativas de configuración, etc. Considérese el Firmware de cualquiera de los dispositivos que intervengan en el subsistema de almacenamiento, como puedan ser tarjetas controladoras HBA de fibra, el Firmware de la propia cabina de almacenamiento (el Storage), etc.
• Errores y advertencias de Controladores de dispositivos. Comprobar la existencia de nuevas versiones por parte del fabricante, alternativas de configuración, etc.
• Congestiones o cuellos de botella en los caminos de entrada/salida. Por ejemplo, pueda estar algún puerto de la red SAN saturado de tráfico, de tal modo, que la carga de trabajo de entrada/salida exceda las capacidades del sistema o las capacidades del camino de entrada/salida. Otro ejemplo es la configuración Boot-On-SAN que permiten algunos servidores, consistente en servidores SIN discos locales, que disponen de todo su almacenamiento (incluido Boot, Sistema, y ficheros de paginación) en la SAN. Esta configuración, aunque ofrece de gran versatilidad para los administradores de sistemas (permite presentar discos o LUNs a servidores físicos, como si se tratasen se máquinas virtuales, facilita la clonación de servidores, etc.) implica una intensiva carga de entrada/salida sobre las cabinas de almacenamiento y sus puertos de fibra (al menos, en caso de disponer un número considerable de servidores configurados en Boot-On-SAN).
• Utilización de controladores de filtrado de entrada/salida (I/O filter drivers). Algunas aplicaciones, como puede ser el caso de software de backup o antivirus, utilizan este tipo de controladores, los cuales forman parte de la pila de entrada/salida y tienen acceso a las solicitudes de IRP. Un ejemplo, puede ser el caso de un software de backup que esté realizando backups de los ficheros (MDF y LDF) de SQL Server con la instancia iniciada y algún agente para ficheros abiertos, produciéndose una demora en las operaciones de entrada/salida de SQL Server. En este caso, la recomendación es excluir los ficheros de base de datos de ésta política de backup.

Es importante tener en cuenta que los problemas de entrada/salida son especialmente difíciles de diagnosticar y de depurar.

Antes de SQL Server 2000 SP4, era necesario utilizar el System Monitor y observar los contadores:

• Physical Disk\Avg Disk sec/read. El valor de éste contador suele ser menor de 8 milisegundos para sistemas de disco sin cache, y menor de 1 milisegundo para sistemas de disco con caché.
• Physical Disk\Avg Disk sec/write. El valor de éste contador suele ser menor de 8 milisegundos.
• Physical Disk\Avg Disk sec/transfer. El valor de éste contador suele ser menor de 15 milisegundos. Si encontramos subidas en el valor de éste contador, puede ser debido a que el subsistema de entrada/salida no es capaz de mantener la demanda de operaciones de entrada/salida.
• Physical Disk\Average Disk Queue Length. Un valor superior a 2 durante periodos de tiempo contiguos (de más de 10 minutos) suele revelar cuellos de botella en el subsistema de entrada/salida.
• Physical Disk\% Disk Time. Un valor superior al 55% durante periodos de tiempo continuos (de más de 10 minutos) suele revelar cuellos de botella en el subsistema de entrada/salida.
• Processor\% Processor Time. Un valor superior al 75% durante periodos de tiempo continuos (de más de 10 minutos) suele revelar cuellos de botella de CPU. Es interesante comprobar este contador junto al contador System\Processor Queue Length.
• System\Processor Queue Length. Un valor superior a 2 (por cada CPU) durante periodos de tiempo continuos (de más de 10 minutos) junto a un valor elevado del contador Processor\% Processor Time, es una muestra muy evidente de la existencia de cuellos de botella de CPU (se necesita mayor capacidad de procesamiento). Una medida que se puede tomar ante elevados valores del contador System\Processor Queue Length en el caso de SQL Server, es disminuir el valor de la opción de configuración max worker threads.
• SQL Server Buffer\Buffer Cache Hit Ratio. Este contador indica con qué frecuencia SQL Server accede al buffer de memoria en vez de a disco, cuando necesita resolver una operación de lectura. Es recomendable mantener un valor por encima del 90%, siendo lo ideal mantenerse lo más cercano posible al 100%. En caso de mantener un valor inferior al 90% durante periodos de tiempo continuos (de más de 10 minutos), puede resultar de mucho interés aumentar la memoria RAM del servidor. Es interesente comprobar el valor de éste contador, junto con el contador Memory\Pages/sec.
• SQL Server General Statistics\User Connections. Este contador indica el número de conexiones de usuario (OJO, que no tiene porque coincidir con el número de usuarios conectados). El valor de éste contador debe ser inferior al valor de la opción de configuración max worker threads. En caso de no cumplirse ésta regla, debe aumentarse el valor de la configuración max worker threads para cubrir éste objetivo.
• Memory\Pages/sec. Este contador indica el número de páginas por segundo que son paginadas, de RAM a disco o de disco a RAM. Evidentemente, cuanto mayor es la paginación mayor es la actividad de entrada/salida a disco. Mantener una media superior a 20 para este contador durante periodos de tiempo continuos (de más de 10 minutos), puede indicar la existencia de un cuello de botella de Memoria. Es importante observar la ocurrencia de un valor elevado para este contador, junto con un valor elevado para el contador SQL Server Buffer\Buffer Cache Hit Ratio.
• SQL Server:Buffer Manager\Page reads/sec. Este contador permite medir la cantidad de lecturas producidas por SQL Server.
• SQL Server:Buffer Manager\Page writes/sec. Este contador permite medir la cantidad de escrituras producidas por SQL Server.

Del mismo modo, suele resultar muy útil comprobar dichos contadores juntos, intentando relacionarlos entre ellos (y a poder ser, relacionarlos con otros eventos, como ejecución de determinados procesos, acceso a determinadas tablas, etc.). El fin de este ejercicio es intentar comprobar si existe un cuello de botella en la entrada/salida a disco y si puede ser causada por latencias de acceso a disco. En cualquier caso, si descubrimos éste error en el ERRORLOG, sería buena práctica realizar un seguimiento de dichos contadores con el fin de encontrar argumentos para ayudar a diagnosticar nuestras sospechas de problemas en el subsistema de entrada/salida.

También, el tipo de espera (lastwaittype) que podamos encontrar al consultar la tabla del sistema master.dbo.sysprocesses, puede ser de gran ayuda para diagnosticar problemas en el subsistema de entrada/salida a disco, principalmente si encontramos esperas de pestillo (las de I/O LATCH como por ejemplo, PAGEIOLATCH_SH) y esperas de escritura de LOG (WRITELOG).

Algunas medidas preventivas que podemos tomar, son defragmentar el sistema de ficheros (parando el SQL Server, excepto que dispongamos de algún software capaz de defragmentar en caliente), y del mismo modo, defragmentar o reindexar los índices de SQL Server. En caso de disponer de un Cluster MSCS, es útil comprobar el rendimiento en ambos nodos, por si pudiera estar el problema localizado en uno de los nodos del Cluster (ej: en algún defecto de sus tarjetas de fibra HBA, en algún problema con alguno de los caminos existentes hasta la cabina de discos, etc.). También es de interés ejecutar el comando DBCC CHECKDB para comprobar que no existen errores de integridad en nuestras bases de datos (lento, pero coherente ;-). Si se desea, también cabe la posibilidad de descargar y utilizar las herramientas SQLIOSim y SQLIO desde la Web de Microsoft, con el fin cargar y medir el rendimiento del subsistema de entrada/salida de SQL Server.

En caso de servidores de gran actividad, puede ser relevante aumentar el número de controladoras y de puertos de fibra para el acceso a la SAN, y distribuir las distintas cargas de trabajo de entrada/salida entre distintos caminos y LUNs. También puede servir de ayuda, aumentar el número de discos físicos de nuestros RAIDs, aumentar la memoria caché de las controladoras, utilizar distintos niveles de RAID (ej: RAID1 en vez de RAID5 para discos intensivos en escritura), utilizar discos más rápidos, utilizar controladoras más rápidas, etc. En el caso de grandes servidores, en ocasiones se les dota de una única cabina de almacenamiento exclusiva para un servidor (y sólo para él), incluso en ocasiones se les dota de dos o más cabinas de almacenamiento, con el fin de distribuir la carga de trabajo entre las distintas cabinas.

En cualquier caso, tomar contacto con el personal de Soporte de Microsoft (PSS) o con Consultores experimentados, puede ser de gran ayuda cara a solucionar nuestros problemas, y garantizar la entrega de un servicio de calidad y un buen rendimiento (la salud de nuestros sistemas, es nuestra salud ;-).