Cette page a été traduite par l'API Cloud Translation.

Régler les performances d'Oracle sur solution Bare Metal

Objectif

Ce document explique comment aborder les problèmes liés aux performances avec Oracle sur solution Bare Metal.

Étape 1 : Rassembler des données de diagnostic

Essayez de comprendre le problème aussi bien que possible. Recueillez un maximum d'informations, y compris les suivantes :

Informations sur l'environnement de base de données : ID/IP de la machine, emplacement du centre de données, détails de l'environnement Oracle, etc…
Description du problème et chronologie.
Étendue de l'impact : par exemple, le problème affecte-t-il une seule session ou un seul serveur, un ensemble de sessions et de serveurs associés ou tous les utilisateurs de la base de données ?
Décrivez les étapes d'investigation réalisées jusqu'à présent. Des solutions de contournement sont-elles en place ?
Indiquez si l'erreur peut être reproduite à la demande. Si c'est le cas, comment ?
Existe-t-il des données de référence de bonne qualité pour la comparaison ?
Des modifications ont-elles récemment été apportées aux configurations au niveau de la base de données, de l'hôte, du réseau, de l'espace de stockage ou de l'application, y compris des modifications apportées à la charge de travail ?
Rassemblez tous les journaux et traces pertinents, y compris les rapports ASH, les rapports AWR, les journaux d'alerte, les fichiers de trace et les journaux de suivi et de surveillance TFA/OS.

# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.

tfactl diagcollect -srdc dbperf

Étape 2 : Analyser et créer des recommandations

N'hésitez pas à passer certaines sections en fonction des données que vous avez recueillies ci-dessus.

2.1 État de l'hôte de base de données

Une vérification d'état rapide sur l'hôte de base de données est un bon point de départ. Vous devriez pouvoir utiliser les fichiers TFA/OSWatcher correspondant à la période concernée. Il s'agit ici de rechercher des signes de saturation, d'utilisation et/ou d'erreur des ressources. Vous pouvez également utiliser BMS Infrascope pour mieux comprendre votre environnement à un niveau général grâce à l'ID machine, au lun-id, etc…

2.2.1 Journaux système

/var/log/messages ou dmesg peuvent être utilisés pour identifier les problèmes potentiels au niveau du stockage, qui correspond à la couche réseau du point de vue du système.
```
# System messages

cat /var/log/messages
Or
dmesg -T
```

2.2.2 Processeur

"uptime/top" peut être utilisé pour afficher les moyennes de charge système au cours des 1/5/15 dernières minutes. Prenez en compte le nombre de cœurs de processeur lorsque vous consultez ces chiffres. Sous Linux, ces chiffres incluent le nombre de processus en cours d'exécution sur le processeur ou en attente de processeur ainsi que le nombre de processus en veille ininterrompue (généralement des E/S de disque). Vous trouverez ci-dessous quelques commandes utiles.

# To find load average

"w"
Or
"uptime"
Or
"top"

[root@svr001 ~]# uptime
 21:32:09 up 12 days,  1:04,  3 users,  load average: 0.31, 0.44, 0.64

# To find CPU Usage over time

"sar -u 5"

[root@svr001 ~]# sar -u 5
Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001)      12/16/2020           _x86_64_        (16 CPU)
09:52:20 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:52:25 PM     all      0.63      0.00      0.73      0.11      0.00     98.52
09:52:30 PM     all      1.10      0.00      0.82      0.15      0.00     97.93

# To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states

"ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"

2.2.3 Mémoire

Utilisez "free" (libre) pour trouver la quantité de mémoire "available" (disponible). Un système sain doit disposer de suffisamment d'espace libre.

# Find system memory usage

"free -m"

[root@svr001 ~]# free -m
              total       used       free        shared      buff/cache  available
Mem:         385423       16603      188217      153744      180602      211778
Swap:         16383           0       16383

"vmstat" peut être utilisé pour afficher les statistiques d'échange (si,so). La valeur doit être de zéro pour un système opérationnel. Il fournit également d'autres colonnes intéressantes "procs/memory/cpu (processus/mémoire/processeur) qui peuvent s'avérer utiles en fonction du problème.

# Virtual Mem stats 5 snapshots 5 secs apart

"vmstat 5 5"

[root@svr001 ~]# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache         si   so    bi    bo   in   cs   us sy id wa st
1  0      0 192717472 497132 184439376    0    0    82    35    2    0    1  1 98  0  0
1  0      0 192717520 497132 184439616    0    0  3225   719 15118 29594  1  1 98  0  0

