<<< DISK$DATA:[NOTES$LIBRARY]VAX_VMS.NOTE;1 >>> -< SIG VAX/VMS >- ================================================================================ Note 1376.0 moni rms/item=caching/summary 9 replies DECUSF::QUIVOGNE_L 21 lines 12-JUN-1991 11:56 -------------------------------------------------------------------------------- J'ai tente d'evaluer l'impact de global buffer sur certains fichiers de notre sites. Pour cela, j'ai lance pendant une demi-journee un : $ MONITOR RMS/ITEM=CACHING/SUMMARY/NODISPLAY/FILE=(...) Les valeurs que je trouve dans la ligne GLOBAL CACHE HIT PERCENT me semblent cependant etranges. Exemple, pour un petit fichier parametres (avec 2 buffers) j'obtiens sur l'un des deux noeuds du cluster : Average : 72.73 MAX : 100.00 Et sur l'autre noeud : Average : 17.27 MAX : 150.00 QUID de cette valeur de 150 % ? Et comment interpreter ces resultats ? Sur un autre fichier, j'ai meme : Average : 276.49 MAX : 100.00 Quelqu'un peut-il eclairer ma lanterne... ================================================================================ Note 1376.1 moni rms/item=caching/summary 1 of 9 DECUSF::FOUCHET_F "François FOUCHET" 1 line 12-JUN-1991 12:01 -< SMP ? >- -------------------------------------------------------------------------------- Les CPU incrimines ne seraient ils pas SMP ? ================================================================================ Note 1376.2 moni rms/item=caching/summary 2 of 9 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 10 lines 12-JUN-1991 13:58 -< This might (just) help >- -------------------------------------------------------------------------------- Since these figures don't have anything to do with CPU usage they *shouldn't* be affected by SMP... I have posted in PUB:[VMS]GBLHIT.BCK_Z a piece of code written by some Digital people on a project in the UK (it was given to me in good faith as being public domain by a Digital SWAS guy a few years ago, when SWAS was still SWAS) which lets you look at global buffer hits more closely. I only ever used it on VMS V4.7, but I relinked it just now and it doesn't seem to crash on V5.3-1 (it needs CMEXEC, so it should only threaten your process, not the system (subject to Murphy)). ================================================================================ Note 1376.3 moni rms/item=caching/summary 3 of 9 DECUSF::QUIVOGNE_L 5 lines 12-JUN-1991 14:22 -< suite... >- -------------------------------------------------------------------------------- A .1 : Heu... SMP ?? Nous avons un 6000-410 et un 8750... A .2 : Merci mais est-ce que justement les BUGCHECK FATAL en mode EXEC ne font pas crasher la machine. Nous travaillons en environnement boursier et j'aimerais vraiment pas planter le systeme... ================================================================================ Note 1376.4 moni rms/item=caching/summary 4 of 9 DECUSF::BROWN_N "Nick BROWN, Conseil de l'Europe" 5 lines 12-JUN-1991 15:56 -< Should be OK >- -------------------------------------------------------------------------------- A BUGCHECK in any mode will crash the machine (subject to SYSGEN parameters). What I think you mean is what an error in the program will do. By default, an error such as an access violation in EXEC mode will kill the process, NOT the system. I have tried GBLHIT on my system this afternoon and it seemed to work OK. Don't worry (!). ================================================================================ Note 1376.5 moni rms/item=caching/summary 5 of 9 DECUSF::QUIVOGNE_L 7 lines 12-JUN-1991 16:14 -< Thanks >- -------------------------------------------------------------------------------- OK... Ceci dit un bugcheck crashe le systeme (du moins je crois) en EXEC et bien sur en KERNEL, quelque soit la valeur du parametre SYSGEN (qui n'est donc significatif que pour les autres modes). Cordialement... ================================================================================ Note 1376.6 moni rms/item=caching/summary 6 of 9 DECUSF::GERARD_G "G. Gerard ENST centre de calcul" 9 lines 12-JUN-1991 16:53 -< c'est fatal ... >- -------------------------------------------------------------------------------- > Ceci dit un bugcheck crashe le systeme (du moins je crois) en EXEC > et bien sur en KERNEL, quelque soit la valeur du parametre SYSGEN (qui > n'est donc significatif que pour les autres modes). en mode KERNEL ou EXEC, il existe 2 types de bugcheck: les non-fatal et les fatal. Curieusement, les bugcheck mode kernel ont plus souvent tendance a etre fataux. hum. Ces derniers se traduisent par un crash. Le parameter BUGCHECKFATAL permet de transfer un non-fatal bugcheck en fatal bugcheck. voir vms v5.2 ... ================================================================================ Note 1376.7 moni rms/item=caching/summary 7 of 9 DECUSF::PANNETIER_AM "Alain PANNETIER - TIBET" 12 lines 12-JUN-1991 20:14 -< les mystères de SYSGEN >- -------------------------------------------------------------------------------- En 5.1 et 5.2, on pouvait faire une manip burlesque : $ MC SYSGEN SYSGEN> USE DEFAULT SYSGEN> SHOW BUGCHECKFATAL Parameter name Current Default -------------- -------- -------- BUGCHECKFATAL 1 0 ^^ ^^ Peut être cela vous concerne-t-il ? ================================================================================ Note 1376.8 moni rms/item=caching/summary 8 of 9 DECUSF::QUIVOGNE_L 8 lines 13-JUN-1991 09:15 -< ...continue... >- -------------------------------------------------------------------------------- A -1 : non, non !! Nous discutions juste de possibilites... Mais pour revenir a la question initiale et independamment de l'outil GBLHIT (quelle est la note qui parle des .BCK_Z ?), j'aimerais savoir si les resultats enregistres par MONITOR ont un sens et lequel (parce qu'une moyenne > au maximum...) Cordialement - LQ ================================================================================ Note 1376.9 moni rms/item=caching/summary 9 of 9 DECUSF::GUIRAUD_D "Daniel GUIRAUD - INFI" 2 lines 14-JUN-1991 10:45 -< goto 1363 >- -------------------------------------------------------------------------------- C'est la note 1363 qui parle des BCK_Z.