| Resumen: | |
|
|
El mes pasado, en la primera entrega de esta serie de tres partes, señalé las mejoras del kernel de Windows Vista en las áreas de procesos y E/S.
Esta vez hablaré de los avances sobre la forma en que Windows Vista administra la memoria, así como las mejoras destacadas del inicio, el apagado y la administración de energía del sistema (Primera parte).
Cada versión de Windows® mejora la escalabilidad y el rendimiento, en lo que Windows Vista™ no es diferente. El Administrador de memoria de Windows Vista incluye numerosas mejoras, como el uso más extenso de técnicas de sincronización libres de bloqueo, bloqueo concreto, empaquetado más comprimido de estructuras de datos, E/S de paginación mayor, compatibilidad con arquitecturas modernas de memoria de GPU y uso más eficiente del búfer de traducción de direcciones. Además, ahora la administración de memoria de Windows Vista ofrece asignación dinámica de espacio de direcciones según los requisitos de las diferentes cargas de trabajo.
Existen cuatro características potenciadoras del rendimiento basadas en nuevas tecnologías que hacen su presentación en un sistema operativo en Windows Vista: SuperFetch, ReadyBoost, ReadyBoot y ReadyDrive. Las abordaré con todo detalle más adelante en este artículo.
Espacio dinámico de direcciones de kernel
Windows y las aplicaciones que ejecuta se han encontrado con el obstáculo que presentan los límites de espacio de direcciones de los procesadores de 32 bits. El kernel de Windows se ciñe de forma predeterminada a 2 GB o a la mitad del espacio total de direcciones virtuales de 32 bits, con la otra mitad reservada para uso del proceso cuyo subproceso se esté ejecutando actualmente en la CPU. Dentro de su mitad, el kernel tiene que asignarse a sí mismo, asignar los controladores de dispositivos, la memoria caché del sistema de archivos, las pilas de kernel, las estructuras de datos de códigos por sesión y los búferes no paginados (memoria física bloqueada) y paginados asignados por controladores de dispositivos. Antes de Windows Vista, el Administrador de memoria determinaba en el momento del inicio cuánto espacio de direcciones se debía asignar a estos diversos objetivos, pero esta inflexibilidad a veces conducía a situaciones en las que una de las regiones se llenaba mientras que otras seguían teniendo mucho espacio disponible. El agotamiento de un área puede llevar a errores en la aplicación e impedir que los controladores de dispositivos completen las operaciones de E/S.
En Windows Vista de 32 bits, el Administrador de memoria administra dinámicamente el espacio de direcciones del kernel, y asigna y desasigna el espacio de los distintos usos según requieran las demandas de la carga de trabajo. Así, la cantidad de memoria virtual utilizada para almacenar los búferes paginados puede crecer cuando los controladores de dispositivos piden más, y puede reducirse cuando los controladores la liberan. Por lo tanto, Windows Vista puede ocuparse de una gran variedad de cargas de trabajo. Igualmente, la versión de 32 bits del próximo Windows Server®, cuyo nombre en código es "Longhorn", dará cabida a más usuarios simultáneos de Terminal Server.
Por supuesto, en sistemas de 64 bits de Windows Vista, las restricciones de espacio de direcciones no son actualmente una limitación práctica y, por tanto, no requieren un tratamiento especial, ya que están configuradas de forma óptima.
Prioridades de memoria
Del mismo modo que Windows Vista añade prioridades de E/S (como señalé en la última entrega), también implementa prioridades de memoria. Para entender cómo usa Windows las prioridades de memoria, hace falta comprender cómo implementa el Administrador de memoria su memoria caché, llamada "lista En espera". En todas las versiones de Windows anteriores a Windows Vista, cuando el sistema recuperaba una página física (que suele tener 4 KB de tamaño) propiedad de un proceso, el Administrador de memoria solía colocar la página al final de la lista En espera. Si el proceso quería obtener acceso a la página otra vez, el Administrador de memoria tomaba la página de la lista En espera y la reasignaba al proceso. Cuando un proceso quería utilizar una página nueva de memoria física y no había ninguna libre disponible, el Administrador de memoria le daba la página al principio de la lista En espera. Este esquema trataba todas las páginas en espera esencialmente como iguales, y utilizaba únicamente la hora a la que se colocaron en la lista para ordenarlas.
En Windows Vista, cada página de la memoria tiene una prioridad en un rango de 0 a 7, de modo que el Administrador de memoria divide la lista En espera en ocho listas en las que se almacenan páginas con una prioridad particular. Cuando el Administrador de memoria quiere tomar una página de la lista En espera, primero toma las páginas de las listas con poca prioridad. La prioridad de una página refleja generalmente la del subproceso que causa su asignación en primer lugar. Si la página es compartida, refleja la más alta de las prioridades de memoria de los subprocesos que la comparten. Los subprocesos heredan el valor de prioridad de página del proceso al que pertenecen. El Administrador de memoria utiliza las prioridades más bajas para las páginas que lee del disco cuando anticipa accesos a la memoria de un proceso.
De forma predeterminada, los procesos tienen un valor de prioridad de página de 5, pero las funciones permiten que las aplicaciones y el sistema puedan cambiar el proceso y los valores de prioridad de página de los subprocesos. El punto fuerte de las prioridades de memoria se encuentra sólo cuando las prioridades relativas de las páginas se entienden a gran escala, que es la función de SuperFetch.
SuperFetch
Un cambio considerable del Administrador de memoria está en la forma de administrar la memoria física. La administración de la lista En espera que usaban las anteriores versiones de Windows tiene dos limitaciones. Primero, el establecimiento de prioridades entre las páginas reside sólo en el comportamiento más reciente de los procesos y no anticipa los requisitos futuros de la memoria. Segundo, los datos utilizados para el establecimiento de prioridades se limitan a la lista de páginas propiedad de un proceso en algún punto concreto en el tiempo. Estos defectos pueden tener como resultado situaciones como el "síndrome de después de comer", en el que el usuario deja el equipo un rato y entonces se ejecuta una aplicación que requiere mucha memoria (como un análisis de antivirus o una desfragmentación de disco). Esta aplicación obliga a que el código y los datos que las aplicaciones activas habían guardado en la memoria caché se sobrescriban con las actividades que requieren mucha memoria. Cuando el usuario vuelve, experimenta un rendimiento lento, ya que las aplicaciones tienen que solicitar los datos y el código del disco.
Windows XP incluía compatibilidad con captura previa que mejoraba el rendimiento del inicio de aplicaciones y el arranque al realizar E/S de discos grandes para cargar de antemano la memoria con los datos del sistema de archivos y el código esperados, según inicios anteriores de arranque y aplicaciones. Windows Vista va un paso más allá con SuperFetch, un esquema de administración de memoria que mejora el enfoque al que se obtuvo acceso menos recientemente con información histórica y administración proactiva de memoria.
SuperFetch está implementado en %SystemRoot%\System32\Sysmain.dll como servicio de Windows que se ejecuta dentro de un proceso de host del servicio (%SystemRoot%\System32\Svchost.exe). El esquema depende del Administrador de memoria, para poder recuperar los historiales de uso de páginas así como dirigir al Administrador de memoria para cargar de antemano los datos y el código de los archivos en disco o de un archivo de paginación en la lista En espera y asignar las prioridades a las páginas. El servicio SuperFetch esencialmente amplía el seguimiento de páginas a datos y código que estuvieran alguna vez en la memoria, pero que el Administrador de memoria volviera a usar para hacer sitio a otros datos y código nuevos. Almacena esta información en archivos de escenario con la extensión .db en el directorio %SystemRoot%\Prefetch junto con archivos estándares de captura previa empleados para optimizar el inicio de la aplicación. Gracias a este conocimiento profundo del uso de la memoria, SuperFetch puede cargar de antemano los datos y el código cuando la memoria física está disponible.
Siempre que la memoria se quede libre, por ejemplo, cuando una aplicación salga o libere memoria, Superfetch pedirá al Administrador de memoria que capture los datos y el código recientemente desechados. Esto se lleva a cabo con una tasa de unas pocas páginas por segundo con E/S de prioridad muy baja, de modo que la carga previa no tenga efectos para el usuario ni para otras aplicaciones activas. Por lo tanto, si deja el equipo para ir a comer y una tarea secundaria que requiera mucha memoria hace que el código y los datos de sus aplicaciones activas se desechen de la memoria mientras ha salido, normalmente SuperFetch podrá reponer todo, o la mayor parte, en la memoria antes de que vuelva. SuperFetch incluye también compatibilidad específica con escenarios para los modos de hibernación y de espera, el cambio rápido de usuario (FUS) y el inicio de aplicaciones. Cuando el sistema hiberna, por ejemplo, SuperFetch almacena los datos y el código en un archivo de hibernación esperado (basado en hibernaciones anteriores), al que tendrá acceso durante la subsiguiente reanudación. En cambio, si reanuda Windows XP, cuando solicite los datos que estaban en la memoria caché, habrá que volver a leerlos del disco.
Consulte la barra lateral "Acerca de SuperFetch" para obtener más información sobre el efecto que tiene SuperFetch en la memoria disponible.
Acerca de SuperFetch
Después de usar el sistema Windows Vista un rato, verá un número bajo en el contador de memoria física libre en la página de rendimiento del Administrador de tareas. Eso es porque SuperFetch y el almacenamiento en caché de Windows estándar hacen uso de toda la memoria física disponible para guardar en la memoria caché los datos de disco. Por ejemplo, cuando arranca por primera vez, si ejecuta inmediatamente el Administrador de tareas, debería advertir el valor de la memoria libre en disminución conforme el número de la memoria caché aumenta. O bien, si ejecuta un programa que necesita mucha memoria y después lo cierra (irá bien cualquiera de los "optimizadores de RAM" de software gratuito que asignan grandes cantidades de memoria y después la liberan) o sencillamente copia un archivo muy grande, el número Libre aumentará y el gráfico Uso de memoria física caerá conforme el sistema recupere la memoria desasignada. Sin embargo, con el tiempo, SuperFetch volverá a llenar la memoria caché con los datos obligados a salir de la memoria, de modo que el número En caché subirá y el número Libre disminuirá.
ReadyBoost
La velocidad de las CPU y las memorias están dejando atrás rápidamente a la de los discos duros, de modo que los discos suelen ser un cuello de botella en el rendimiento del sistema.
La E/S aleatoria de disco es especialmente costosa porque el tiempo de búsqueda del cabezal de disco está entorno a los 10 milisegundos, una eternidad para los procesadores actuales de 3 GHz. Mientras que la RAM es ideal para guardar en caché los datos de disco, es relativamente costosa. La memoria flash, sin embargo, suele ser más barata y puede atender las lecturas aleatorias hasta 10 veces más rápido que un disco duro normal. Windows Vista, por lo tanto, incluye una característica llamada ReadyBoost para aprovechar los dispositivos de almacenamiento de memoria flash con la creación de una capa intermedia de almacenamiento en caché que se encuentre lógicamente entre la memoria y los discos.
ReadyBoost consiste en un servicio implementado en %SystemRoot%\System32\Emdmgmt.dll, que se ejecuta en un proceso de host del servicio, y un controlador de filtro de volumen, %SystemRoot%\System32\Drivers\Ecache.sys. Emd es el dispositivo de memoria externo, el nombre de trabajo de ReadyBoost durante su desarrollo. Al insertar un dispositivo de memoria flash (como una llave USB) en un sistema, el servicio ReadyBoost comprueba el dispositivo para determinar sus características de rendimiento y almacena los resultados de la prueba en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, como se muestra en la figura 1.
Figura 1 Resultados de la prueba del dispositivo de ReadyBoost en el Registro
Si todavía no utiliza ningún dispositivo para guardar en caché, y el nuevo dispositivo es de un tamaño de 256 MB a 32 GB, tiene una tasa de transferencia de 2,5 MB/s o más en las lecturas aleatorias de 4 KB y una tasa de transferencia de 1,75 MB/s o más en las escrituras aleatorias de 512 KB, entonces ReadyBoost preguntará si quiere dedicar hasta 4 GB del almacenamiento para el almacenamiento en caché de disco. Aunque ReadyBoost pueda utilizar NTFS, limita el tamaño máximo de caché a 4 GB para adaptarse a las limitaciones de FAT32. Si está de acuerdo, entonces el servicio creará un archivo de almacenamiento en caché llamado Readyboost.sfcache en la raíz del dispositivo y pedirá a SuperFetch que rellene previamente la memoria caché en segundo plano.
Después de que el servicio ReadyBoost haya iniciado el almacenamiento en caché, el controlador del dispositivo de Ecache.sys interceptará todas las lecturas y escrituras de los volúmenes de disco duro local (C:\, por ejemplo) y copiará cualquier dato que se escriba en el archivo de almacenamiento en caché que el servicio haya creado.
Ecache.sys comprime los datos y suele alcanzar una proporción de compresión de 2:1, por lo que un archivo de caché de 4 GB contendría 8 GB de datos. El controlador cifra cada bloque que escribe con el Estándar de cifrado avanzado (AES) mediante una clave de sesión por arranque generada aleatoriamente para garantizar la privacidad de los datos en la memoria caché si el dispositivo se retira del sistema.
Cuando ReadyBoost observa lecturas aleatorias que se pueden satisfacer desde la memoria caché, las atiende desde allí, pero debido a que el acceso de lecturas secuenciales es mejor en un disco duro que en una memoria flash, permite que las lecturas que forman parte de las pautas de accesos secuenciales vayan directamente al disco, aunque los datos estén en la memoria caché.
Figura 1 Resultados de la prueba del dispositivo de ReadyBoost en el Registro (Hacer clic en la imagen para reducirla)
ReadyBoot
Windows Vista utiliza la misma captura previa al iniciar que Windows XP si el sistema tiene menos de 512 MB de memoria, pero si el sistema tiene 700 MB o más de RAM, utiliza una caché en RAM para optimizar el proceso de arranque. El tamaño de la memoria caché depende de la RAM total disponible, pero es suficientemente grande para crear una caché razonable y aún así otorgarle al sistema la memoria que necesita para arrancar sin problemas.
Después de cada arranque, el servicio ReadyBoost (el mismo servicio que implementa la característica ReadyBoost recién descrita) utiliza el tiempo de inactividad de la CPU para calcular el plan de almacenamiento en caché al iniciar para el siguiente arranque. Analiza la información de seguimiento de archivos de los cinco arranques anteriores e identifica a qué archivos se tuvo acceso y dónde residen en el disco. Almacena los seguimientos procesados en %SystemRoot%\Prefetch\Readyboot como archivos .fx y guarda el plan del almacenamiento en caché en HKLM\System\CurrentControlSet\Services\Ecache\Parameters en valores REG_BINARY denominados según los volúmenes internos de disco a los que hacen referencia.
La memoria caché se implementa mediante el mismo controlador de dispositivo que implementa el almacenamiento en caché de ReadyBoost (Ecache.sys), pero el llenado de la memoria caché se rige por el servicio ReadyBoost al iniciarse el sistema. Mientras la memoria caché de arranque se comprime como la memoria caché de ReadyBoost, otra diferencia entre la administración de la memoria caché de ReadyBoost y la de ReadyBoot es que en el modo ReadyBoot, a excepción de las actualizaciones del servicio ReadyBoost, la memoria caché no cambia para reflejar los datos que se leen o escriben durante el arranque. El servicio ReadyBoost elimina la memoria caché 90 segundos después del comienzo del arranque, o si las necesidades de otra memoria lo exigen, y registra la estadística caché en HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, como se muestra en la figura 2. Las pruebas de rendimiento de Microsoft muestran que ReadyBoot ofrece mejoras de rendimiento de alrededor del 20 por ciento sobre la captura previa heredada de Windows XP.
Figura 2 Estadística del rendimiento de ReadyBoot
ReadyDrive
ReadyDrive es una característica de Windows Vista que aprovecha las nuevas unidades de disco duro híbrido llamadas H-HDD. Un H-HDD es un disco con una memoria flash permanente incrustada (también conocida como NVRAM). Los H-HDD más comunes incluyen entre 50 MB y 512 MB de caché, pero el límite de caché de Windows Vista es de 2 TB.
Windows Vista utiliza los comandos ATA-8 para definir los datos de disco que se van a incluir en la memoria flash. Por ejemplo, Windows Vista guardará los datos de arranque en la memoria caché cuando el sistema se apague, permitiendo así que se reinicie más rápido. Almacena también partes de los datos de archivo de hibernación en la memoria caché cuando el sistema hiberna para que la subsiguiente reanudación sea más rápida. Dado que la memoria caché se habilita aun cuando el disco mantiene una velocidad baja de giro, Windows puede utilizar la memoria flash como caché de escritura en disco, que evita aumentar la velocidad de giro del disco cuando el sistema se está alimentando de la batería. Al mantener el eje del disco desactivado, se puede ahorrar buena parte de la energía que consume la unidad de disco en uso normal.
Base de datos de configuración de arranque
Windows Vista ha mejorado varios aspectos del inicio y el apagado. El inicio ha mejorado con la introducción de la base de datos de configuración de arranque (BCD) para almacenar la configuración de inicio del sistema y del sistema operativo, los procesos de inicio de nuevo flujo y de organización del sistema, la nueva arquitectura de inicio de sesión y la compatibilidad con los servicios de inicio automático demorado. Los cambios en el apagado de Windows Vista incluyen los avisos de apagado para los servicios de Windows, solicitud de apagado de los servicios de Windows y un cambio considerable en la forma en que el sistema operativo administra las transiciones de estado de energía.
Uno de los cambios más visibles en el proceso de inicio es la ausencia de Boot.ini en la raíz del volumen del sistema. Eso es porque la configuración de arranque, que en versiones anteriores de Windows se almacenaba en el archivo de texto Boot.ini, ahora se almacena en la BCD. Una de las razones por las que Windows Vista utiliza la BCD es que unifica las dos arquitecturas actuales de arranque compatibles con Windows: MBR y EFI. MBR se usa generalmente en sistemas de escritorio x86 y x64, mientras que EFI se usa en sistemas basados en Itanium (aunque es probable que los equipos de escritorio admitan EFI en un futuro próximo). La BCD resume el firmware y tiene otras ventajas sobre Boot.ini, como la compatibilidad con cadenas Unicode y los ejecutables alternativos de arranque previo.
La BCD se almacena en el disco en un subárbol de registro que se carga en el registro de Windows para obtener acceso mediante API de registro. En los equipos, Windows la almacena en Boot\Bcd en el volumen del sistema. En sistemas EFI, está en la partición del sistema EFI. Cuando se carga el subárbol, aparece en HKLM\Bcd00000000, pero el formato interno está sin documentar, así que editarlo requiere el uso de una herramienta como %SystemRoot%\System32\Bcdedit.exe. Las interfaces para manipular la BCD también se encuentran disponibles para las secuencias de comandos y los editores personalizados mediante el Instrumental de administración de Windows (WMI) y podrá utilizar la utilidad de configuración del sistema de Windows (%SystemRoot%\System32\Msconfig.exe) para editar o agregar los parámetros básicos, como las opciones de depuración del kernel.
La BCD divide la configuración de arranque de gran plataforma, como la selección predeterminada del sistema operativo y el tiempo de espera del menú de arranque, a partir de la configuración específica del sistema operativo, como las opciones de arranque de sistema operativo y la ruta de acceso al cargador del arranque del sistema operativo.
Por ejemplo, en la figura 3 se muestra que cuando se ejecuta Bcdedit sin opciones de línea de comandos, muestra la configuración de la plataforma en la sección del Administrador de arranque de Windows a la cabeza del resultado, seguida de la configuración específica del sistema operativo en la sección del cargador de arranque de Windows.
Figura 3 Configuración que se muestra en BCDEdit
Cuando inicia una instalación de Windows Vista, este nuevo esquema divide las tareas del cargador de sistema operativo (Ntldr) en versiones anteriores de Windows en dos archivos ejecutables diferentes: \BootMgr y %SystemRoot%\System32\Winload.exe. Bootmgr lee la BCD y muestra el menú de arranque del sistema operativo, mientras que Winload.exe se ocupa de la carga del sistema operativo. Si realiza un arranque limpio, Winload.exe cargará los controladores de dispositivos de inicio del arranque y los archivos del sistema operativo centrales, incluso Ntoskrnl.exe, y transferirá el control al sistema operativo. Si el sistema se está
Bootmgr incluye también compatibilidad para archivos ejecutables adicionales de arranque previo. Windows Vista viene con la herramienta de diagnóstico de memoria de Windows (\Boot\Memtest.exe) preconfigurada como opción para comprobar la salud de la RAM, pero otros fabricantes pueden agregar sus propios archivos ejecutables de arranque previo como opciones que aparecerán en el menú de arranque de Bootmgr.
Procesos de inicio
En versiones anteriores de Windows, la relación entre varios procesos de sistema era poco intuitiva. Por ejemplo, cuando el sistema arranca, el administrador interactivo de inicio de sesión (%SystemRoot%\System32\Winlogon.exe) inicia el servicio Subsistema de autoridad de seguridad local (Lsass.exe) y el Administrador de control de servicios (Services.exe). Además, Windows utiliza un contenedor de espacio de nombres llamado Sesión para aislar los procesos que se ejecutan en sesiones de inicio diferentes. Pero antes de Windows Vista, el usuario iniciaba la sesión en la Sesión 0 (compartida por la consola), la sesión utilizada por los procesos de sistema, que creaba problemas potenciales de seguridad. Dicho problema aparecía, por ejemplo, cuando un servicio de Windows mal escrito ejecutándose en la Sesión 0 mostraba una interfaz de usuario en la consola interactiva, lo que permitía que el código malintencionado pudiera atacar la ventana mediante intrusiones y obtener posiblemente los privilegios administrativos.
Para abordar estos problemas, se volvieron a diseñar varios procesos del sistema para Windows Vista. El Administrador de sesión (Smss.exe) es el primer proceso en modo de usuario creado durante el arranque como en versiones anteriores de Windows, pero en Windows Vista el Administrador de sesión inicia una segunda instancia de sí mismo para configurar la Sesión 0, que se dedica únicamente a procesos de sistema. El proceso del Administrador de sesión para la Sesión 0 inicia la aplicación de inicio de Windows (Wininit.exe), un proceso de subsistema de Windows (Csrss.exe) para la Sesión 0 y, a continuación, se cierra. La aplicación de inicio de Windows continúa iniciando el Administrador de control de servicios, el Subsistema de autoridad de seguridad local y un proceso nuevo, el Administrador de sesión local (Lsm.exe), que administra las conexiones de Terminal Server en el equipo.
Cuando un usuario inicia la sesión en el sistema, el Administrador de sesión inicial crea una instancia nueva de sí mismo para configurar la nueva sesión. El nuevo proceso de Smss.exe inicia un proceso del subsistema de Windows y un proceso de Winlogon para la sesión nueva. El hecho de tener las copias principales de uso de sí mismo del Administrador de sesión para
Con esta nueva arquitectura, los procesos del sistema, incluidos los servicios de Windows, quedan aislados en la Sesión 0. Si un servicio de Windows, que se ejecuta en la Sesión 0, muestra una interfaz de usuario, el servicio Detección de servicios interactivos (%SystemRoot%\System32\UI0Detect.exe) lo notificará a cualquier administrador de inicio de sesión con el inicio de una instancia de sí mismo en el contexto de seguridad del usuario y la presentación del mensaje que aparece en la figura 4. Si el usuario selecciona el botón "Mostrarme el mensaje", el servicio alternará entre el escritorio y el escritorio del servicio de Windows, donde el usuario podrá interactuar con la interfaz de usuario del servicio y después volver a su propio escritorio. Para obtener más información sobre lo que sucede al inicio, consulte la barra lateral "Visualización de las relaciones del proceso de inicio".
Figura 4 El servicio ha mostrado una ventana
Visualización de las relaciones del proceso de inicio
Podrá utilizar Process Explorer de Sysinternals (microsoft.com/technet/sysinternals) para ver el árbol de inicio de procesos de Windows Vista.
La captura de pantalla incluye la columna Sesión, que se puede agregar mediante el cuadro de diálogo de la columna Process Explorer. El proceso resaltado es el Smss.exe inicial. Debajo está el Csrss.exe y el Wininit.exe de la Sesión 0, que están justificados a la izquierda porque su proceso primario, la instancia de Smss.exe configurada por la Sesión 0, se ha cerrado. Los tres secundarios de Wininit son Services.exe, Lsass.exe y Lsm.exe.
Process Explorer identifica un conjunto de procesos en ejecución en la Sesión 1, que es la sesión a la que estoy conectado a través de una conexión del Escritorio remoto.
Process Explorer muestra los procesos que se ejecutan en su misma cuenta resaltados en azul. Finalmente, la Sesión 2 se inicia en preparación de que un usuario se conecte con la consola y cree una sesión de inicio nueva. Es en esta sesión donde Winlogon se ejecuta y utiliza LogonUI para pedir al nuevo usuario de la consola que "Presione Ctrl+Alt+Supr para iniciar una sesión", y donde Logonui.exe solicitará al usuario sus credenciales.
Proceso de inicio e información de sesión
Proveedores de credenciales
Incluso la arquitectura de inicio de sesión cambia en Windows Vista. En versiones anteriores de Windows, el proceso de Winlogon cargaba la DLL de autenticación e identificación gráfica (GINA) especificada en el registro para mostrar una IU de inicio de sesión que pedía a los usuarios sus credenciales. Desgraciadamente, el modelo GINA sufre varias limitaciones: sólo se puede configurar un GINA, la escritura de un GINA completo es difícil para otros fabricantes y los GINA personalizados que no tienen interfaces de usuario estándares cambian la experiencia del usuario de Windows.
En vez de un GINA, Windows Vista utiliza la nueva arquitectura de proveedor de credenciales. Winlogon inicia un proceso separado, el host de interfaz de usuario de inicio de sesión (Logonui.exe), que carga los proveedores de credenciales configurados en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Logonui puede alojar múltiples proveedores de credenciales simultáneamente; de hecho, Windows Vista se entrega con proveedores interactivos (Authui.Dll) y de tarjetas inteligentes (Smart-cardcredentialprovider.dll). Para garantizar una experiencia de usuario uniforme, LogonUI administra la interfaz de usuario que ven los usuarios finales, pero permite también a los proveedores de credenciales especificar elementos personalizados, como texto, iconos y controles de edición.
Servicios de inicio automático demorado
Si alguna vez ha iniciado la sesión en un sistema de Windows inmediatamente después de que se inicie, habrá experimentado probablemente alguna demora antes de que el escritorio esté configurado completamente y pueda interactuar con el shell y cualquier aplicación que inicie. Mientras está iniciando la sesión, el Administrador de control de servicios inicia los diversos servicios de Windows configurados como servicios de inicio automático que, por lo tanto, se activan al iniciar. Muchos servicios realizan inicializaciones que exigen mucho a la CPU y a los discos, y que compiten con sus actividades de inicio de sesión. Con el fin de mejorar este aspecto, Windows Vista introduce un servicio nuevo para el inicio llamado inicio automático demorado, que pueden utilizar los servicios si no tienen que estar activos inmediatamente después del arranque de Windows.
El Administrador de control de servicios inicia los servicios configurados para el inicio automático demorado después de que los servicios del inicio automático han terminado de iniciarse y establece la prioridad del subproceso inicial en THREAD_PRIORITY_LOWEST. Este nivel de prioridad es la causa de que toda la E/S de disco que el subproceso realiza tenga prioridad de E/S muy baja. Cuando un servicio termina de inicializarse, el Administrador de control de servicios establece su prioridad en normal. La combinación del inicio demorado, la prioridad baja de CPU y memoria, y la prioridad en segundo plano de disco reduce mucho las interferencias con un inicio de sesión de usuario. Muchos servicios de Windows, incluidos la transferencia inteligente en segundo plano, Cliente de Windows Update y Windows Media® Center, utilizan el nuevo tipo de inicio para ayudar a mejorar el rendimiento de inicio de sesión después de un arranque.
Apagado
Un problema que ha acosado a los escritores de los servicios de Windows es que durante un apagado de Windows hay, de forma predeterminada, un máximo de veinte segundos para realizar una limpieza general. Las versiones de Windows anteriores a Windows Vista no han sido compatibles con un apagado limpio que espera a que todos los servicios se cierren porque un servicio de depuración de errores puede mantener en espera un apagado indefinidamente. Algunos servicios, como los que tienen operaciones de apagado relacionadas con la red o tienen que guardar grandes cantidades de datos en el disco, quizás requieran más tiempo, por lo que Windows Vista ofrece un servicio para solicitar avisos de apagado.
Cuando Windows Vista se apaga, el Administrador de control de servicios notifica primero a los servicios que solicitan aviso de apagado. Esperará indefinidamente a que estos servicios terminen, pero si tienen un error y no responden a consultas, el Administrador de control de servicios renunciará y seguirá adelante pasados tres minutos. Una vez que todos estos servicios hayan terminado o el tiempo de espera haya caducado, el Administrador de control de servicios seguirá con el apagado de los servicios de tipo heredado para el resto de los servicios. La directiva de grupo y los servicios de Windows Update registran el aviso de apagado en una instalación actualizada de Windows Vista.
La directiva de grupo y los servicios de Windows Update utilizan también otra característica de los servicios de Windows Vista: orden de apagado. Los servicios siempre han podido especificar las dependencias de inicio que el Administrador de control de servicios sigue para iniciar los servicios en un orden que los satisfaga, pero hasta Windows Vista no se han podido especificar las dependencias de apagado. Ahora los servicios que se registran para los avisos de apagado se pueden insertar a sí mismos en la lista almacenada en HKLM\System\CurrentControlSet\Control\PreshutdownOrder y el Administrador de control de servicios los apagará según su orden. Consulte la barra lateral "Identificación de un servicio de inicio automático demorado y aviso de apagado" para obtener más información sobre estos servicios.
Administración de energía
La suspensión y la hibernación son otras formas de apagado. La administración de energía de depuración de errores en controladores y aplicaciones ha sido problemática desde que Windows 2000 introdujo la administración de energía en la línea de base de Windows NT® de los sistemas operativos de Windows. Muchos usuarios esperaban que su equipo portátil se suspendiera o hibernara al cerrar la tapa antes de embarcarse en un viaje y, al llegar a su destino se han encontrado sólo una maleta caliente, una batería agotada y datos perdidos. Esto es porque Windows siempre ha pedido a los controladores de dispositivos y las aplicaciones su consentimiento para cambiar el estado de energía, y un solo controlador o aplicación que no responde podría impedir la transición.
En Windows Vista, el Administrador de energía del kernel todavía informa a los controladores y las aplicaciones de los cambios de estado de energía para que puedan prepararse, pero ya no solicita permiso. Además, el Administrador de energía espera, como máximo, 20 segundos para que las aplicaciones respondan a las notificaciones de cambio, en lugar de los dos minutos que esperaba en versiones anteriores de Windows. Como resultado, los usuarios de Windows Vista pueden estar más seguros de que sus sistemas respetan la hibernación y la suspensión.
Próximamente
Tal como mencioné antes, esta es la segunda entrega de una serie de tres. La primera parte trataba las mejoras del kernel de Windows Vista en las áreas de E/S y procesos. Esta vez, me he centrado en las mejoras de Windows Vista en cuanto a la administración de la memoria, el inicio y el apagado. La próxima vez, concluiré la serie con la descripción de los cambios del kernel en cuanto a confiabilidad y seguridad.
No hay comentarios:
Publicar un comentario