Au cœur de Windows Seven et de Windows Server 2008 R2

Au cœur de Windows Sevenet de Windows Server 2008 R2 RDA401 – Microsoft Techdays 9 février 2011 – 13h-14h

Présentation des speakers • Hervé Chapalain • EscalationEngineer • Microsoft France • hervech@microsoft.Com • Julien Crozon • Tech lead • Société Générale CorporateInvestmentBanking • http://bugslasher.net • crozon@gmail.com

Agenda • Changements architecturaux du noyau • Troubleshooting • Scalabilité • Diminution de la consommation électrique • Virtual Hard Drive (VHD)

Le Kernel • Windows 7 et Server 2008 R2 utilisent le même kernel • Commeprévu, 2008 R2 Serveurn’existequ’en 64-bit • Wow64 estune option sur la version Core Serveur • Le numéro de version est 6.1 pour des raisons de compatibilité • Ne reflète pas le fait quec’estune nouvelle version majeure • Ne reflète pas la quantité de nouveautés • Anticipe le fait que de nombreuses applications ne sont compatibles que pour Vista au moment de la sortie de win7

MinWin • MinWinest la première étape d’un Windows modulaire • Peutêtrebuildé, booté et testé de manièreautonome • Les couches plus hautespeuventévoluer de manièreindépendante • MinWinest un ensemble de composantsrequis pour booter et accéder au réseau • “le NT de Cutler”: Kernel, file system, TCP/IP stack, device drivers, services • Pas de WMI, graphiques, audio ou shell • MinWin: 160 binaires, 22MB surdisque, 40MB en mémoire

MinWin Shell, Graphics, Multimedia, Layered Services, Applets, Etc. Kernel, HAL, TCP/IP, File Systems, Drivers, Core System Services MinWin

DLL Refactoring • Pour retirer des dépendancessur les couches hautes, il a falluréarchitecturer des DLLs • Les applications en dehors de MinWinutilisent les anciennes DLLs • Ces DLLs transfèrent les appelsvers les APIs MinWin via des DLLs MinWin • Exemple: • Kernel32.dll -> Kernelbase.dll • Advapi32.dll -> Kernelbase.dll

API Sets • Problème : les DLLs contiennentplusieurs ensembles d’APIsdifférentes • Un ensemble d’APIsestlié à uneimplémentation • Les API Sets sont des DLLs virtuelles • L’architecture interne d’une API estséparée de son implémentation • Ellespeuventêtreréuniesdans un mêmebinaire pour unemeilleureefficacité • Les APIS de MinWinsont les premières à êtreimplementéesseloncemodèle : • Ex. api-ms-win-core-errorhandling-l1-1-0.dll

DLLs Virtuellesvers DLLs logiques • Le “mapping” eststockédans un schéma qui estembarquédans Apisetschema.dll • Le Kernel lit le schéma au boot et le “map” danstous les processus pour unemeilleure performance • Le loader utilise le schéma pour charger les DLLs qui n’ont pas de path spécifié • Des images de ces DLLs virtuelles existent sur le système pour des raisons de compatibilité avec des outils type Depends • Elles ne sont toutefois pas utilsées par le loader Loader Virtual DLL 1 ApiSetSchema.dll Logical DLL Virtual DLL 2

Troubleshooting • 3 grandes améliorations pour aider au déplombage d’applications • FaultToleranceHeap (FTH) • ProcessReflection • Radar

TroubleshootingLe FaultToleranceHeap (FTH) • Rappel : qu’est ce qu’un sous-système de ‘heap’ (‘tas’ en français) ? • Le système d’exploitation n’offre qu’une API d’allocation mémoire : VirtualAlloc. La granularité de son allocation est une page mémoire (généralement 4k pour les small pages, 2Mo pour les large page). • Pour éviter de perdre de l’espace, le système offre un sous-système de ‘heap’ qui permet d’allouer de plus petits blocs • Différentes fonctionnalités sont proposées depuis XP : la sérialisation des appels en cas de multithreading, le LFH (Low Fragmentation Heap) pour éviter la fragmentation

TroubleshootingLe FaultToleranceHeap • Idée principale : les corruptions de heap représentent 15% des crash en mode user, 30% des crash lorsque les applications se terminent. Un heap résistant à ce type de problème améliorerait l’expérience utilisateur • Réalisation : • Un nouveau sous-système de heap appliqué dynamiquement par le système d’exploitation permet de réduire les chances d’avoir une faute en cas de dépassement de buffer, de double libération de la mémoire, etc.

