Tengo un sitio que ejecuta una aplicación muy sensible a IO (Accredo Saturn); Es un paquete de contabilidad/CRM escrito en Delphi con una base de datos local de archivos planos.
Por varias razones históricas, el sitio lo estaba ejecutando en un servidor terminal Windows Server 2008 R2 que se ejecuta en Server 2012 R2 Hyper-V en un Proliant DL380 G9, siendo su DC un antiguo DL380 G7 con SBS 2011 (Exchange ha estado durante mucho tiempo en Office 365 ).
Ahora los actualicé a un nuevo DL380 G10 con Server 2019. El host y el controlador de dominio se ejecutan en 6 x 600 GB 10k SAS en RAID10 (host en su propia partición, una partición grande para el resto) en un P408i-p. con el servidor de escritorio remoto en 4 SSD SATA de uso mixto de 480 GB en RAID10 en un P408i-a. El servidor tiene 2x Xeon 4210 y 64 GB de memoria. Los datos de este software están en un VHDX en la matriz SSD, montado directamente en el servidor de escritorio remoto.
Tienen 18 usuarios, todos los cuales usan el servidor de escritorio remoto para este programa, y 8 usuarios del centro de llamadas también usan un agente del sistema telefónico Unify. Uno o dos usan Edge. Tenía la intención de exagerar un poco con las especificaciones porque este cliente es exigente con la velocidad y, como mencioné, ¡el software es exigente!
El cliente se ha quejado de velocidades lentas dentro del software. Lo probé y descubrí que una operación que tomaba 5 segundos ahora toma hasta 15. La antigua máquina virtual 2008 R2 en el mismo hardware funciona como siempre, por lo que casi parece tener algo que ver con el invitado. .
He ejecutado diskspd sin que ningún usuario haya iniciado sesión (-c100b -b4K -o32 -F8 -T1b -s8b -W60 -d60 -Sh) y veo IOPS de lectura y rendimiento similares en ambas máquinas virtuales, pero con algunas variaciones amplias en los subprocesos en el Nueva máquina virtual 2019. Veo alrededor de 531,41 Mbps y 136 k IOPS en los invitados, pero dos subprocesos menos a 1,9 Mbps en la máquina virtual de 2019. La antigua máquina virtual tiene una velocidad de 520,44 Mbps, pero constantemente entre 72 y 76 por subproceso, excepto por un subproceso que baja a 3,75. El total fue de 133.000 IOPS. Eso está en la matriz SSD.
En comparación, la matriz SSD básica con los mismos parámetros me proporciona 999 Mbps, consistentemente 124-125 Mbps por subproceso y un total de 255k IOPS.
Llevo días investigando esto. Probé la entrada del registro para deshabilitar el balanceador de carga IO, pero fue en vano; no estoy seguro de si se aplica siquiera a 2019. Probé VHDX tanto fijos como dinámicos; incluso intercambié el volumen de datos entre servidores ( es su propio VHDX). He probado la memoria dinámica y estática. He probado NUMA habilitado y deshabilitado.
¡Estoy desesperado y tengo un cliente frustrado que mañana iniciará su centro de llamadas para el año en la antigua máquina virtual!
El 2008 R2 es una VM de generación 1, versión 5, mientras que el 2019 es de generación 2, versión 9.
¡Se agradecería cualquier sugerencia sobre cómo recuperar los IOPS de la misión!
Esta es mi primera publicación, así que me disculpo si no he incluido suficiente información relevante o específica.
Respuesta1
en 6x 600 GB 10k SAS en RAID10
Instalado en un Raid 1 de 2x SSD de alto rendimiento que le brinda lo que: ¿50 veces la IO?
Generalmente: OBTÉN SSD.
En la parte superior, utilice SSD de tamaño estático.
No PUEDES hacer mucho más; sin embargo, tus números parecen una locura. Más de 200.000 IOPS hablan de una programación increíblemente mala.
Respuesta2
Eso no es evidencia de que el problema de rendimiento se deba al almacenamiento.
Analice en detalle el lento flujo de trabajo de la aplicación.
¿Qué rutas de código se necesitan? Perfile cuánto tiempo lleva cada función.
¿Qué consultas a la base de datos hace?
¿Cuántos registros de datos hay y de qué tamaño?
- ¿Cómo maneja la concurrencia, incluidos los bloqueos basados en archivos o bases de datos?
- ¿Utiliza algún recurso externo a través de la red? ¿Cuál es la latencia para esos?
- ¿Cómo se ve la comunicación con el cliente por cable? El cliente podría ser el servidor de terminal en este caso.
Probablemente necesitará la ayuda del proveedor de software para profundizar tanto. Insista en obtener perfiles detallados y visibilidad del tipo que obtendría de un paquete de monitoreo del rendimiento de la aplicación.
Los límites de recursos como CPU, memoria, IOPS y ancho de banda de la red pueden ser la razón por la que las cosas van lentas. Y esas son métricas para medir. Sin embargo, también es posible que la pila de esa aplicación en ese sistema operativo no vaya más rápido incluso si le lanza hardware. La única manera de saberlo es aislar lo que realmente es lento.
Respuesta3
Me acabo de dar cuenta de esto cuando vine aquí para investigar otro tema. El problema se resolvió y se debió a TSFairShare Disk. Desactivar eso resolvió el problema; resulta que es un problema para muchas aplicaciones que utilizan una base de datos a nivel de archivo.
Encontramos la solución enterrada en un foro de Microsoft Dynamics GP. Los detalles de la solución real se resumen aquí:https://www.ryslander.com/disable-fair-sharing-in-windows-server/- para aplicaciones como GP y la aplicación que estábamos usando (Accredo), solo es necesario desactivar FSSDisk; dejamos los demás en paz.
Observo que con Server 2022 el valor predeterminado volvió a estar deshabilitado.