Windows ha sido culpado por la lentitud de las operaciones de archivos y la creación de procesos. ¿Alguna vez has tratado de hacerlos aún más lentos? ¡Este artículo mostrará la técnica de cómo ralentizar gradualmente la creación de procesos en Windows (hasta el infinito) de forma invisible para la mayoría de los usuarios!
Y, por supuesto, el artículo también le dirá cómo detectar y evitar este problema.
Este es un problema real que encontré a principios de año, y el artículo explica cómo lo descubrí y encontré una solución. Artículos anteriores sobre la desaceleración de Windows:
Algo anda mal
No busco problemas, pero creo que los encontré. Tal vez porque recojo Chrome de la fuente cientos de veces durante el fin de semana, o tengo mala suerte en la vida. Supongo que nunca lo sabremos. De una forma u otra, este artículo describe el
quinto problema grave que encontré en Windows al construir Chrome.
- Serialización no planificada, lo que conduce a una interfaz de usuario de bloqueo completa: "procesador de 24 núcleos, pero no puedo mover el cursor" .
- Un descriptor de proceso se filtró en uno de los complementos de Microsoft para Windows: "Los procesos de zombis consumen tu memoria" .
- Un error de corrección de larga data en el caché de archivos de Windows: "¿Error del compilador? Error de enlazador? Error del kernel de Windows ".
- Falla de rendimiento cuando se usan incorrectamente las notificaciones de archivos: "Retraso de Windows, Parte 1: acceso a archivos" .
- Y esto: una extraña solución arquitectónica que ralentiza la creación de procesos con el tiempo.
Raro seguimiento de fallas
Las computadoras deben ser confiables y predecibles, y algo más me molesta. Si construyo Chrome varios cientos de veces seguidas, me gustaría ver cada ensamblaje exitoso. Por lo tanto, cuando nuestro proceso de compilación distribuida (gomacc.exe) a veces falla, quiero investigar esto. He configurado
la grabación automática de volcados de memoria , por lo que veo que se producen bloqueos cuando se detecta la corrupción del montón. Una forma fácil de verificar es habilitar el montón de páginas para que el montón de Windows coloque cada asignación de memoria en una página separada. Esto significa que los desbordamientos de uso libre y de búfer causan una falla instantánea en lugar de un daño difícil de diagnosticar. Anteriormente escribí acerca de
habilitar pageheap usando App Verifier .
El verificador de aplicaciones ralentiza el programa por dos razones: las asignaciones de memoria se ralentizan y las asignaciones alineadas a páginas prácticamente desactivan la memoria caché del procesador. Por lo tanto, una ligera desaceleración en el ensamblaje era predecible, y sucedió.
Pero cuando llegué más tarde, la asamblea pareció detenerse por completo. Después de
aproximadamente 7000 pasos de ensamblaje , no se notó ningún progreso.
O (n ^ 2) generalmente no es bueno
Resulta que a Application Verifier le gusta crear archivos de registro. Y no importa que nadie esté mirando estos archivos, los crea por si acaso. Y estos archivos deben tener nombres únicos. Estoy seguro de que me pareció una buena idea dar nombres numéricos a los registros en orden ascendente, como gomacc.exe.0.dat, gomacc.exe.1.dat, etc.
Para obtener nombres numéricos en orden ascendente, debe determinar qué número usar a continuación. La forma más fácil es
probar posibles nombres / números hasta encontrar uno que aún no se haya utilizado. Es decir, intente crear un nuevo archivo llamado gomacc.exe.0.dat, y si ya existe, intente gomacc.exe.1.dat y así sucesivamente.
¿Qué podría salir mal?
De hecho, en el peor de los casos, todo es bastante malo.
Resulta que si realiza una búsqueda lineal de un nombre de archivo no utilizado al crear un proceso, entonces iniciar N procesos requiere operaciones
O (N ^ 2) . El sentido común dicta que los algoritmos O (N ^ 2) son demasiado lentos si no puede garantizar que N siempre permanezca relativamente pequeño.
La gravedad de la situación dependerá del tiempo que lleve verificar la existencia del archivo. Tomé medidas y descubrí que en Windows toma alrededor de 80 microsegundos (80 μs o 0.08 ms). Iniciar el primer proceso es rápido, pero comenzar el proceso número 1000 requiere escanear 1000 archivos de registro ya creados. Tarda 80 ms, y luego aún más.
Una compilación típica de Chrome requiere que el compilador se ejecute unas 30,000 veces. Cada ejecución del compilador requiere el escaneo de N archivos de registro creados previamente, 0.08 ms para verificar cada archivo. Una búsqueda lineal para el siguiente nombre de archivo de registro disponible significa que ejecutar N procesos requiere (N ^ 2) / 2 verificaciones de la existencia del archivo, es decir, 30,000 * 30,000 / 2, que es de 450 millones. Dado que cada verificación de la existencia de un archivo toma 0.08 ms, esto es 36 millones de milisegundos, o 36,000 segundos. Es decir, el tiempo de compilación de Chrome, que generalmente es de cinco a diez minutos, aumentará en otras diez horas.
Maldición
Al escribir este artículo, reproduje el error ejecutando un archivo ejecutable vacío aproximadamente 7000 veces, y vi una curva O (n ^ 2) clara como esta:
Por extraño que parezca, si tomamos la traza ETW y observamos el tiempo promedio de llamadas a CreateFile, entonces para casi todos los archivos el resultado es inferior a cinco microsegundos (un promedio de 4.386 μs en el ejemplo a continuación):
Parece que esto muestra solo la restricción ETW en el seguimiento de E / S de archivos. Los eventos de E / S de archivos rastrean solo el nivel más bajo del sistema de archivos y, sobre Ntfs.sys, hay muchos más niveles, incluidos FLTMGR.SYS y ntoskrnl.exe. Sin embargo, la desaceleración no puede ocultarse por completo: el uso de la CPU es visible en el gráfico de uso de la CPU. La captura de pantalla siguiente muestra el intervalo de tiempo de 548 ms, que representa la creación de un solo proceso. Básicamente, todo el tiempo que lleva escanear unos 6850 posibles nombres de archivos de registro:
¿Te ayudará un disco más productivo?
No
La cantidad de datos procesados es pequeña, y la cantidad de escritura en el disco es aún menor. Durante mis pruebas para reproducir un error, el disco estaba casi completamente inactivo. Este problema está relacionado con la CPU porque se almacenan en caché todos los datos relevantes del disco. E incluso si los costos generales se redujeran en un orden de magnitud, seguirían siendo demasiado grandes. No puede mejorar el algoritmo O (N ^ 2).
Descubrimiento
Este problema en particular se puede detectar buscando en% userprofile% \ appverifierlogs archivos .dat. En
general, puede detectar una desaceleración en la creación de procesos al examinar el rastreo de ETW, y ahora sabe qué buscar.
Solución
La solución más fácil es desactivar el registro. Esto también dejará de llenar el disco con gigabytes de registros. Está deshabilitado por el siguiente comando:
appverif.exe -logtofile disableDespués de deshabilitar el registro, descubrí que mis procesos comenzaron aproximadamente tres veces más rápido (!) Que al comienzo de la prueba, y la desaceleración desapareció por completo. Se crean 7000 procesos verificados de Application Verifier en 1,5 minutos, no en 40 minutos. Con mi archivo por lotes simple para pruebas y un proceso simple, veo las siguientes velocidades de creación de procesos:
- típicamente 200 por segundo (5 ms por proceso)
- 75 por segundo con Application Verifier habilitado pero registro deshabilitado (13 ms por proceso)
- 40 por segundo con Application Verifier activado y el registro activado, al principio ... (25 ms por proceso, el tiempo aumenta gradualmente hasta el infinito)
- 0.4 por segundo después de una compilación de Chrome
Microsoft puede solucionar este problema abandonando el aumento monótono en el número de archivos de registro. Si usaran la fecha y hora actuales como un nombre de archivo (hasta un milisegundo o en una resolución más alta), obtendrían nombres de registros más semánticamente significativos que se crean muy rápidamente prácticamente sin lógica de búsqueda para un archivo único.
Pero Application Verifier ya no es compatible, y los archivos de registro son inútiles de todos modos, así que deshabilítelos.
Información de apoyo
Los archivos por lotes y una secuencia de comandos para recrear el error después de habilitar Application Verifier para empty.exe se pueden encontrar
aquí .
El rastro ETW de alrededor del final del experimento está
aquí .
Otros enlaces:
Datos de tiempo sin procesar utilizados para crear un gráfico.Discusión sobre RedditDiscusión en Hacker NewsPara ver ejemplos de otros algoritmos O (n ^ 2) que se comercializan, consulte
Accidentally QuadraticPara un disfrute más mundano, vea una compilación de video de mis
19 formas diferentes de llegar al trabajo en septiembre : estaba demasiado ocupado para continuar el experimento este mes.