TroubleshootingLe FaultToleranceHeap: design • Le système d’exploitation surveille les crash des applications • Si le logiciel crash dans ntuser.dll quatre fois dans l’heure qui suit, le système applique une politique de tolérance de faute • Un système de poids est utilisé afin de choisir la meilleure technique d’évitement de faute • Si le processus crash quand même, le poids est diminué • Si le processus survit, le poids est augmenté • Si le poids tombe en dessous de zéro, la politique de tolérance de faute est supprimée • Les axes sur lesquels le FTH peut agir • Valide toutes les opérations de tas • Garde les 4 derniers Mo libérés en mémoire afin de supporter les doubles libérations • Garde des espaces entre les petites allocations pour éviter les problèmes de débordement • Le FTH ne justifie pas de ne plus corriger les bugs ! • C’est une ‘mitigation’ : un moyen pour que l’expérience utilisateur ne soit pas désagréable • Les bugs remontés doivent être traités

Troubleshooting Démo Le FaultToleranceHeap

TroubleshootingProcessReflection • Idée principale : en environnement de production, quand un processus a des problèmes de mémoire ou qu’il réagit très lentement, la meilleure solution est souvent de prendre un dump pour l’analyser. Malheureusement, c’est une opération lente qui suspend le processus et qui n’est donc pas praticable sur des services à haute disponibilité (serveur Web, base de données, etc.) • Solution : • Créer une copie du processus de la même façon qu’un fork() sous Unix, et créer un dump de cette copie

TroubleshootingProcessReflection : design • Le système d’exploitation expose une nouvelle fonction via ntdll : RtlCreateProcessReflection • L’API est pour l’instant interne • La mémoire est copiée en mode Copy-On-Write : les deux processus partagent les même pages mémoire jusqu’à ce que le processus originel fasse des modifications • L’outil ‘ProcDump’ de SysInternals permet d’utiliser la fonctionnalité

Troubleshooting Démo ProcessReflection

TroubleshootingRadar • Radar est un système de détection automatique de fuites mémoire temps réel • Spécialement conçu pour avoir un très faible impact sur les processus • Récolte suffisamment d’informations pour pouvoir pointer la source de la fuite mémoire • Utilise l’API de ProcessReflection • Implémente une heuristique permettant de choisir quels processus sont suspectés de fuites mémoire (dépassement d’un certain ‘working set’ par exemple) • Quand une fuite est détectée, un rapport est envoyé àMicrosoft • Les ISV peuvent le demander et ainsi corriger leurs programmes

Working Sets • Le Memory Manager a étéoptimisé pour réduirel’impact des processusconsommant beaucoup de VA • Réutilisation de leurs pages plus agressive • Utilise 3bits plutôt que 2bits pour gérer l'âge d'une page • Le System cache, paged pool, et le code system utilisentleurpropre working set • Chacunestoptimisé pour son usage spécifique, ce qui améliorel’utilisationglobale de la mémoire • Réduitl’impact des copies de fichierssur le code système Vista, Server 2008 System Cache, Paged Pool, System Code P1 P2 … Windows 7, Server 2008 R2 System Cache Paged Pool System Code P1 P2 …

Suppression du “PFN Lock” • Windows trace l’état des pages en mémoire physique • En coursd’utilisation (dans un working set) • Pas assignées à un working set (dansune des listessuivantes: free, zero, modified, standby…) • Avant, les changements de cesétatsetaientsynchronisés par le “global PFN (Physical Frame Number) lock” • Aujourd’hui, le PFN lock n’existe plus • Les pages sontsynchroniséesindividuellement • Améliore la performance des applications nécessitant beaucoup de mémoire

Suppression d’autres “Locks” importants • Cache Manager Virtual Address Control Block (VACB) lock • Pas complètementsupprimé, maisn’est plus utilisé pour de nombreusestâchescourantes • Améliore la performance des applications utilisant le file caching de manière intensive • Object Manager Type lock • Améliore la performance des tâchesnécessitant la modification d’objets kernel (synchronization, files, registry)

Suppression du Dispatcher Lock • Les locks serialisentl’accès aux structures de données • Evitentqueplusieurs threads modifientsimultanément les mêmesdonnées • Introduit de la latence car les threads doiventattendreleur tour pour continuer • Le Dispatcher lock estutiliséproportionnellement à l’activité • Le lock protègetous les changements d’états des threads (wait, unwait, etc.) • Ce lock n’existe plus sous Windows 7 • Chaque thread est protégé par son propre lock • De nombreusesopérationssont lock-free

Comment réduire la consommation ? • 4 améliorations pour diminuer la consommation électrique • Core Parking • Unified Background Process Manager (UBPM) • Timercoalescing • PerfConfig.exe

Comment réduire la consommation ? • Motivations • La consommation électrique des serveurs devient de plus en plus problématique • Autonomie de l’embarqué

Comment réduire la consommation ? • Comment consommer peu ? • Maximiser le temps d’idle / d’extinction des CPU • Eteindre les processeurs non nécessaires • Eviter le plus possible de les réveiller • Minimiser le nombre de processus démarrés • Mutualiser les services • Définir des événements qui démarrent des services, plutôt que démarrer des services qui attendent des événements

