Para monitorear el espacio de un servidor linux, existen dos comandos muy útiles.
El primero es df(disk free), les recomiendo usarlo con la opción -h (human-readable) que automaticamente se ajusta al tamaño de cada filesystem mostrandolo en K, M, G o T.
[oracle@m9 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
137G 63G 68G 48% /
/dev/md0 99M 28M 67M 30% /boot
tmpfs 2.0G 545M 1.5G 28% /dev/shm
/dev/mapper/vgR0-lvR0
50G 39G 7.9G 84% /data0
/dev/mapper/vgR10-backups
119G 93G 21G 83% /backups
/dev/mapper/vgR0-oracle11g
99G 20G 75G 21% /u01
El segundo es du (disk usage), este nos muestra que directorios están utilizando el mayor espacio (recomendable usar -h). Por ejemplo para ver que esta consumiendo el mayor espacio en /u01 ejecutamos:
[oracle@m9 ~]$ du -h /u01 132K /u01/software/Disk1/stage/Actions/ntw32FoldersActions/10.2.0.3.0/1 136K /u01/software/Disk1/stage/Actions/ntw32FoldersActions/10.2.0.3.0 140K /u01/software/Disk1/stage/Actions/ntw32FoldersActions 24K /u01/software/Disk1/stage/Actions/ntCrsActionLib/10.2.0.1.0/1 28K /u01/software/Disk1/stage/Actions/ntCrsActionLib/10.2.0.1.0 32K /u01/software/Disk1/stage/Actions/ntCrsActionLib
Algunas variantes que podemos usar son: -s Para mostrar todo el espacio utilizado por este directorio y subdirectorios
[oracle@m9 db_1]$ du -sh /u01 20G /u01
Desplegar los 5 directorios que ocupan mayor espacio en /u01
[oracle@m9 u01]$ du -s /u01/* |sort -nr| head -5 16856112 /u01/app 3255624 /u01/software
En este caso solo contiene 2 directorios Monitoreando el I/O El comando iostat nos puede ayudar a determinar si tenemos un problema de I/O. La opción -x (extended) y -d (device) son muy útiles para generar el reporte. El siguiente ejemplo ejecuta el comando cada 10 segundos.
[oracle@m9 u01]$ iostat -xd 10 Linux 2.6.27.25-78.2.56.fc9.x86_64 (m9) 07/06/2010 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.22 7.90 0.52 4.87 25.47 106.80 24.57 0.04 6.80 2.55 1.37 sda1 0.00 0.00 0.00 0.00 0.00 0.00 8.71 0.00 11.35 10.77 0.00 sda2 0.10 0.22 0.04 0.05 1.17 2.27 36.37 0.00 8.69 5.74 0.05 sda3 0.11 7.68 0.48 4.81 24.30 104.53 24.36 0.04 6.77 2.51 1.33 sdb 0.22 7.93 0.52 4.84 25.82 106.80 24.75 0.03 6.19 2.93 1.57 dm-6 0.00 0.00 0.01 0.00 0.09 0.00 11.93 0.00 3.92 2.79 0.00 dm-7 0.00 0.00 0.01 0.00 0.07 0.00 8.00 0.00 2.16 1.80 0.00 dm-8 0.00 0.00 0.03 0.67 0.25 5.38 8.00 0.01 8.35 0.19 0.01
La forma de revisar este reporte es ver el %util que no este al 100% ya que esto indicaría un problema con el I/O. Si alguno de los discos que presenta alto consumo pertenece a oracle, entonces podemos ejecutar un query sobre la base de datos para determinar que session esta generando demasiadas escritura o lecturas.
SELECT * FROM (SELECT parsing_schema_name ,direct_writes ,SUBSTR(sql_text,1,75) ,disk_reads FROM v$sql ORDER BY disk_reads DESC) WHERE rownum < 20;
Este otro query es útil para determinar que objetos producen la mayoria de los I/O en la base de datos.
SELECT *
FROM
(SELECT
s.statistic_name
,s.owner
,s.object_type
,s.object_name
,s.value
FROM v$segment_statistics s
WHERE s.statistic_name IN
('physical reads', 'physical writes', 'logical reads',
'physical reads direct', 'physical writes direct')
ORDER BY s.value DESC)
WHERE rownum < 20;
Una nota importante cuando monitoreamos el I/O, es que si estamos sobre una SAN (discos virtuales) la salida de iostat es a nivel del disco virtual, no de los discos fisicamente, esto puede dificultar encontrar que disco esta generando el cuello de botella, en estos casos debemos de trabajar con el administrador de la SAN para determinar que LUN es el del problema. Un comando que nos puede ayudar a realizar una prueba sobre nuestro filesystem es tomar el tiempo en que tarda en generar algunos archivos grandes y compararlos con otro ambiente que tenga un arreglo similar o configuración similar.
[oracle@m9 orc11g]$ time dd if=example01.dbf of=borrame.dbf 204816+0 records in 204816+0 records out 104865792 bytes (105 MB) copied, 2.4027 s, 43.6 MB/s real 0m2.441s user 0m0.074s sys 0m2.050s
Ya hemos comentado el comando sar con anterioridad y bueno este mismo nos puede dar también información del I/O con la opción -d.
[oracle@m9 orc11g]$ sar -d -f /var/log/sa/sa01 08:40:01 AM DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util 08:50:01 AM dev8-0 3.95 2.80 79.00 20.68 0.02 4.30 2.73 1.08 08:50:01 AM dev8-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:50:01 AM dev8-2 0.01 0.17 0.00 17.33 0.00 19.33 14.00 0.01 08:50:01 AM dev8-3 3.94 2.63 79.00 20.69 0.02 4.26 2.71 1.07 08:50:01 AM dev8-16 3.93 4.16 79.00 21.15 0.02 4.68 3.14 1.24 08:50:01 AM dev8-17 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:50:01 AM dev8-18 0.01 0.15 0.00 22.00 0.00 9.50 7.75 0.01 08:50:01 AM dev8-19 3.92 4.01 79.00 21.15 0.02 4.67 3.13 1.23
Y para mostrar información actual cada 2 segundos para un total de 10 reportes.
[oracle@m9 orc11g]$ sar -d 2 10
Monitoreando el trafico Si llegamos a sospechar, que el problema de desempeño del servidor se debe a un problema en la red, podemos hacer uso del comando netstat con la opción - ptcn, el cuál despliega el ID del proceso, las conecciones TCP y se mantiene actualizando la salida.
[oracle@m9 orc11g]$ netstat -ptcn (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:42453 127.0.0.1:1522 ESTABLISHED 24028/java tcp 0 0 127.0.0.1:1522 127.0.0.1:59825 ESTABLISHED 30426/oracleorc11g tcp 0 0 192.168.1.4:19526 192.168.1.5:389 ESTABLISHED - tcp 0 0 127.0.0.1:59825 127.0.0.1:1522 ESTABLISHED 24028/java tcp 0 0 127.0.0.1:54088 127.0.0.1:1522 ESTABLISHED 24028/java tcp 0 0 192.168.1.4:36415 192.168.1.253:5053 ESTABLISHED - tcp 0 0 127.0.0.1:1522 127.0.0.1:37731 ESTABLISHED 3550/oracleorc11g tcp 0 0 127.0.0.1:1522 127.0.0.1:42490 ESTABLISHED 29529/oracleorc11g
Si tenemos valores muy altos en Send-Q (bytes not acknowledged by remote host), puede indicar que la red esta sobrecargada. Lo bueno de esta salida, es que nos indica el programa que lo esta generando. Generalmente cuando se tienen problemas de desempeño en un servidor de base de datos, la red no es el problema pero es importante revisarla y no dejarlo pasar.
Por último, podemos usar el comando sar para ver el historial de comportamiento de red con la opción -n y alguno de los siguientes argumentos: DEV (network devices), EDEV (error count), SOCK (sockets), o FULL (all).
[oracle@m9 orc11g]$ sar -n DEV Linux 2.6.27.25-78.2.56.fc9.x86_64 (m9.dbanet.dbaremoto.com.mx) 07/06/2010 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:10:01 AM lo 11.69 11.69 2.02 2.02 0.00 0.00 0.00 12:10:01 AM eth0 372.28 220.06 334.77 15.05 0.00 0.00 0.00 12:10:01 AM vboxnet0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:10:01 AM pan0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:20:01 AM lo 11.88 11.88 2.19 2.19 0.00 0.00 0.00