Optimisation mémoire d'un hôte HPVM

L'utilisation de HPVM (aka Integrity VM) pour virtualiser des serveurs HP-UX permet de consolider aisément de nombreuses machines sur un unique hôte.
Néanmoins, la configuration initiale du serveur hôte peut impacter sensiblement la disponibilité mémoire allouable aux VM.
Par exemple, sur un serveur configuré avec peu de personnalisation :

#  kctune | grep -v Default
Tunable                            Value  Expression   Changes
base_pagesize                         64  64
filecache_max                 1027323330  1%           Imm (auto disabled)
filecache_min                 1027323330  1%           Imm (auto disabled)
max_thread_proc                     3000  3000         Immed
maxdsiz                       2063835136  2063835136   Immed
maxdsiz_64bit                34359738368  34359738368  Immed
maxfiles                            2048  2048

# kmeminfo
tool: kmeminfo 10.11 - libp4 9.466 - libhpux 1.309 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.31 64bit Montvale on host "xxxxxx"
core: /dev/kmem live
nbpg: 65536 bytes
hpvm: host
------------------------------ ----------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory       =  1572360   96.0g 100%
Free memory           =    21715    1.3g   1%
User processes        =  1371494   83.7g  87%  details with -user
  Detached SHMEM      =        2  128.0k   0%  details with -shmem
System                =   174935   10.7g  11%
  Kernel              =   143585    8.8g   9%  kernel text and data
    HPVM overhead     =    27803    1.7g   2%  details with -hpvm
    Dynamic Arenas    =    54002    3.3g   3%  details with -arena
      vx_inode_kmcach =     6623  413.9m   0%
      vx_global_kmcac =     5954  372.1m   0%
      spinlock_arena  =     4246  265.4m   0%
      reg_fixed_arena =     3837  239.8m   0%
      FCACHE_ARENA    =     3827  239.2m   0%
      Other arenas    =    29515    1.8g   2%  details with -arena
    Super page pool   =      525   32.8m   0%  details with -kas
    Emergency pool    =    49686    3.0g   3%  system critical reserve
    UAREA's           =      728   45.5m   0%
    Overflow pte's    =      784   49.0m   0%
    Static Tables     =     5956  372.2m   0%  details with -static
      pfdat           =     4798  299.9m   0%
      text            =      559   34.9m   0%  vmunix text section
      bss             =      321   20.1m   0%  vmunix bss section
      inode           =      112    7.0m   0%
      data            =       99    6.2m   0%  vmunix data section
      Other tables    =       65    4.1m   0%  details with -static
  File Cache          =    31350    1.9g   2%  details with -ufc

Si on exclut la surcharge engendrée par HPVM, la quantité de mémoire réservée pour le système est de 9 Go pour une quantité totale de 96 Go, soit plus de 9%.
Si on y ajoute le cache de fichiers, on arrive à presque 11 Go (11,5%)


Au prix de la mémoire installée sur les machines HP Integrity, il est judicieux de se pencher sur son utilisation optimale.


La partie facile 
Le premier levier pour optimiser la mémoire est le cache de fichiers.
La fonction du serveur hôte n'étant pas de distribuer des fichiers ou d'en faire un usage intensif, le bénéfice d'un cache de grande taille est nul.
On peut réduire à une taille fixe de 200 Mo.

# kctune  -v filecache_max
Tunable             filecache_max
Description         Maximum amount of physical memory to be used for caching file I/O data
Module              fs_bufcache
Current Value       205462700
Value at Next Boot  205462700
Value at Last Boot  205462700
Default Value       51365609472 (automatic)
Can Change          Immediately (Automatic Tuning Disabled)

#kctune filecache_min=205462700 filecache_max=205462700

Et voilà, 1,7 Go facilement récupérés et sans douleur.


Déjà optimisé mais un rappel ne fait pas de mal
Sur un serveur équipé de 96 Go, la gestion des pages mémoires peut nécessiter une quantité importante de mémoire.
96 Go = 100663296 Ko soit 25 165 824 pages de 4 ko
Chaque page nécessitant 200 octets, il ne faut pas moins de 4,6 Go pour sa gestion.
Exemple réel sur un serveur avec 58 Go:
taille de page de 4k : 
pfdat = 742328             2.8g 5%
Après l'augmentation de la taille de page à 64k :
pfdat = 2899               181.2m 0%
La modification de la taille de page mémoire de base est heureusement effectuée automatiquement lors de l'installation de HPVM.
Dans les autres cas, la commande est de modification est la suivante :
# kctune base_pagesize=64
Il faut toutefois vérifier que les applications supportent cette modification de taille de page par défaut.


