Temos um servidor MySQL 5.0 em uma caixa Centos. 32 GB de memória. Temos apenas um disco rígido, capacidade de 374 GB, 50 GB disponíveis. Todas as nossas mesas são MyISAM.
Quando copiamos um arquivo grande (2GB-3GB) dentro do disco rígido, o MySQL desacelera temporariamente. A cópia do arquivo leva menos de um minuto. Mas a desaceleração temporária dura cerca de uma hora (pode até ser exatamente uma hora).
Passada uma hora, de repente tudo volta à sua rotina.
Parece que a cópia de arquivo grande empurra o MySQL para começar a usar o disco rígido para memória, talvez a saída "sar -b" possa ser uma prova disso. Mas por que o mysql começaria a usar o disco rígido, o arquivo copiado é cerca de 10% da RAM total.
Alguma ideia para evitar isso?
Aqui está a saída do sar, a cópia do arquivo foi feita por volta das 11:00:
10:20:01 AM CPU %user %nice %system %iowait %steal %idle
10:30:01 AM all 5.52 0.00 4.40 5.35 0.00 84.72
10:40:01 AM all 5.38 0.00 4.34 5.34 0.00 84.93
10:50:01 AM all 6.44 0.00 4.86 7.00 0.00 81.70
11:00:01 AM all 6.06 0.00 4.33 6.48 0.00 83.12
11:10:02 AM all 6.18 0.00 6.11 9.60 0.00 78.11
11:20:01 AM all 1.92 0.00 1.95 8.58 0.00 87.55
11:30:01 AM all 2.23 0.00 2.59 8.53 0.00 86.64
11:40:01 AM all 3.63 0.00 3.57 8.95 0.00 83.85
Aqui está a saída sar -r:
10:20:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
10:30:01 AM 823860 32125192 97.50 345996 24971808 34995984 232 0.00 0
10:40:01 AM 895852 32053200 97.28 360620 24877364 34995984 232 0.00 0
10:50:01 AM 295556 32653496 99.10 372440 25451620 34995984 232 0.00 0
11:00:01 AM 809260 32139792 97.54 395116 24869132 34995984 232 0.00 0
11:10:02 AM 430732 32518320 98.69 659220 23661112 34995984 232 0.00 0
11:20:01 AM 153580 32795472 99.53 687740 24438764 34995984 232 0.00 0
11:30:01 AM 251816 32697236 99.24 778396 24284876 34995984 232 0.00 0
11:40:01 AM 297912 32651140 99.10 782468 24354304 34995984 232 0.00 0
Olhando para sar -P ALL, CPU 1 tem %70+ iowait:
10:40:01 AM CPU %user %nice %system %iowait %steal %idle
10:50:01 AM all 6.44 0.00 4.86 7.00 0.00 81.70
10:50:01 AM 0 5.87 0.00 4.70 1.77 0.00 87.66
10:50:01 AM 1 12.14 0.00 5.80 44.59 0.00 37.48
10:50:01 AM 2 2.68 0.00 2.30 0.43 0.00 94.58
10:50:01 AM 3 5.90 0.00 4.07 11.72 0.00 78.31
10:50:01 AM 4 2.68 0.00 2.53 0.59 0.00 94.20
10:50:01 AM 5 6.45 0.00 4.88 9.13 0.00 79.54
10:50:01 AM 6 2.84 0.00 2.43 0.52 0.00 94.22
10:50:01 AM 7 5.04 0.00 4.31 3.04 0.00 87.61
10:50:01 AM 8 6.37 0.00 4.85 0.73 0.00 88.04
10:50:01 AM 9 8.88 0.00 6.45 17.30 0.00 67.37
10:50:01 AM 10 5.17 0.00 3.79 1.34 0.00 89.69
10:50:01 AM 11 10.85 0.00 8.95 8.72 0.00 71.48
10:50:01 AM 12 4.12 0.00 3.41 0.93 0.00 91.53
10:50:01 AM 13 10.27 0.00 7.59 7.06 0.00 75.08
10:50:01 AM 14 6.81 0.00 5.69 3.01 0.00 84.48
10:50:01 AM 15 6.94 0.00 6.00 1.15 0.00 85.91
11:00:01 AM all 6.06 0.00 4.33 6.48 0.00 83.12
11:00:01 AM 0 5.86 0.00 6.11 5.44 0.00 82.59
11:00:01 AM 1 11.14 0.00 4.55 45.71 0.00 38.60
11:00:01 AM 2 3.33 0.00 3.24 1.18 0.00 92.25
11:00:01 AM 3 4.33 0.00 3.04 7.62 0.00 85.01
11:00:01 AM 4 2.28 0.00 1.83 1.87 0.00 94.02
11:00:01 AM 5 4.61 0.00 4.51 3.97 0.00 86.91
11:00:01 AM 6 2.59 0.00 2.42 1.80 0.00 93.19
11:00:01 AM 7 3.90 0.00 3.23 2.55 0.00 90.33
11:00:01 AM 8 4.86 0.00 3.94 1.21 0.00 89.99
11:00:01 AM 9 7.06 0.00 5.12 12.43 0.00 75.39
11:00:01 AM 10 4.87 0.00 4.76 1.09 0.00 89.28
11:00:01 AM 11 6.42 0.00 5.20 5.67 0.00 82.71
11:00:01 AM 12 6.28 0.00 5.61 4.63 0.00 83.48
11:00:01 AM 13 14.10 0.00 7.61 4.17 0.00 74.12
11:00:01 AM 14 4.76 0.00 3.54 3.67 0.00 88.04
11:00:01 AM 15 10.64 0.00 4.61 0.74 0.00 84.01
11:00:01 AM CPU %user %nice %system %iowait %steal %idle
11:10:02 AM all 6.18 0.00 6.11 9.60 0.00 78.11
11:10:02 AM 0 5.79 0.00 4.76 1.17 0.00 88.28
11:10:02 AM 1 5.87 0.00 16.54 72.31 0.00 5.29
11:10:02 AM 2 3.24 0.00 3.04 4.31 0.00 89.42
11:10:02 AM 3 5.66 0.00 5.32 9.17 0.00 79.85
11:10:02 AM 4 3.81 0.00 3.40 1.59 0.00 91.20
11:10:02 AM 5 6.06 0.00 5.02 9.16 0.00 79.77
11:10:02 AM 6 4.10 0.00 3.94 0.71 0.00 91.25
11:10:02 AM 7 4.64 0.00 4.29 6.18 0.00 84.88
11:10:02 AM 8 6.19 0.00 5.12 0.50 0.00 88.20
11:10:02 AM 9 8.72 0.00 8.12 26.72 0.00 56.44
11:10:02 AM 10 6.37 0.00 4.78 1.01 0.00 87.83
11:10:02 AM 11 8.59 0.00 7.01 8.53 0.00 75.86
11:10:02 AM 12 5.43 0.00 5.09 0.72 0.00 88.76
11:10:02 AM 13 11.04 0.00 9.00 6.99 0.00 72.97
11:10:02 AM 14 5.60 0.00 5.33 1.12 0.00 87.95
11:10:02 AM 15 7.73 0.00 7.05 3.40 0.00 81.82
11:20:01 AM all 1.92 0.00 1.95 8.58 0.00 87.55
11:20:01 AM 0 1.85 0.00 1.79 11.58 0.00 84.78
11:20:01 AM 1 4.02 0.00 7.08 77.21 0.00 11.69
11:20:01 AM 2 1.32 0.00 1.14 1.08 0.00 96.46
11:20:01 AM 3 1.35 0.00 1.25 3.75 0.00 93.64
11:20:01 AM 4 1.29 0.00 1.11 1.08 0.00 96.53
11:20:01 AM 5 1.49 0.00 1.37 2.70 0.00 94.44
11:20:01 AM 6 1.59 0.00 1.27 0.92 0.00 96.21
11:20:01 AM 7 1.62 0.00 1.50 3.74 0.00 93.14
11:20:01 AM 8 1.84 0.00 1.68 3.32 0.00 93.15
11:20:01 AM 9 2.09 0.00 2.24 19.19 0.00 76.49
11:20:01 AM 10 2.15 0.00 1.42 1.02 0.00 95.41
11:20:01 AM 11 1.95 0.00 1.95 3.06 0.00 93.04
11:20:01 AM 12 1.90 0.00 1.68 1.10 0.00 95.32
11:20:01 AM 13 2.40 0.00 2.09 2.94 0.00 92.57
11:20:01 AM 14 1.90 0.00 1.87 1.14 0.00 95.09
11:20:01 AM 15 1.89 0.00 1.83 3.37 0.00 92.91
sar -W:
10:20:01 AM pswpin/s pswpout/s
10:30:01 AM 0.00 0.00
10:40:01 AM 0.00 0.00
10:50:01 AM 0.00 0.00
11:00:01 AM 0.00 0.00
11:10:02 AM 0.00 0.00
11:20:01 AM 0.00 0.00
11:30:01 AM 0.00 0.00
11:40:01 AM 0.00 0.00
sar -b, observe o salto logo após as 11h.
10:20:01 AM tps rtps wtps bread/s bwrtn/s
10:30:01 AM 1941.72 296.49 1645.23 2619.86 26872.80
10:40:01 AM 2018.03 341.37 1676.66 3123.88 25695.44
10:50:01 AM 2581.44 460.03 2121.41 6384.41 35324.48
11:00:01 AM 3031.42 508.31 2523.11 4936.72 44437.03
11:10:02 AM 7222.13 1083.55 6138.58 61930.06 122374.97
11:20:01 AM 4832.72 1960.20 2872.53 55023.49 55869.57
11:30:01 AM 2174.64 1619.38 555.26 14751.91 9753.42
11:40:01 AM 2361.23 1682.74 678.49 15293.00 11799.85
11:50:01 AM 2210.12 1433.24 776.88 12757.86 13321.64
12:00:01 PM 3439.84 932.84 2507.01 22081.47 44653.18
As tabelas MyISAM dependem do cache do sistema de arquivos para manter os dados na memória (os índices são mantidos no cache interno do buffer de chaves, conforme especificado por
key_buffer_size). Você não disse qual é o tamanho total dos dados, mas suspeito que sua cópia esteja empurrando blocos de dados para fora do cache fs, de modo que o MySQL tenha que lê-los do disco novamente logo em seguida. Suasar -bsaída suporta isso mostrando 4-5x as leituras do disco logo após a cópia. Há também uma queda muito pequena nos dados armazenados em cache nasar -rsaída - é um pouco difícil de interpretar isso, porque se a cópia está enviando dados para fora, ela está substituindo bytes no cache, então não esperaria ver muito de flutuação lá.Eu recomendaria usar uma ferramenta como o collectl para coletar estatísticas de resolução mais alta (e melhor ainda, enviar esses dados para um mecanismo gráfico como o graphite , para que você possa visualizá-los.
Por que você está executando o MyISAM? O InnoDB não teria esse tipo de problema (pelo menos não tão pronunciado, especialmente com
innodb_flush_method=O_DIRECTset), pois mantém seu próprio buffer pool que armazena em cache índices, dados, MVCC e páginas de desfazer. Se você não pode mudar para o InnoDB ou alterar este trabalho, você pode encontrar ou escrever um programa de cópia simples que faça o que você precisa, mas defina O_DIRECT nas chamadas open(). Isso impedirá que o sistema operacional armazene as páginas em cache.Acabei de atualizar para o MySQL 5.5 e esse problema foi resolvido. Tentei com arquivos de até 10 GB e o MySQL não foi afetado.