Eduardo:<br><br>Em se tratando de tunning para banco de dados relacionais existem algumas ferramentas que podem ajudar a obter informações a fim de identificar possíveis gargalos ocasionados por tempo de acesso ao disco elevelado.
<br>O pacote sysstat possui o comando iostat que monitora a carga de entrada e saída de dispositivos de disco através da observação do tempo em que os devices estão ativos em relação a suas taxas de transferência médias.<br>
O comando iostat -p sda 2 6 por exemplo exibe na tela em intervalos de dois segundos um total de seis relatórios para o dispositivo /dev/sda e suas respectivas partições. Abaixo está a saída de um relatório do iostat para um servidor Red Hat Enterprise Linux rodando um banco de dados Oracle 10G de produção de um hospital (mais de 300 clientes).
<br><br>Linux 2.6.9-34.ELsmp (hostname suprimido) 25-06-2007<br><br>cpu-moy: %user %nice %sys %iowait %idle<br> 8,98 0,00 1,83 5,93 83,26<br><br>Device: tps Blk_lidos/s Blk_escr./s Blk_lidos Blk_escr.
<br>sda 1,03 1,49 24,42 3984787 65344393<br>sda1 1,44 0,18 11,42 492106 30555096<br>sda2 0,07 0,23 0,30 627684 790336
<br>sda3 1,64 1,07 12,70 2864149 33998961<br>sdb 19,40 56,94 116,35 152401356 311388287<br>sdb1 27,29 56,94 116,35 152400660 311388287
<br>sdc 8,37 189,88 298,79 508204506 799668994<br>sdc1 8,78 189,88 298,79 508203826 799668994<br>sdd 16,18 401,93 2,35 1075720826 6276858
<br>sdd1 16,32 401,93 2,35 1075720146 6276858<br>sde 40,77 844,01 429,95 2258883433 1150714228<br>sde1 68,22 844,01 429,95 2258882753 1150714228
<br>sdf 14,35 379,30 3,59 1015157914 9616696<br>sdf1 14,43 379,30 3,59 1015157234 9616696<br>sdg 3,74 125,90 2,98 336946298 7965248
<br>sdg1 3,89 125,90 2,98 336945594 7965248<br>sdh 26,69 627,60 68,19 1679699346 182498589<br>sdh1 26,88 627,60 68,19 1679698666 182498589
<br><br>Os percentuais de uso de cpu são para as operações de IO.<br><br>Este outro exemplo traz uma saída mais detalhada (favor corrigir a identação das colunas):<br><br>iostat -t -k -d -x sdb sdc sdd sde sdf sdg sdh 3<br>
Linux 2.6.9-34.ELsmp (hostname suprimido) 25-06-2007<br><br>Hora: 13:48:23<br>Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util<br>sdb 0,32 7,57 17,11 2,29 57,03 116,33 28,51 58,17 8,94 0,10 4,92 3,88 7,54
<br>sdc 0,05 0,37 3,04 5,33 189,85 298,77 94,92 149,39 58,39 0,05 5,94 5,11 4,27<br>sdd 0,02 0,13 16,09 0,10 402,05 2,35 201,03 1,17 24,98 0,03 1,67 1,52 2,46
<br>sde 0,23 27,22 39,69 1,08 843,89 429,84 421,94 214,92 31,25 0,20 4,84 2,27 9,27<br>sdf 0,02 0,06 14,12 0,23 379,27 3,59 189,64 1,80 26,67 0,03 2,39 2,06 2,95
<br>sdg 0,00 0,15 3,65 0,09 125,87 2,98 62,94 1,49 34,43 0,01 2,40 2,34 0,88<br>sdh 0,05 0,14 22,89 3,80 627,53 68,19 313,76 34,09 26,07 0,08 3,11 2,73 7,29
<br><br>Hora: 13:48:26<br>Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util<br>sdb 0,00 0,00 5,30 1,66 84,77 42,38 42,38 21,19 18,29 0,04 6,43 6,43 4,47
<br>sdc 0,00 0,00 0,33 2,32 5,30 149,67 2,65 74,83 58,50 0,02 7,38 7,37 1,95<br>sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
<br>sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00<br>sdf 0,00 0,33 0,00 0,66 0,00 7,95 0,00 3,97 12,00 0,00 6,50 6,50 0,43
<br>sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00<br>sdh 0,00 0,00 6,29 1,66 100,66 26,49 50,33 13,25 16,00 0,04 4,75 4,75 3,77
<br><br>Hora: 13:48:29<br>Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util<br>sdb 0,00 0,33 39,13 2,01 626,09 45,48 313,04 22,74 16,33 0,11 2,60 2,57 10,57
<br>sdc 0,00 0,33 0,00 5,02 0,00 58,19 0,00 29,10 11,60 0,03 6,80 6,80 3,41<br>sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
<br>sde 0,00 0,00 0,00 0,33 0,00 10,70 0,00 5,35 32,00 0,01 18,00 18,00 0,60<br>sdf 0,00 0,00 0,33 0,00 5,35 0,00 2,68 0,00 16,00 0,00 1,00 1,00 0,03
<br>sdg 0,00 0,00 0,00 0,33 0,00 5,35 0,00 2,68 16,00 0,01 17,00 17,00 0,57<br>sdh 0,00 0,33 17,73 2,34 283,61 40,13 141,81 20,07 16,13 0,09 4,70 4,70 9,43
<br><br>A coluna %util exibe o percentual de utilização da capacidade de IO de cada disco. Valores constantes muito próximos de 100% indicam que há um gargalo de IO.<br><br>Abaixo, no mesmo servidor, capturei o cabeçalho do comando top:
<br><br>top - 13:40:12 up 30 days, 23:35, 1 user, load average: 3.86, 3.61, 3.53<br>Tasks: 494 total, 1 running, 493 sleeping, 0 stopped, 0 zombie<br>Cpu(s): 3.5% us, 0.9% sy, 0.0% ni, 70.5% id, 24.7% wa, 0.1%
hi, 0.3% si<br>Mem: 8060328k total, 7382104k used, 678224k free, 358872k buffers<br>Swap: 8193140k total, 60284k used, 8132856k free, 4062004k cached<br><br>Se você observar, na linha Cpu(s) a coluna wa indica que naquele momento as operações de IO utilizavam 24% de CPU. Isto é um pico neste ambiente de produção e não deve ser uma constante. Caso esta coluna sempre tenha valores altos, há um gargalo de disco sério.
<br><br>No pacote sysstat também há o comando vmstat que pode lhe dar alguma pista sobre o desempenho de seu IO.<br><br>o comando vmstat 5 100 exibe mil relatórios com intervalos de 5 segundos<br>procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
<br> r b swpd free buff cache si so bi bo in cs us sy id wa<br> 1 0 60284 651464 359336 4064600 0 0 729 118 3 2 9 2 83 6<br> 0 1 60284 648128 359336 4064600 0 0 134 127 3440 1708 4 2 91 4
<br> 0 1 60284 646272 359336 4064600 0 0 1019 377 3907 2391 2 1 84 13<br> 0 0 60284 649992 359344 4064592 0 0 99 42 3065 1300 2 1 95 3<br><br>A coluna b exibe a quantidade de processos bloqueados aguardando a resposta de uma requisição de IO que não foi atendida. O valor aceitável é até uma unidade por CPU.
<br><br>Como você tem apenas 4 discos utilizar RAID 5 não otimiza a performance, embora melhore a tolerância a falhas. Usar RAID 0 iria otimizar a performance mas não ofereceria nenhuma tolerância a falhas.<br>Uma sugestão (caso o orçamento permita) seria RAID 5 usando 9 discos (1 como disco de paridadade) ou pelo menos raid 5 com 5 discos (1 como disco de paridade)
<br>Controladoras com cache pequeno são fatais para a performance. Pelo menos 256MB de cache é aceitável dependendo da sua apĺicação.<br>Os mans dos comandos podem ajudar mais. Espero que estas informações sirvam como um pontapé inicial.
<br><br>Robert Pereira<br>3Consult Soluções de TI<br><a href="http://www.3consult.com.br">www.3consult.com.br</a><br>Salvador - BA<br><br><br><br><br><br><br><br><br><br>Ainda neste pacote<br><br><div><span class="gmail_quote">
Em 25/06/07, <b class="gmail_sendername">Eduardo Nakamatu</b> <<a href="mailto:enakamatu@gmail.com">enakamatu@gmail.com</a>> escreveu:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Srs,<br><br>Tenho um servidor com 4 discos SAS em raid (não me recordo qual), e<br>temos instalado nele o banco de dados db2 express-c. Apesar de nossa<br>base ser pequena, notaos certa lentidao em alguns processos, e ja<br>
olhamos processador e memoria, faltando apenas o acesso ao disco.<br><br>Pergunto, como poso fazer a analise de acesso ao disco?<br><br>--<br>Eduardo Nakamatu<br>Analista de Negocios Microsiga / Programador ADVPL<br>---------------------------------------------------
<br>Linux User:<br>---------------------------------------------------<br>Mail | enakamatu(at)gmail.com<br>Blog | <a href="http://enakamatu.wordpress.com">enakamatu.wordpress.com</a><br>Msn | <a href="mailto:enakamatu@hotmail.com">
enakamatu@hotmail.com</a><br><br>--<br>Fedora-users-br mailing list<br><a href="mailto:Fedora-users-br@redhat.com">Fedora-users-br@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-users-br">https://www.redhat.com/mailman/listinfo/fedora-users-br
</a><br></blockquote></div><br>