Si ce n'est pas déjà fait, pensez à activer les "hugepages" afin de profiter de tailles de pages plus élevées et du verrouillage de la SGA dans la mémoire système.
- Confirmez l'utilisation des "hugepages" dans la section "init.ora" du rapport AWR (définissez "use_large_pages" sur "only") ou dans la section de démarrage d'instance dans "alert.log".
- Ne pas utiliser les "hugepages" peut entraîner des échanges système et une utilisation de mémoire plus élevée pour chaque connexion à la base de données.

2.2.4 Stockage

"iostat" permet d'afficher les statistiques des appareils de stockage en mode bloc telles que "await", "avgqu-sz" ou "%util", qui peuvent indiquer la saturation du stockage, les performances inférieures, etc…

# IO Stats with extended per-disk statistics

"iostat -x 5 5"
Or
"sar -dp"

# For devices with 90% utilization and above

"sar -dp | awk '/%util/ || ($11 > 90)'"

[root@svr001 ~]# iostat -x 5 5
Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001)      12/16/2020      _x86_64_        (16 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       1.05    0.01    0.77    0.09    0.00   98.08
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sde               0.00     0.00    0.17    0.83     7.10    20.12    54.46     0.04   41.10   18.91   45.57   1.12   0.11
sdf               0.00     0.00    0.00    0.00     0.00     0.00    43.50     0.00    1.03    1.03    0.00   0.75   0.00
sdc               0.00     0.00    0.00    0.00     0.00     0.00    40.15     0.00    0.40    0.40    0.00   0.22   0.00
sda               0.00     0.00    1.16   20.80     7.76   177.15    16.84     0.02    0.82    0.73    0.83   0.14   0.31
sdd               0.00     0.00   43.24    8.03   639.16    97.67    28.75     0.01    0.20    0.18    0.31   0.18   0.92

Si vous constatez une saturation d'E/S, voici les premiers points à prendre en compte :

Le QOS pour le nombre d'IOPS (8000 blocs) pour les volumes SSD est de 6000 par téraoctet. Google ne propose pas de QOS pour les disques durs standard. Définissez des attentes correctes en utilisant ces chiffres.
Si vous ne parvenez pas à atteindre la QOS ci-dessus, l'étape suivante peut consister à vérifier que vous respectez bien les bonnes pratiques en matière de configuration de stockage.

Chaque serveur BMS dispose de quatre cartes d'interface réseau de 25 Gbit/s chacune qui sont liées à deux cartes d'interface réseau de 50 Gbit/s par l'intermédiaire d'une agrégation dynamique de liens 802.3ad (active-active).

# Interface Transfer Speed
# bond0 is the primary interface in this case.

[root@svr001 ~]# ethtool bond0 | grep -i speed
Speed: 50000Mb/s

Cela signifie donc que (50 000 Mbit/s = 6250 Mo/s = 6 400 000 Ko/s) est le point de saturation de l'interface réseau principale.

# Interface stats

"sar -n DEV | head -3 && sar -n DEV | grep bond0"

[root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0
12:00:01 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
12:10:01 AM bond0.118     87.30     49.94     69.45     24.93      0.00      0.00      0.00
12:10:01 AM     bond0     89.31     52.26     71.58     25.59      0.00      0.00      2.00
12:20:01 AM bond0.118     21.91     13.21     18.92      8.02      0.00      0.00      0.00
12:20:01 AM     bond0     23.94     15.55     19.65      8.39      0.00      0.00      2.00

Utilisez des outils courants tels que ping, traceroute, tnsping et autres pour détecter d'éventuels problèmes réseau comme des pertes de paquets ou une latence entre les machines utilisateur ou d'application et le serveur de base de données. Pour en savoir plus, consultez ce tutoriel.
```
# Quick check for 9000 mtu.
# If not configured correctly, we will see "Message too long" errors

ping -c 5 -s 8972 -M do <IP>
```

L'analyse des statistiques d'interconnexion dans le rapport AWR suivie de la comparaison avec une bonne référence et de l'utilisation de la commande "netstat -s" (compteurs de statistiques IP) pour détecter les échecs de fragmentation/réassemblage et les problèmes de dépassement de mémoire tampon ou autres peuvent nous donner des indices sur l'état du réseau privé.


# Interface errors:

[root@svr001 ~]netstat -s |
egrep       "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive"

Ip:
168848352 total packets received
0 incoming packets discarded
701 outgoing packets dropped
3265322 fragments received ok

2.3 État de la base de données

Maintenant que vous connaissez l'état général du système et que vous avez effectué des observations utiles, vous pouvez examiner plus en détail la couche de base de données. Selon la nature du problème, veillez à collecter tous les rapports pertinents (AWR, ASH, et autres) et les fichiers journaux (TFA, journaux d'alerte, fichiers de suivi et autres) qui pourraient vous aider à diagnostiquer le problème.

Voici quelques-uns des domaines clés à examiner dans ce rapport :

Haut du rapport
- Le résumé de l'environnement vous donne des informations concernant la version logicielle d'Oracle et des informations concernant l'hôte (cœurs, mémoire, rapport de temps DB contre temps écoulé, etc.).
- Le profil de chargement nous fournit des informations sur le rapport de temps DB contre processeur DB, les statistiques d'analyse, les statistiques d'E/S, etc.
- Temps DB = processeur DB + temps d'attente + attente de processeur (file d'attente d'exécution).
- Processeur DB = temps d'exécution sur le processeur (file d'attente d'exécution non incluse).
- Session active moyenne = temps DB / temps écoulé.
- Processeur DB par seconde / (nombre_de_processeurs * secondes écoulées) fournit des informations sur la saturation du processeur par la base de données.
Init.ora
- Recherchez tous les paramètres (traits de soulignement, paramètres de protection des données, etc.) qui pourraient ici jouer le rôle de déclencheur.
Principaux événements programmés de premier plan
- Examinez la répartition du temps DB afin d'identifier le potentiel d'amélioration le plus élevé.
- Recherchez les temps d'attente les plus longs qui apparaissent dans la section et consultez leurs caractéristiques de performance associées telles que "DBTime%" (% de temps DB), "wait class" (classe d'attente), "avg. time" (durée moyenne), etc.
- Selon les événements que vous trouvez dans cette section, vous pouvez afficher une vue détaillée d'autres sections du rapport.
Statistiques des modèles de temps
- Certaines des statistiques importantes à examiner dans cette section sont les statistiques d'analyse, le temps CPU en arrière-plan, le temps d'exécution SQL et le processeur DB.
- En règle générale, un temps de traitement SQL élevé et des temps d'analyse faibles sont souhaités. Un temps d'exécution SQL beaucoup plus élevé que le processeur DB peut indiquer des temps d'attente d'E/S élevés.