Comment réduire la consommation ? Le Core Parking • Idée principale : éteindre les core non utilisés • Réalisation : • Le système d’exploitation peut maintenant décider d’endormir indépendamment chaque core (to ‘park’ a core) • Changement de principe du scheduler : celui-ci essaye de garder suffisamment de core éveillés pour absorber la charge demandée, et éteint les autres • Le système connait la topographie physique (sockets et CPU) et logique (hyperthreading, SMT) et adapte son comportement • Le comportement est différent entre Windows Seven et Windows Server 2008 R2

Comment réduire la consommation ? CoreParking : design • Un évènement est levé toutes les 50 ms • Il contrôle la charge des CPU et décide de l’état de chaque core physique pour les prochaines 50 ms • Quel est l’algorithme de décision ? • Cycle en hystérésis : augmente le nombre de CPU éveillés au delà d’un certain seuil d’utilisation, le diminue en deçà d’un autre seuil • Il y a un minimum de core qui ne peuvent être endormis • Sur les systèmes NUMA, au moins un core par nœud doit rester éveillé (pour recevoir les notifications NUMA) • Le scheduler est notifié de la nouvelle politique de parking • Les threads ne sont pas envoyés sur les core endormis (à moins qu’il existe une affinité)

Comment réduire la consommation ? Démo Core Parking

Comment réduire la consommation ? Unifier la gestion des tâches de fond (UBPM) • Idée principale : beaucoup de services ne sont utiles que dans un contexte bien précis, et ne devraient être démarrés que quand c’est nécessaire • Réalisation : • Création de l’infrastructure UBPM (Unified Background Process Manager) servant à démarrer des services selon leurs abonnements à des événements

Comment réduire la consommation ? UBPM : design • Le processus de gestion des services (‘services.exe’) gère les réactions des services aux événements • Les événements sont implémentés en ETW (Event Tracing for Windows) • Chaque service peut s’abonner àun ou plusieurs événements pour déclencher son démarrage ou son arrêt • Exemple : le service de gestion de NetBios (‘lmhosts’) démarre avec la première IP disponible, et s’arrête quand la dernière IP devient indisponible • Exemple : le service de gestion des périphériques BlueTooth (‘bthserv’) démarre au premier périphérique BlueTooth connecté

Comment réduire la consommation ? Démo Service asservi àun événement custom

Comment réduire la consommation ?Rassembler les événements des timer (TimerCoalescing) • Idée principale : beaucoup d’applicatifs utilisent des timer pour être appellés régulièrement, mais n’ont pas de contrainte forte sur le temps écoulé entre chaque appel • Réalisation : • Nouvelle API de ‘TimerCoalescing’ : on peut créer un timer en précisant la tolérance du logiciel vis-à-vis de l’exactitude de la période Timer tick 15.6 ms Periodic Timer Events

Comment réduire la consommation ?Timercoalescing : design • Nouvelle fonction dans l’API Windows : ‘SetWaitableTimerEx’ • Contient un argument en plus, ‘TolerableDelay’, permettant d’indiquer qu’un driver ou un logiciel tolère une incertitude sur la période du timer • Les principaux services systèmes de Windows 7 / Windows Server 2008 R2 utilisent ce type de timer • C’est le choix du développeur de l’utiliser ou non • L’ancienne API fonctionne exactement comme avant pour éviter les effets de bord

Comment réduire la consommation ? Démo Observer le regroupement des timer dans un Windows 7

Comment réduire la consommation ?Utiliser l’outil Powercfg.exe Démo

Comment réduire la consommation ? Analyse des résultats obtenus : distribution du temps passé en idle Move right better Windows* Vista SP1 Windows* 7 Build A Windows* 7 Build B

Les disques durs virtuels (VHD) • Les VHD sont des composants à part entière du système d’exploitation • Support natif dans l’OS • Démonstration • Performances

Les disques durs virtuels (VHD) Un support natif dans le système d’exploitation • La gestion des VHD est disponible directement dans la console de management des disques • Ainsi que via une API Win32 public disponible dans VirtDisk.dll : CreateVirtualDisk, GetVirtualDiskInformation, etc. • Les fonctionnalités standards sont : • Création, attachement d’un fichier à un volume, détachement, etc… • Augmentation de la taille d’un disque, compactage, réunion de deux disques en un seul, etc. • Gestion de VHD imbriqués (deux niveaux maximum) • Boot sur un VHD (et donc ordonnancement des arrêts des disques)

Les disques durs virtuels (VHD) Démo Créer un VHD

Les disques durs virtuels (VHD) : Performances

MSDN et TechNet: l’essentiel des ressources techniques à portée de clic • Portail administration et infrastructure pour informaticiens • Portail de ressources technique pour développeurs http://technet.com http://msdn.com

Au cœur de Windows Seven et de Windows Server 2008 R2