Ajuste del rendimiento de Oracle en la solución Bare Metal
Objetivo
En este documento, se proporcionan lineamientos sobre cómo abordar los problemas relacionados con el rendimiento mediante Oracle en la solución Bare Metal.
Paso 1: Recopila datos de diagnóstico
Comprende el problema con tanto detalle como sea posible. Recopila la mayor cantidad de información posible, incluido lo siguiente:
- Información del entorno de base de datos: ID o IP de la máquina, ubicación del centro de datos, detalles del entorno de Oracle, etcétera.
- Descripción del problema, incluido el cronograma
- Extensión del impacto: Por ejemplo, ¿el problema afecta solo a una sesión o servidor, o a un conjunto de sesiones y servidores relacionados, o a todos los usuarios de la base de datos?
- Describe la investigación realizada hasta ahora. ¿Hay alguna solución alternativa?
- ¿El problema se puede reproducir a voluntad? Si es así, ¿de qué manera?
- ¿Hay algún buen dato de referencia para comparar?
- ¿Se produjo algún cambio reciente en la configuración de las capas de la base de datos, el host, la red, el almacenamiento o la aplicación, incluido algún cambio en la carga de trabajo?
- Recopila todos los registros y seguimientos relevantes, incluidos ASH, AWR, registros de alerta, archivos de registros y registros del agente de observación de 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
Paso 2: Analiza y compila recomendaciones
No dudes en omitir secciones aquí según los datos que recopilaste antes.
2.1 Estado del host de la base de datos
Realizar una verificación de estado rápida en el host de la base de datos es un buen comienzo. Deberías poder usar archivos TFA/OSWatcher por el período del problema. Aquí debes buscar signos de uso, errores y saturación de recursos. También puedes usar BMS Infrascope para comprender tu entorno en un nivel alto con el ID de máquina, lun-id, etcétera.
2.2.1 Registros del sistema
Puedes usar
/var/log/messagesodmesgpara identificar posibles problemas en el almacenamiento y la capa de red como los ve el sistema.# System messages cat /var/log/messages Or dmesg -T
2.2.2 CPU
“uptime”/“top” se puede usar para ver los promedios de carga del sistema en los últimos 1/5/15 minutos. Ten en cuenta la cantidad de núcleos de CPU cuando observes estos números. En Linux, estos números incluyen la cantidad de procedimientos en cpu/espera de cpu, así como los que están en suspensión ininterrumpible (por lo general, E/S de disco). A continuación, se presentan algunos comandos útiles.
# 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 Memoria
Usa "free" para encontrar memoria libre "disponible"; un sistema en buen estado debe tener suficiente espacio.
# 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” se puede usar para ver las estadísticas de intercambio (si, so). Deberías ver cero en un sistema en buen estado. También proporciona otras columnas interesantes para procs/memory/cpu, etc., que pueden ser de interés según el problema.
# 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 0Considera habilitar hugepages si aún no lo están para aprovechar el tamaño mayor de la página y el bloqueo de sga en la memoria del sistema.
- Confirma el uso de hugepages en la sección init.ora del informe de awr (use_large_pages configurado en solo) o en la sección de inicio de la instancia en alert.log.
- No usar hugepages también puede ser la causa del intercambio del sistema y un uso de memoria más alto por conexión a la base de datos.
2.2.4 Almacenamiento
Se puede usar “iostat” para ver las estadísticas del dispositivo de almacenamiento en bloques, como await, avgqu-sz o %util, que puede indicar saturación del almacenamiento, rendimiento bajo, “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.92Algunos de buenos puntos de partida, si ves saturación en IO, son los siguientes:
- El QOS para la cantidad de IOPS (bloques 8K) para volúmenes SSD es de 6,000 por terabyte. Google no proporciona QOS para HDD. Establece las expectativas correctas con estos números.
- Si no ves la QOS esperada, el paso siguiente es asegurarte de cumplir con las prácticas recomendadas respecto de la configuración de almacenamiento.
Cada servidor de BMS tiene 4 NIC, 25 Gbps cada uno, vinculados a dos NIC de 50 Gb mediante el agregado dinámico de vínculos 802.3ad (activo-activo).
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/sEsto significa que (50,000 Mb/s = 6250 MB/s = 6,400,000 KB/s) es el punto de saturación para la interfaz de red principal.
# 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
Usa herramientas comunes como ping, traceroute, tnsping, entre otras, para buscar posibles problemas de red, como pérdida de paquetes/latencia entre máquinas de usuario/app y servidor de base de datos. Consulta este instructivo para obtener más información.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>Analizar las estadísticas de interconexión en el informe de AWS y compararlas con un buen modelo de referencia, así como usar el comando “netstat -s” (contadores de estadísticas de IP) para encontrar fallas de fragmentación o reensamblaje, problemas de desbordamiento de búfer, etc, puede darnos pistas sobre el estado de la red privada.
# 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 Estado de la base de datos
Ahora que conoces el estado general del sistema y realizaste observaciones útiles, puedes analizar la capa de la base de datos. Según la naturaleza del problema, asegúrate de recopilar todos los informes relevantes (awr, ash, etc.) y los archivos de registro (tfa, registros de alerta, archivos de seguimiento, etc.) que puedan ayudar a diagnosticar el problema.
Las siguientes son algunas de las áreas clave que debes observar en el informe awr:
Parte superior del informe
- El resumen del entorno te brinda información sobre el software de Oracle, información del host, como núcleos, memoria, tiempo transcurrido o tiempo de base de datos, etcétera.
- El perfil de carga nos brinda información sobre el tiempo de la base de datos en comparación con la CPU de la base de datos, estadísticas de análisis, estadísticas de e/s, etcétera.
- Tiempo de base de datos = CPU de la base de datos + tiempo en espera + espera de cpu (cola de ejecución)
- CPU de DB = Tiempo de ejecución en la CPU (cola de ejecución no incluida)
- Sesión activa promedio = tiempo de base de datos / tiempo transcurrido
- cpu de base de datos por segundo / (num_cpus * segundos transcurridos) proporciona información sobre la saturación de la CPU por db
Init.ora
- Busca cualquier parámetro (guion bajo, relacionado con la protección de los datos, etc.) que pueda ser un activador aquí.
Principales eventos temporizados en primer plano
- Investiga la distribución de tiempo de la base de datos para identificar el mayor potencial de mejora
- Busca las esperas principales que aparecen en la sección y sus características de rendimiento, como DBTime%, clase de espera, tiempo promedio, etcétera
- Según los eventos que encontremos en esta sección, podemos desglosar aún más las secciones del informe de awr.
Estadísticas del modelo de tiempo
- Algunas de las estadísticas importantes que debes observar en esta sección son las relacionadas con el análisis, el tiempo de CPU en segundo plano, el tiempo transcurrido de ejecución de SQL, la CPU de base de datos.
- Por lo general, se desean un tiempo de procesamiento de SQL alto y tiempos de análisis bajos. Un tiempo de ejecución de sql mucho más alto que la CPU de la base de datos puede indicar que el tiempo de espera de E/S es alto.
Eventos comunes de espera de Oracle relacionados con problemas de infraestructura
Sincronización del archivo de registro:
- La sincronización del archivo de registro puede deberse a problemas de infraestructura subyacentes o al diseño de la aplicación. A continuación, se presentan algunos lineamientos que se pueden usar para determinar si la infraestructura degradada contribuye a este evento de espera.
- La sincronización del archivo de registro puede deberse al rendimiento deficiente del almacenamiento local, así como al almacenamiento o la red remotos, si hay protección de datos.
- El rendimiento de la escritura en paralelo en los archivos de registro es un buen indicador de que existen latencias en el almacenamiento local y que afectan directamente el rendimiento de la sincronización de archivos de registro. Puedes ver los histogramas de eventos de espera y compararlos con buenos modelos de referencia para descubrir variaciones recientes. Una escritura en el disco óptima típica sería más cercana a 10 ms.
- Tener una configuración de protección de datos de disponibilidad/protección máxima podría contribuir aquí. Puedes ver las esperas relacionadas con la protección de datos, y sus histogramas podrían ayudar a indicar latencias de red o problemas de E/S en el sitio en espera.
- Otra causa es un lgwr ocupado debido a confirmaciones excesivas o escasez de CPU. Se debe verificar la estadística “tiempo de CPU en segundo plano” para asegurarte de que no sea una gran parte del tiempo de base de datos.
- La sincronización del archivo de registro puede deberse a problemas de infraestructura subyacentes o al diseño de la aplicación. A continuación, se presentan algunos lineamientos que se pueden usar para determinar si la infraestructura degradada contribuye a este evento de espera.
Esperas relacionados con Cloud Storage:
- Además de recomendar el ajuste de aplicaciones de chat o problemas de hotspots, debes verificar y eliminar la posibilidad de cuellos de botella de rendimiento de interconexión.
- Los BLOQUES GLOBALES DE CACHÉ PERDIDOS O DAÑADOS deben estar lo más cerca posible de cero.
- PERDIDOS: Pérdidas de bloques durante las transferencias. Puede indicar problemas de red
- DAÑADOS: Los valores altos indican un problema de IPC, red o hardware.