Direct IO y la p......

El escenario era el siguiente :
Teniamos un dominio del 10.000, conectado directamente a 2 storage externos un EMC y un SHARK, el s.o era solaris 7, con oracle 9.2.01
Migramos dicho servidor a un 4900, con solaris 10 , veritas 4.0 y oracle 10, conectado a el mismo storage pero a travez de una SAN ( switch brocade 24K ), con placa qlogic 2340.
 El problema era el siguiente :

Luego de migrar, la gente de base de datos decia que :
Las aplicaciones que hacen acceso random a los datafiles de oracle, tienen mucha mas demora que en la maquina anterior.
Las operaciones que realizan un acceso secuencial sobre los datafiles, funcionan mucho mejor. ( fullscan).            

Teniamos hasta el momento,segun estos datos, 2 lugares hacia donde apuntar, los discos de la SAN o quizas los parametros de la placa qlogic.

Por ejemplo, uno de los parametros a modificar en el /kernel/drv/qlc.conf , podria llegar a ser el hba1-execution-throttle=256 ( donde el actual es 1 )   
LUEGO, tocamos los siguientes parametros en el /etc/system :

El dba, me dijo que bajaron los tiempos con este parametro
* Tamanio fisico maximo de un I/O con VM                 
* Unidad=sector (de 512 bytes)                       

   
set vxio:vol_maxio=32768                                 

Tocamos parametros de Veritas de io

Luego de esto ultimo, El DBA me dijo que ya estaba solucionado el problema y que el resto seria un bug de Oracle, por lo cual pedi cerrar el caso en sun.

A los 2 o 3 dias, seguimos con los mismos problemas.

El escenario sigue siendo el mismo que detalle al comienzo .
El tema es que el error los da en forma aleatoria. ya sea en forma secuencial o random.

Lo que probe hacer fue bajar desde veritas con el vxtunefs bajar el parametro  discover_direct_ioz a 64 k, segun me guie en el siguiente blue print
http://www.sun.com/blueprints/0400/ram-vxfs.pdf             

                                                                                      

Pero se sigue dando el error en forma aleatoria y mas seguido cuando se trabaja con lectura random.

Abreviando muchismo, aca fue donde afinamos la punteria :
1) Generamos 2 filesystems para probar, ellos son /interfaz y /carga.
al filesystem /carga le sacamos el parametro directio de las opciones del mount.
y al filesystem /interfaz, le dejamos la opcion directio en el vfstab, que es como esta en el ambiente productivo.
/dev/vx/dsk/SOS/vol01 /dev/vx/rdsk/SOS/vol01 /carga vxfs 3 yes largefiles                                        
/dev/vx/dsk/SOS/vol02 /dev/vx/rdsk/SOS/vol02 /interfaz vxfs 3 yes largefiles,convosync=direct                    
Realizamos las siguientes pruebas.                                                                               
 En el fs /carga, ejecutamos un vxbench con opciones , write, read, random write,                                
 random read sin direct i/o y un vxbench con las mismas opciones pero con directio.                              

 A continuacion muestro la salida de los vxbench que hicimos en el fs /carga, Observemos los tiempos de
 la primer columna , como se pegan un viaje cuando los tiras con directio.      

Write SIN Directio
 /carga/PRUEBA # /usr/sbin/vxbench -w write -i iosize=16,iocount=10000,nrep=

10 test1
 total: 5.088 sec 314448.66 KB/s cpu: 4.84 sys 0.21 user                           
Read SIN Directio                                                                  
 /carga/PRUEBA # /usr/sbin/vxbench -w read -i iosize=16,iocount=10000,nrep=10 test1
 total: 2.830 sec 565335.87 KB/s cpu: 2.65 sys 0.17 user                           
Write CON Directio                                                                 
 /carga/PRUEBA #/usr/sbin/vxbench -w write -i iosize=16,iocount=10000,nrep=10 -c direct test2
 total: 101.390 sec 15780.62 KB/s cpu: 12.01 sys 0.47 user                                  
READ CON Directio
 /carga/PRUEBA # /usr/sbin/vxbench -w read -i iosize=16,iocount=10000,nrep=10 -c direct test2
 total: 88.032 sec 18175.25 KB/s cpu: 10.05 sys 0.45 user
Randon Write SIN Directio
 /carga/PRUEBA # /usr/sbin/vxbench -w rand_write -i iosize=16,iocount=10000,nrep=10 test3
 total: 19.299 sec 82906.56 KB/s cpu: 18.09 sys 0.43 user
Randon READ SIN Directio
/carga/PRUEBA # /usr/sbin/vxbench -w rand_read -i iosize=16,iocount=10000,nrep=10 test3
 total: 6.507 sec 245873.36 KB/s cpu: 6.17 sys 0.32 user
Random Write CON Directio
/carga/PRUEBA # /usr/sbin/vxbench -w rand_write -i iosize=16,iocount=10000,nrep=10 -c directio
 total: 362.794 sec 4410.21 KB/s cpu: 53.67 sys 0.77 user
