El rendimiento del inserto aumenta bajo carga: ¿por qué?

Tengo un fragmento de código que realiza inserciones en tablas altamente desnormalizadas. Las tablas tienen un número de columnas que van desde ~ 100 hasta 300+. Este es SQL Server 2008 R2, que se ejecuta en Windows Server 2008.

Cada inserción consiste en insertar en varias tablas bajo la misma transacción. NHibernate agrupa algunos insertos, pero otros no, pero todos están bajo la misma transacción.

Cuando realizo inserciones por ejemplo 500 veces llamando repetidamente a un fragmento de código que realiza la inserción, obtengo un promedio de ~ 360 ms.

Lo extraño es que, cuando ejecuto el código de prueba simultáneamente usando 4 procesos (el mismo exe se ejecuta desde 4 mensajes de comando diferentes en Windows Server 2008), el rendimiento de inserción por llamada mejora mucho. Veo ráfagas que van tan rápido como 90 ms (casi X4 más rápido). Estoy midiendo el tiempo de inserción del código.

Dado que los 4 procesos no saben nada el uno del otro, supongo que esto tiene algo que ver con SQL Server, pero no tengo ni idea de por qué. Me gustaría saber por qué sucede esto y si hay alguna configuración que me permita obtener el mismo rendimiento cuando las inserciones no son tan frecuentes.

Las sugerencias con respecto a los métodos de monitoreo de SQL Server para comprender lo que está sucediendo en el nivel de base de datos son igualmente bienvenidas.

Una posible razón es que cuatro procesos concurrentes generan un patrón más favorable de descargas de registros, lo que generalmente significa que cada descarga de registros escribe más datos que en el caso de un solo proceso de ejecución.

Para determinar si el rendimiento del registro de transacciones / tamaño de descarga es un factor, supervise:

• sys.dm_os_wait_stats para WRITELOGy LOGBUFFERespera
• sys.dm_io_pending_io_requests para el rendimiento de IO
• Contadores de Monitor de rendimiento (o sys.dm_os_performance_counters ) para:
  • Bytes de registro vaciados / seg.
  • Log Flushes / sec
  • Tiempo de espera de descarga de registro

Busque los límites internos que se alcanzan. En SQL Server 2008 R2, puede haber un máximo de 32 E / S de descarga de registro pendientes (asíncronas) por base de datos en las versiones de 64 bits (solo 8 en 32 bits). También hay un límite de tamaño total en las E / S pendientes de 3840 KB.

Más información y lecturas adicionales:

• Monitoreo de registro de transacciones
• Recorte de grasa de registro de transacciones
• Diagnóstico de problemas de rendimiento del registro de transacciones y límites del administrador de registros
• Optimizando el registro de transacciones en todo

Todo @PaulWhite dice, además ...

Si tiene claves foráneas en su lugar, cada inserción requerirá una verificación en cada tabla referenciada. A mí me parece que eres, ya que solo obtienes 360 ms, lo que me parece lento.

De todos modos, verificar esas tablas se ayuda enormemente al tener esos datos en la RAM, en lugar de tener que cargarlos en el disco.

Me parece que cargar los datos en la RAM es una parte importante de su ejecución, y que solo tiene que suceder una vez.

También podría ser un almacenamiento en caché efectivo del plan, y que sus consultas deben compilarse la primera vez, con llamadas posteriores que puedan evitar esa fase.

Algunos servidores / cpus / os recuerdan los patrones. como caché

Como estás haciendo lo mismo 4 veces, estoy seguro de que hay formas en que puede cortar esquinas, lo que supongo es que la primera forma en que lo haces, lo considera como un proceso largo (ejemplo1), pero en la segunda forma ve el código reutilizado y lo ejecuta como caché (ejemplo2) o podría ser el primer proceso demasiado grande para que quepa todo en el (ejemplo de ram3).

ejemplo1: 0111110000110111110000111011111000011110111110000

ejemplo2: 0111110000 | 11 | 0111110000 | 111 | 0111110000 | 1111 | 0111110000

ejemplo3: 0111110000011111000001111100000111110000 ejemplo3: bucle: 0111110000

Sé que el servidor ubuntu hace esto con repetidas consultas mysql. Puedo guardarlos en caché, aunque en realidad la única diferencia en el tiempo es de 10-40 mm, pero se suma. Cuando estaba en la escuela había clases que mostraban que tenía que hacer que los programas (perl / php) usaran ese caché para ser más rápidos.

Pero, puede depender del programa, de qué idioma es, en qué está compilado o cómo fue programado.