SQL Server tempdb en disco RAM?

Nuestra base de datos de aplicaciones de proveedores es muy intensiva en TempDB.

El servidor es virtual (VMWare) con 40 núcleos y 768 GB de RAM, y ejecuta SQL 2012 Enterprise SP3.

Todas las bases de datos, incluido TempDB, están en SSD de nivel 1 en SAN. Tenemos 10 archivos de datos tempdb, cada uno pre-crecido a 1GB y nunca crecen automáticamente. Lo mismo con el archivo de registro de 70 GB. Las banderas de seguimiento 1117 y 1118 ya están configuradas.

sys.dm_io_virtual_file_stats muestra más de 50 Terabytes leídos / escritos en datos tempdb y archivos de registro en el último mes, con io_stall acumulativo de 250 horas o 10 días.

Ya hemos ajustado el código del proveedor y los SP en los últimos 2 años.

Ahora, estamos pensando en colocar archivos tempdb en la unidad RAM, ya que tenemos un montón de memoria. Dado que tempdb se destruye / recrea cuando se reinicia el servidor, es un candidato ideal para colocar en la memoria volátil que también se vacía cuando se reinicia el servidor.

He probado esto en un entorno inferior y ha resultado en tiempos de consulta más rápidos, pero ha aumentado el uso de la CPU, porque la CPU está haciendo más trabajo en lugar de esperar en la unidad tempdb lenta.

¿Alguien más ha puesto su tempdb en RAM en sistemas de alta producción oltp? ¿Hay alguna desventaja importante? ¿Hay algún proveedor para elegir o evitar específicamente?

Primero, parche: asegúrese de estar en la actualización acumulativa 10 del Service Pack 1 2012 o posterior. En SQL 2014, Microsoft cambió TempDB para estar menos ansioso por escribir en el disco , y lo respaldaron increíblemente a 2012 SP1 CU10 , por lo que puede aliviar mucha presión de escritura TempDB.

En segundo lugar, obtenga números exactos en su latencia. Verifique sys.dm_io_virtual_file_stats para ver la pérdida promedio de escritura para sus archivos TempDB. Mi forma favorita de hacer esto es:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Mire la sección de estadísticas del archivo y concéntrese en las escrituras físicas. Los datos de SinceStartup pueden ser un poco engañosos, ya que también incluyen momentos en que CHECKDB se está ejecutando, y eso realmente puede afectar su TempDB.

Si su latencia de escritura promedio es superior a 3 ms, entonces sí, es posible que tenga almacenamiento de estado sólido en su SAN, pero aún así no es rápido.

Considere primero los SSD locales para TempDB. Los buenos SSD locales (como las tarjetas PCIe NVMe de Intel, que tienen menos de $ 2k USD, especialmente en los tamaños que está describiendo) tienen una latencia extremadamente baja, más baja de lo que puede lograr con el almacenamiento compartido. Sin embargo, en virtud de la virtualización, esto tiene un inconveniente: no puede vMotion al invitado de un host a otro para reaccionar a la carga o a problemas de hardware.

Considere una unidad de RAM al final. Hay dos grandes problemas con este enfoque:

Primero, si realmente tiene una gran actividad de escritura TempDB, la tasa de cambio en la memoria puede ser tan alta que no podrá vMotion al invitado de un host a otro sin que todos lo noten. Durante vMotion, debe copiar el contenido de la RAM de un host a otro. Si realmente está cambiando tan rápido, más rápido de lo que puede copiarlo a través de su red vMotion, puede encontrarse con problemas (especialmente si este cuadro está relacionado con la duplicación, AG o un clúster de conmutación por error).

En segundo lugar, las unidades de RAM son software. En las pruebas de carga que he realizado, no he quedado tan impresionado con su velocidad bajo una actividad de TempDB realmente intensa. Si es tan pesado que un SSD de nivel empresarial no puede seguir el ritmo, entonces también estará gravando el software de la unidad RAM. Realmente querrá cargar esta prueba en gran medida antes de lanzarla en vivo: pruebe cosas como muchas reconstrucciones de índice simultáneas en diferentes índices, todo usando sort-in-tempdb.

Crear una unidad RAM debería ser trivial. Muchas unidades de memoria USB y unidades ópticas de arranque de Linux crean una unidad RAM y almacenan archivos del sistema operativo allí. El sistema de archivos raíz está entonces en la memoria. En Windows, en el pasado, se cargaba una unidad de RAM como controlador de dispositivo en config.sys. Por lo general, el controlador se cargaba en la memoria alta. En mi opinión, esta es una solución muy buena y simple. Si he creado su solución utilizando una unidad de RAM, me gustaría saber de ella. Me gustaría hacer algo similar, pero me gustaría hacer escrituras en el almacenamiento permanente y almacenar un db en RAM. En mi caso, tenemos máquinas que pueden instalar más RAM de la que puede usar el sistema operativo. Crear un disco RAM antes de que se cargue el sistema operativo permitirá la utilización de RAM que el sistema operativo no vería de otra manera.