Événements d'attente Oracle courants liés aux problèmes d'infrastructure

Synchronisation des fichiers de journaux :
- la synchronisation des fichiers journaux peut être due à des problèmes d'infrastructure sous-jacents ou à la conception de l'application. Vous trouverez ci-dessous quelques directives à utiliser pour déterminer si une infrastructure dégradée contribue à cet événement d'attente.
  - La synchronisation des fichiers journaux peut être causée par des performances médiocres du stockage local, ainsi que par le stockage à distance et/ou le réseau si une protection des données est impliquée.
  - Les performances d'écriture parallèle du fichier de journal constituent un bon indicateur de l'existence de latences dans le stockage local qui ont un impact direct sur les performances de synchronisation des fichiers journaux. Vous pouvez consulter les histogrammes des événements d'attente et les comparer à des de référence de bonne qualité pour détecter les variations récentes. Une écriture optimale type sur le disque est plus proche des 10 ms.
  - Une configuration à disponibilité maximale ou avec protection des données peut aussi être un contributeur ici. Vous pouvez examiner les temps d'attente liés à la protection des données et leurs histogrammes qui peuvent vous aider à détecter les latences du réseau et/ou les problèmes d'E/S sur le site de secours.
  - Une autre cause peut être un lgwr occupé en raison de commits excessifs ou d'un manque de ressources de processeur. La statistique "temps CPU en arrière-plan" doit être vérifiée pour vous assurer qu'il ne s'agit pas d'une grande partie du temps DB.
Attentes liées à Cloud Storage :
- En plus de paramétrer les applications bruyantes et de régler les problèmes de hotspotting, vous devez vérifier et éliminer toute possibilité de goulot d'étranglement affectant les performances.
- "GLOBAL CACHE BLOCKS LOST/CORRUPT" (nombre total de blocs de cache perdus/corrompus) doit être aussi proche de zéro que possible.
  - "LOST" (perdus) : pertes de blocs pendant les transferts. Peut indiquer des problèmes de réseau.
  - "CORRUPT" (corrompus) : des valeurs élevées indiquent un problème d'IPC, de réseau ou de matériel.

Liens utiles :

Dépannage réseau : Lien
Guide de réglage des performances d'Oracle : Lien