Si vous utilisez les « Server-Generated Alerts » avec RAC; vous avez sans doute déjà rencontré le message d’alerte qui suivant:
Metrics « Global Cache Blocks Lost » is at XX
Fort de mon Packet Loss Myths, j’avais plutôt tendance à laisser courir! Mais après réflexion, et une bonne séance de tuning, il apparait que ce n’est pas forcément si anodin… Dans certain cas, si vous faites des full scan de table ou d’index, vos requêtes peuvent passer un temps significatif de leur exécution sur l’événement gc cr multi block. Ce que j’observe sur ce RAC (10.2.0.4 sur Linux x86_64), c’est que cet événement amène à la perte de blocs sur le réseau interconnect.
Après analyse, et la lecture assidue des 2 notes ci-dessous, il semble que le problème soit liés à la configuration de /net/core/rmem_default qui s’il est positionné à 256K est un peu court pour un multi_block_read_count=16 et des blocs de 8K:
- 563566.1 – gc lost blocks diagnostics
- 341788.1 – Recommendation for the Real Application Cluster Interconnect and Jumbo Frames
Je dois encore réaliser quelques tests pour reproduire ce comportement et m’assurer que j’ai bien compris ce qu’il se passe lorsque une requête attend sur l’événement gc cr multi block, et pourquoi les blocs sont perdus dans ce cas particulier lorsque les buffers sont trop petits. Enfin il semble que pour mon problème, augmenter les paramétres à 1Mo réduit mes waits et élimine les « Lost Blocks ».
Et c’est là que commence la discussion! Si vous prêtez attention aux différentes notes/RDA qui définissent quelles devraient être les bonnes valeurs, surprise! Vérifiez par vous-même selon la source, la version, 32 ou 64 bits, vous trouvez une large éventail de valeurs entre 256K et 4M:
- Oracle® Database Quick Installation Guide 10g Release 2 (10.2) for Linux x86 6 Configuring Kernel Parameters
- Oracle® Database Installation Guide 10g Release 2 (10.2) for Linux x86 – 2.6 Configuring Kernel Parameters
- Oracle® Database Quick Installation Guide 11g Release 1 (11.1) for Linux x86 – 6 Configuring Kernel Parameters
- Oracle® Database Installation Guide – 11g Release 1 (11.1) for Linux – 2.8 Configuring Kernel Parameters
- 169706.1 – Oracle® Database on AIX®,HP-UX®,Linux®,Mac OS® X,Solaris®,Tru64 Unix® Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.1)
Il semblerait, si je lis entre les lignes qu’un consensus se dégage à 1M pour 10g et 4M pour 11g… Seulement voilà, si multi_block_read_count peut expliquer les 1M, pourquoi 4M avec 11g? Je sens qu’on ne me dit encore pas tout!