Random READ CON Directio
/carga/PRUEBA # /usr/sbin/vxbench -w rand_read -i iosize=16,iocount=10000,nrep=10 -c directio
 total: 663.139 sec 2412.77 KB/s cpu: 12.64 sys 0.56 user
/carga/PRUEBA #


Hicimos las mismas pruebas sobre el filesystem /interfaz, es decir el que esta montado con directio
y la conclusion fue ....................:
En el /etc/vfstab, sacamos la opcion convosync=direct de los filesystems de la Base de Datos y anduvo Perfecto.

 

       

 

                       

                

I/O Error Sobre Storage Externo

Me llamaron diciendo que les daba IO error algunos filesystems, el error que mostraba el /var/adm/messages era este :
Aug 17 16:29:17 coneja fctl: [ID 517869 kern.warning] WARNING: 942=>fp(3)::GPN_ID for D_ID=64a200 failed
Aug 17 16:29:17 coneja fctl: [ID 517869 kern.warning] WARNING: 943=>fp(3)::N_x Port with D_ID=64a200, PWWN=5005076801403680 disappeared from fabric
Aug 17 16:29:17 coneja fctl: [ID 517869 kern.warning] WARNING: 952=>fp(3)::GPN_ID for D_ID=64e200 failed
Aug 17 16:29:17 coneja fctl: [ID 517869 kern.warning] WARNING: 953=>fp(3)::N_x Port with D_ID=64e200, PWWN=5005076801303680 disappeared from fabric
Aug 17 16:29:18 coneja fctl: [ID 517869 kern.warning] WARNING: 964=>fp(1)::GPN_ID for D_ID=64a900 failed
Aug 17 16:29:18 coneja fctl: [ID 517869 kern.warning] WARNING: 965=>fp(1)::N_x Port with D_ID=64a900, PWWN=5005076801103680 disappeared from fabric
Aug 17 16:29:18 coneja fctl: [ID 517869 kern.warning] WARNING: 974=>fp(1)::GPN_ID for D_ID=64e900 failed
Aug 17 16:29:18 coneja fctl: [ID 517869 kern.warning] WARNING: 975=>fp(1)::N_x Port with D_ID=64e900, PWWN=5005076801203680 disappeared from fabric
Aug 17 17:03:28 coneja mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g60050768019901b4000000000000002a (ssd107) multipath status: optimal, path /pci@8,600000/SUN
W,qlc@2/fp@0,0 (fp3) to target address: 5005076801403680,0 is offline. Load balancing: round-robin
Aug 17 17:03:28 coneja scsi: [ID 243001 kern.info]    Target 0x64e200: Device type=0x1f Nonzero pqual=0x1

El storage externo , tuvo problemas y los fs quedaron con IO error
chequeo el metastat |grep -i Errored
los filesystems quedan doblados, lo que hay que hacer es un umount del filesystem y montarlo, sino chilla, lo dejo asi.
Si putea por io error le corro un fsck  y luego lo monto.

[coneja] /var/adm # umount /u18
[coneja] /var/adm # mount /u18
mount: I/O error
mount: cannot mount /dev/md/dsk/d58
[coneja] /var/adm # fsck /dev/md/dsk/d58
** /dev/md/rdsk/d58
** Last Mounted on /u18
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder Groups

CORRECT BAD CG SUMMARIES FOR CG 0? y

CORRECTED SUPERBLOCK SUMMARIES FOR CG 0
CORRECTED SUMMARIES FOR CG 0
FRAG BITMAP WRONG
FIX? y

CORRECT GLOBAL SUMMARY
SALVAGE? y

Log was discarded, updating cyl groups
10 files, 12582971 used, 5358831 free (7 frags, 669853 blocks, 0.0% fragmentation)

***** FILE SYSTEM WAS MODIFIED *****
[coneja] /var/adm #

Algunos filesystems que NO tiraron IO error pero daban Errored en el status del metastat, no hizo falta correrles el fsck, solo umount y mount
[coneja] /var/adm # umount /u01
umount: /u01 busy
[coneja] /var/adm # metastat d41
d41: Soft Partition
    Device: d40
    State: Errored
    Size: 41943040 blocks (20 GB)
        Extent              Start Block              Block count
             0                     2080                 41943040

coneja] /var/adm # umount -f /u01
[coneja] /var/adm # mount  /u01
[coneja] /var/adm # metastat d41
d41: Soft Partition
    Device: d40
    State: Okay
    Size: 41943040 blocks (20 GB)
        Extent              Start Block              Block count
             0                     2080                 41943040

Device Relocation Information:
Device                                  Reloc   Device ID
c6t60050768019901B4000000000000002Ad0   Yes     id1,ssd@w60050768019901b4000000000000002a
c6t60050768019901B4000000000000002Bd0   Yes     id1,ssd@w60050768019901b4000000000000002b
c6t60050768019901B4000000000000002Cd0   Yes     id1,ssd@w60050768019901b4000000000000002c
[coneja] /var/adm #

Por lo que estuve viendo en sunsolve, hay un parche mas nuevo para la SAN, que es el 113039-25 (requiere REBOOT) quizas solucione esto.