Je viens d'être prévenu que le patch résolvant le problème de fuite mémoire de mon précédent billet va sortir à la fin du mois.
Il portera le nom : PHKL_38436 sera intégré au bundle de patchs standard Juin 2008.
Toutefois, il faudra désinstaller le patch initial avant d'installer le nouveau.
Un thread a été ouvert sur ITRC à propos de ce problème
11 juin 2008
Un peu de GTD pour Outlook
Pour les utilisateurs de GTD mais malheureusement un utilisateur forcé de Outlook, il existe une petite extension permettant d'appliquer la fameuse méthode tout en restant dans le cadre de l'outil de communication de l'entreprise. Il s'agit de Jello.Dashboard
Il s'agit d'un ensemble de page html et de javascript remplaçant judicieusement la page de démarrage de Outlook.
Jello est gratuit (contrairement au plugin du père de la méthode), paramétrable à souhait, traduit en Français et agréable à utiliser.
Les projets n'ont plus aucune raison de ne plus avancer ou d'être oubliés dans un coin !
Découvert via LifeHacker
Il s'agit d'un ensemble de page html et de javascript remplaçant judicieusement la page de démarrage de Outlook.
Jello est gratuit (contrairement au plugin du père de la méthode), paramétrable à souhait, traduit en Français et agréable à utiliser.
Les projets n'ont plus aucune raison de ne plus avancer ou d'être oubliés dans un coin !
Découvert via LifeHacker
3 juin 2008
Memory leak dans HP-UX.
Après 3ème blocage d'un serveur HP-UX 11i v2 hébergeant Integrity VM, l'analyse du dump a montré un manque cruel de mémoire. Ce symptôme avait déjà été détecté lors de l'analyse du 1er blocage. Le taux de réservation mémoire étant très proche de 100%, le problème "pouvait" avoir pour cause une réelle surchage mémoire. Mais ma foi dans les systèmes Unix me laissait penser le contraire. Les 3 libérations de 500 Mo "empruntés" aux machines virtuelles devait mettre le système à l'abri d'un nouveau crash.
Mais cela n'a pas été le cas.
Symptomes : le serveur répond au ping mais pas les VM. Impossible de se connecter. Aucune réponse, aucune banière de login, même via la console.
Solution : TOC (Transfer Of Control) lancé depuis le MP (commande TC dans le menu CM)
Analyse : après le redémarrage du serveur, le crash dump est enregistré dans le répertoire /var/adm/crash (cf. savecrash, crashconf). En lançant crashinfo (disponible dans les HATOOLS) depuis le répertoire du dernier dump ayant eu lieu, on distingue plusieurs informations interessantes :
...
Note: Crash event 0 was a INIT !
=> Le crash a bien été généré par notre TOC.
...
Physical Memory = 16759774 pages (63.93 GB)
Free Memory = 29617 pages (115.69 MB)
Average Free Memory = 29554 pages (115.45 MB)
gpgslim = 62464 pages (244.00 MB)
lotsfree = 253952 pages (992.00 MB)
desfree = 62464 pages (244.00 MB)
minfree = 30976 pages (121.00 MB)
Note: Free memory is desperately low (freemem <>
...
=> Il y a un manque criant de mémoire libre.
Top 10 kernel memory arenas
===========================
Arena Pages
----- -----
M_TEMP 809934 (3.09 GB)
VFD_BT_NODE 107151 (418.56 MB)
...
Tiens !? Qu'est ce que cette "arena" M_TEMP de 3 Go fait ici ?
Regardons de plus près avec "kmeminfo"
Physical memory = 16759774 63.9g 100%
Free memory = 29617 115.7m 0%
User processes = 14150001 54.0g 84% details with -user
System = 2538237 9.7g 15%
Kernel = 2370640 9.0g 14% kernel text and data
Dynamic Arenas = 1231596 4.7g 7% details with -arena
M_TEMP = 809934 3.1g 5%
VFD_BT_NODE = 107151 418.6m 1%
vm_pfn2v_arena = 65720 256.7m 0%
vx_global_kmcac = 56049 218.9m 0%
spinlock = 47548 185.7m 0%
Other arenas = 145194 567.2m 1% details with -arena
Super page pool = 2223 8.7m 0% details with -kas
Static Tables = 597275 2.3g 4% details with -static
pfdat = 392819 1.5g 2%
vhpt = 131072 512.0m 1%
bufhash = 32768 128.0m 0% bufcache hash headers
nbuf = 14512 56.7m 0% bufcache headers
bufmap = 8183 32.0m 0% bufmap->bm_bitmap
Other tables = 17920 70.0m 0% details with -static
Buffer cache = 167597 654.7m 1% details with -bufcache
Encore un peu plus près : kmeminfo -arena M_TEMP
Variable arena "M_TEMP" owns 809934 pages (3.1gb):
kmem_arena_t 0xe00000015c00c780
Attributes: KMT_DEFAULT KT_DEFAULT KAS_ALIVE
Per index summary (all cpu's):
idx objsz pages bytes % nobjs used free %
0 24 804043 3.1g 99 101309418 101308889 529 0
1 56 8 32.0k 0 504 92 412 82
804043 pages mémoires utilisées !
Après investigation avec le support HP, nous avons trouvé qu'il s'agit d'un bug connu depuis peu. Le correctif n'est pas sorti officiellement. Il est prévu le 30 juin pour la sortie trimestrielle.
Notre serveur hôte ayant planté 3 fois en 2 mois, entrainant dans sa chute ses 9 machines virtuelles, il était presque certain qu'il se bloquerai encore une fois avant la mise à disposition du patch.
Nous avons donc décidé d'appliquer la pré-version du correctif sur un serveur de test identique. Si l'évolution de la zone M_TEMP s'est assagit, le correctif sera appliqué aux serveurs concernés.
Liens utiles :
Memory Usage (What is using all of the memory?)
Mais cela n'a pas été le cas.
Symptomes : le serveur répond au ping mais pas les VM. Impossible de se connecter. Aucune réponse, aucune banière de login, même via la console.
Solution : TOC (Transfer Of Control) lancé depuis le MP (commande TC dans le menu CM)
Analyse : après le redémarrage du serveur, le crash dump est enregistré dans le répertoire /var/adm/crash (cf. savecrash, crashconf). En lançant crashinfo (disponible dans les HATOOLS) depuis le répertoire du dernier dump ayant eu lieu, on distingue plusieurs informations interessantes :
...
Note: Crash event 0 was a INIT !
=> Le crash a bien été généré par notre TOC.
...
Physical Memory = 16759774 pages (63.93 GB)
Free Memory = 29617 pages (115.69 MB)
Average Free Memory = 29554 pages (115.45 MB)
gpgslim = 62464 pages (244.00 MB)
lotsfree = 253952 pages (992.00 MB)
desfree = 62464 pages (244.00 MB)
minfree = 30976 pages (121.00 MB)
Note: Free memory is desperately low (freemem <>
...
=> Il y a un manque criant de mémoire libre.
Top 10 kernel memory arenas
===========================
Arena Pages
----- -----
M_TEMP 809934 (3.09 GB)
VFD_BT_NODE 107151 (418.56 MB)
...
Tiens !? Qu'est ce que cette "arena" M_TEMP de 3 Go fait ici ?
Regardons de plus près avec "kmeminfo"
Physical memory = 16759774 63.9g 100%
Free memory = 29617 115.7m 0%
User processes = 14150001 54.0g 84% details with -user
System = 2538237 9.7g 15%
Kernel = 2370640 9.0g 14% kernel text and data
Dynamic Arenas = 1231596 4.7g 7% details with -arena
M_TEMP = 809934 3.1g 5%
VFD_BT_NODE = 107151 418.6m 1%
vm_pfn2v_arena = 65720 256.7m 0%
vx_global_kmcac = 56049 218.9m 0%
spinlock = 47548 185.7m 0%
Other arenas = 145194 567.2m 1% details with -arena
Super page pool = 2223 8.7m 0% details with -kas
Static Tables = 597275 2.3g 4% details with -static
pfdat = 392819 1.5g 2%
vhpt = 131072 512.0m 1%
bufhash = 32768 128.0m 0% bufcache hash headers
nbuf = 14512 56.7m 0% bufcache headers
bufmap = 8183 32.0m 0% bufmap->bm_bitmap
Other tables = 17920 70.0m 0% details with -static
Buffer cache = 167597 654.7m 1% details with -bufcache
Encore un peu plus près : kmeminfo -arena M_TEMP
Variable arena "M_TEMP" owns 809934 pages (3.1gb):
kmem_arena_t 0xe00000015c00c780
Attributes: KMT_DEFAULT KT_DEFAULT KAS_ALIVE
Per index summary (all cpu's):
idx objsz pages bytes % nobjs used free %
0 24 804043 3.1g 99 101309418 101308889 529 0
1 56 8 32.0k 0 504 92 412 82
804043 pages mémoires utilisées !
Après investigation avec le support HP, nous avons trouvé qu'il s'agit d'un bug connu depuis peu. Le correctif n'est pas sorti officiellement. Il est prévu le 30 juin pour la sortie trimestrielle.
Notre serveur hôte ayant planté 3 fois en 2 mois, entrainant dans sa chute ses 9 machines virtuelles, il était presque certain qu'il se bloquerai encore une fois avant la mise à disposition du patch.
Nous avons donc décidé d'appliquer la pré-version du correctif sur un serveur de test identique. Si l'évolution de la zone M_TEMP s'est assagit, le correctif sera appliqué aux serveurs concernés.
Liens utiles :
Memory Usage (What is using all of the memory?)
Inscription à :
Articles (Atom)