De la faible utilisation des fichiers
Un autre levier très important mais qu'il faut manipuler avec précaution est le nombre d'Inde HFS maximum disponible en mémoire "ninode" ainsi que son pendant pour VXFS "vx_ninode". Comme pour le nombre maximum de descripteurs de fichiers ouvrables en même temps (aka "nfiles"), il est important de prendre toutes les précautions nécessaires avant de toucher à ces "tunables".
Sous HP-UX 11i v3, HFS devient obsolète même pour /stand. On peut donc réduire "ninode" à son minimum. "vx_ninode" devient prépondérant.

#  kctune|grep ninode
ninode                8192  Default
vx_ninode            20000  20000        Immed
Par défaut (lorsque vx_ninode = 0), le nombre d'inode pour des serveurs disposant de plus de 3 Go de ram est de 131072. 

Pour avoir un état à un instant T du taux d'utilisation de la table d'inode, il faut utiliser la commande :
#  vxfsstat -v / | grep maxino
vxi_icache_inuseino            1013    vxi_icache_maxino             20000
ou la commande sar : 

# sar -v 1 1

HP-UX xxxxxxxx B.11.31 U ia64    12/05/11

10:53:35 text-sz  ov  proc-sz  ov  inod-sz  ov  file-sz  ov
10:53:36   N/A   N/A 182/4200  0  1008/28192 0  999/2147483647 0

Le résultat de la commande sar nous renvoie le nombre d'inodes utilisés et le nombre maximum d'inodes HFS et VXFS confondus.
Dans le cas de nos serveurs hôte HPVM, ce nombre a été ramené sans problème à 20000.
# /usr/sbin/kctune vx_ninode=20000

Un redémarrage sera nécessaire à la prise en compte des dernières modifications.


A la fin...
Le résultat après la modification sans risque de ces quelques paramètres : un peu plus de 3 Go récupérés. De quoi donner un peu de flexibilité aux projets hébergés ou consolider encore un peu plus sur cette machine.

tool: kmeminfo 10.11 - libp4 9.466 - libhpux 1.309 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.31 64bit Montvale on host "xxxxxxxx"
core: /dev/kmem live
nbpg: 65536 bytes
hpvm: host
----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory       =  1572355   96.0g 100%
Free memory           =    59109    3.6g   4%
User processes        =  1389015   84.8g  88%  details with -user
  Detached SHMEM      =        1   64.0k   0%  details with -shmem
System                =   124435    7.6g   8%
  Kernel              =   118249    7.2g   8%  kernel text and data
    HPVM overhead     =    44642    2.7g   3%  details with -hpvm
    Dynamic Arenas    =    14956  934.8m   1%  details with -arena
      ALLOCB_MBLK_DA  =     1197   74.8m   0%
      spinlock_arena  =     1129   70.6m   0%
      vx_buffer_kmcac =     1114   69.6m   0%
      FCACHE_ARENA    =     1022   63.9m   0%
      vx_global_kmcac =      967   60.4m   0%
      Other arenas    =     9527  595.4m   1%  details with -arena
    Super page pool   =      190   11.9m   0%  details with -kas
    Emergency pool    =    49686    3.0g   3%  system critical reserve    UAREA's           =      658   41.1m   0%
    Overflow pte's    =      784   49.0m   0%
    Static Tables     =     5983  373.9m   0%  details with -static
      pfdat           =     4798  299.9m   0%
      text            =      563   35.2m   0%  vmunix text section
      bss             =      346   21.6m   0%  vmunix bss section
      inode           =      112    7.0m   0%
      data            =       99    6.2m   0%  vmunix data section
      Other tables    =       64    4.0m   0%  details with -static
  File Cache          =     6186  386.6m   0%  details with -ufc


Une question reste en suspend : quid du "Emergency pool" (system critical reserve)
Je n'ai trouvé aucune référence à sa raison d'être ou à son utilisation.
Si quelqu'un a des informations, je suis preneur.


Références :
- Performance Cookbook :
- Common Misconfigured HP-UX Resources
- HP-UX 11.31 - The Cost of Page Frame Data Table pfdat in Large Memory System
- Tunable Base Page Size
- Kernel parameters for HP-UX systems running Oracle E-Business Suite software applications
- Introduction to performance tuning for HP-UX
- SAP ON HP-UX BEST PRACTICES - PART 2