[windows] J'ai la pagedpool qui flanche

Je suis tombé (presque...) par hasard sur une page d'IBM à propos du switch /3GB et de Domino, qui me donne l'occasion de me rafraîchir la mémoire (hem :) sur le sujet. Cette option du noyau Windows (cf C:\boot.ini) en version "Pro" permet de modifier le split de la mémoire virtuelle de chaque processus de 2/2 à 3/1 (user/kernel, on se place sur une archi 32 bits évidemment ; pour info, c'est déjà à 3/1 sur Linux par défaut, grep CONFIG_PAGE_OFFSET /usr/src/linux/.config pour s'en convaincre). Au premier abord, ça a l'air bien cool de pouvoir augmenter la mémoire virtuelle utilisateur des processus, mais ce n'est malheureusement pas aussi simple.

Premier problème : il faut que l'application soit 3GB-aware, c'est-à-dire compilée avec l'option /LARGEADDRESSAWARE de Visual Studio. C'est par exemple le cas d'Exchange, de SQL Server et de Domino. Si le switch /3GB est activé et que l'application n'a pas été compilée avec cette option, le GB restant est perdu.

Deuxième problème : le noyau a la moitié moins d'espace virtuel, et cela affecte tous les processus. En pratique, cela va laisser moins de place pour le cache disque, la paged pool, la non-paged pool et les PTE. Par exemple la valeur maximum de la Paged Pool (celle qui peut être déportée sur disque, ça doit vous rappeler quelquechose) va passer de 491 à 256 MB. Il y a donc plus de chances que les événements 2019 (NonPaged Pool) ou 2020 (Paged Pool) apparaissent dans l'event log. Sous Vista, ça va un peu mieux puisque les tailles des différentes zones du noyau sont dynamiques, ce qui essaie d'empêcher le cas où une zone atteint sa limite maximale alors qu'une autre a encore plein de place.

En plus de /3GB, il est aussi possible sous Windows 2003 de spécifier le switch /USERVA=n, où n est la taille en MB de l'espace virtuel utilisateur (entre 2048 et 3072). Utile pour spécifier un juste milieu entre 2 et 3 GB pour éviter que le noyau ne s'étouffe.

Le switch /3G ne doit pas être confondu avec /PAE, qui permet au noyau de reconnaître plus de RAM, jusqu'à 64 GB selon les systèmes (grep pae /proc/cpuinfo). A moins que les deux switches ne soient utilisés en même temps, ce qui limite à 16 GB. A noter que pour adresser au-delà des 4 GB, un processus doit passer par l'API Address Windowing Extensions.

Les clés de registre pour gérer tout ça se situent dans HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management, en particulier DisablePagingExecutive, LargeSystemCache, NonPagedPoolSize, PagedPoolSize et SystemPages. Sous WinDBG, !vm et !poolused sont vos amis.

Happy kernel memory tuning :)

PS : pendant qu'on parle des switches de boot de Windows, je suis étonné de ne pas voir plus de commentaires à propos de l'arrivée de la fonction SetProcessDEPPolicy() (le seul en Français est là). Allez, /NOEXECUTE=ALWAYSON et on en parle plus.