executando tar bloqueia completamente o mysql

Question

Estou tendo um problema seriamente estranho. Se eu tar algum diretório aleatório com muitos arquivos ou um único arquivo grande tar -pcvf files.tar /var/log , o mysql fica completamente bloqueado e todas as conexões do mysql são usadas pelo tempo em que tar está sendo executado.

Meu erro nginx.log é preenchido com

2011/04/01 04:29:11 [error] 15089#0: *39023131 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.domain.com, request: "GET /some.html HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "www.domain.com", referrer: "http://www.domain.com/some-other.html"

Eu vejo muitas conexões bloqueadas se eu correr

SHOW PROCESSLIST;

Meu servidor tem 4 CPUs com 8 núcleos (32 núcleos, 64 threads) e 64GB RAM . Tem 6x discos SSD no RAID 10 . Top mostra 100% cpu em 1 core em uso para tar , mas logo após tar finishes, o cqu do mysql usa pulos para mais de 600% por um segundo ou dois.

top - 04:48:29 up 37 days, 14:17,  4 users,  load average: 3.82, 1.37, 0.99
Tasks: 1035 total,   1 running, 1034 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.4%us,  7.4%sy,  0.0%ni, 89.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  65980076k total, 43154916k used, 22825160k free,   523560k buffers
Swap:  1052248k total,        0k used,  1052248k free, 37479984k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9325 mysql     15   0 7624m 2.3g 4700 S 606.3  3.6   6861:35 mysqld

• A versão do mysql é 5.1.56
• Linux 2.6.18-238.1.1.el5 # 1 SMP Ter Jan 4 13:32:19 EST 2011 x86_64 x86_64 x86_64 GNU / Linux
• O mysql tem o log binário ativado

my.cnf é otimizado de acordo com sugestões de tuning-primer e mysqltuner e sem nenhum aviso. (exceto para conexões maximizadas devido a tar issue)

[mysqld]
server-id        = 100
datadir          = /var/lib/mysql
port             = 3306
socket           = /var/lib/mysql/mysql.sock
log-error        = /var/log/mysql/mysql.err
log-bin          = /var/log/mysql/mysql-bin
log-bin-index    = /var/log/mysql/mysql-bin.index

expire_logs_days = 2
sync_binlog      = 1

skip-external-locking
skip-innodb

slow_query_log           = 1
slow_query_log_file      = /var/log/mysql/slow_query.log
long_query_time          = 10

max_connections          = 768
key_buffer               = 6G
table_cache              = 15360
read_buffer_size         = 2M
read_rnd_buffer_size     = 2M
sort_buffer_size         = 1M
tmp_table_size           = 128M
max_heap_table_size      = 128M
max_allowed_packet       = 16M
bulk_insert_buffer_size  = 16M
myisam_sort_buffer_size  = 128M
thread_cache_size        = 64
join_buffer_size         = 1M

Eu tentei algumas outras ferramentas de compactação como pigz e gzip e tudo está normal. pigz é multithreaded então usa todos os núcleos ao máximo. A parte superior mostra o uso de 3000% cpu se eu executá-lo e o mysql é executado sem problemas - nem uma única consulta ou bloqueio de tabela.

De qualquer forma, não sei se isso é um problema de tar ou mysql e como resolvê-lo. Eu apreciarei qualquer ajuda. Desculpe pelo meu inglês:)

Obrigado!

EDITAR:

maior iostat 2 durante tar

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.20    0.00    1.31    7.81    0.00   90.68

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda            1179.00       308.00    452244.00        616     904488
sda1              0.00         0.00         0.00          0          0
sda2           1179.00       308.00    452244.00        616     904488
sda3              0.00         0.00         0.00          0          0

maior top durante tar

top - 05:26:07 up 37 days, 14:55,  4 users,  load average: 2.45, 1.70, 1.07
Tasks: 1045 total,   2 running, 1043 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  1.7%sy,  0.0%ni, 91.7%id,  6.4%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  65980076k total, 39148160k used, 26831916k free,   488752k buffers
Swap:  1052248k total,        0k used,  1052248k free, 33484548k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27604 root      25   0 76192 1072  896 R 99.5  0.0   0:23.94 tar

maior vmstat durante tar

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  5      0 21973424 474068 37700200    0    0     1    19    0    0  1  0 99  0  0

maior slabtop durante tar

 Active / Total Objects (% used)    : 9150253 / 12383252 (73.9%)
 Active / Total Slabs (% used)      : 452818 / 453490 (99.9%)
 Active / Total Caches (% used)     : 105 / 149 (70.5%)
 Active / Total Size (% used)       : 1359015.74K / 1709422.53K (79.5%)
 Minimum / Average / Maximum Object : 0.02K / 0.14K / 128.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
8161880 5170966  63%    0.09K 204047       40    816188K buffer_head
2796624 2795723  99%    0.21K 155368       18    621472K dentry_cache
295320 292658  99%    0.09K   7383       40     29532K journal_head
294665 215031  72%    0.52K  42095        7    168380K radix_tree_node
136800 136770  99%    0.02K    950      144      3800K avtab_node
132192  86357  65%    0.08K   2754       48     11016K selinux_inode_security
127680 119472  93%    0.03K   1140      112      4560K size-32
 74565  69314  92%    0.74K  14913        5     59652K ext3_inode_cache
 64320  40789  63%    0.12K   2144       30      8576K inet_peer_cache
 59972  55193  92%    0.17K   2726       22     10904K vm_area_struct

saída para cat /proc/mdstat

Personalities :
unused devices: <none>

saída para mount

/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

saída para df -i

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2            46497792  144610 46353182    1% /
/dev/sda1              26104      46   26058    1% /boot
tmpfs                8247509       1 8247508    1% /dev/shm

    

Answer 1

Tive exatamente o mesmo problema. Hardware como abaixo ...

• Servidor HP DL180-G6 Nearline
• unidades SAS 15k de 4 x 300 GB
• 2 unidades SATA de 10 TB 10k
• 2x CPU Xeon 5340 de 2,53 GHz (total de 8 núcleos)
• 32 GB DDR3 1066 MHz
• HP Storageworks HBA P410 (PCI Express - 1 para todos os HDDs)
• HP Storageworks HBA P212 / Zero (PCI Express - 1 para a unidade de fita externa)
• Unidade de fita SAS externa HP Ultrium LTO 4 (800/1600 MB)

Quando nós rodávamos o backup diário de fita com tar -options -source from /mnt/backup -destination to /dev/st0 (tape) , ele basicamente trava todo o maldito computador. O primeiro serviço que sofreu foi o MySQL, que seria inacessível através do soquete do sistema de arquivos Unix (/var/lib/mysql/mysql.sock), e então os processos travariam um por um. Mesmo o terminal (prompt do bash) estava inutilizável, e esquece de abrir qualquer coisa de dentro do gui (Gnome Desktop).

A solução não foi usar 'nice', mas sim usar 'ionice'. Não foi o carregamento da CPU que foi o problema, mas o carregamento do disco. Os discos e os processadores são rápidos o suficiente, mas o backbone (adaptador de disco rígido / PCI-express bus / etc.) simplesmente não conseguia acompanhar.

Então, aqui estava a correção ...

Comando de backup do tar antigo:

[root@somewhere]# /bin/tar -clpzvf /dev/st0 /mnt/backup

Novo comando de backup de tarts:

[root@somewhere]# /usr/bin/ionice -c2 -n5 /bin/tar -clpzvf /dev/st0 /mnt/backup

Para sua referência, aqui está a man page do comando 'iowait' ... ela é suportada nos kernels 2.6.13 e mais recentes: - link - as prioridades de ionização para os sistemas de classe 2 têm valores 'sãos' entre 3 e 5, se você estiver tentando reduzir a velocidade de uma tarefa sem fazer com que demore para sempre. onde 3 é moderadamente mais lento e 5 é muito mais lento.

Efetivamente o dobro do tempo necessário para executar o backup de fita (de meia hora, agora é cerca de uma hora), mas quem se importa, agora está funcionando como desejado.

    

Answer 2

O problema é contenção. O fato de que o nível de carga é alto confirma isso.

A solução sorta-ok seria executar o processo de tar com bom para diminuir a prioridade. Isso pode ou não ser o suficiente para fazer o mysql não engasgar.

A melhor solução é colocar o mysql em diferentes eixos. Eu assumo pelos nomes dos dispositivos tudo isso rodando em um disco local. Eu sugiro pegar outro disco e mover o mysql para ele.

    

Answer 3

Qual programador de E / S você está usando? (Use cat /sys/block/sda/queue/scheduler para determiná-lo).

Outro problema pode ser que você esteja envenenando o cache de disco com a leitura de arquivos grandes e dados do mysql sendo deslocados com este arquivo. Nesse caso, você pode tentar usar alguma ferramenta de compactação / backup que suporte o directio (e ignora o cache).

Outra opção é aumentar o cache de páginas internas do mysql (acredito que isso seja possível apenas para o innodb).

    

Answer 4

Acho que o problema é mais provável com seus discos / sistema de arquivos / kernel / bus / drivers e não com tar ou mysql .

O fato de adicionar compressão pesada pode ser usado para contornar o problema indica que o problema é contenção em algum lugar nas camadas I / O, sistema de arquivos ou bloqueio, já que a carga que o tar pode colocar no sistema de arquivos é menor A CPU está ocupada com a compactação. Provavelmente deixando espaço suficiente para as necessidades de E / S do MySQL.

EDIT: Apenas um pensamento ... Poderia ser que sua matriz de disco é simplesmente "muito rápida" e o kernel do Linux não é "ajustado" ou preparado para esse tipo de respostas rápidas? / p>

Talvez haja algum ajuste de sysctl que ajude a reduzir o bloqueio. Eu sei muito pouco sobre as partes internas do kernel do Linux para dar conselhos adequados aqui, mas se você puder pagar um pouco de experimentação, você pode tentar mexer (depois de ler / consultar) com o seguinte:

vm.pagecache
vm.max-readahead
vm.overcommit
vm.overcommit_ratio
vm.max_map_count
kernel.sched_interactive
vm.vfs_cache_pressure

e sysctls semelhantes.

A RedHat Magazine tem um artigo sobre a memória virtual no linux que pode ser um bom ponto de partida para analisando o problema.

(seção de resposta final)

Eu acho estranho usar menos de 8 GB de RAM para o mysql quando você tem 64 GB no servidor. O servidor tem outras responsabilidades também? Servidor de arquivos, talvez?

Quantos dados você coloca no arquivo tar quando você vê esses problemas no MySQL?

Quer compartilhar a saída de cat /proc/mdstat e mount também? (E df -i se não for muito particular :-)) Seria interessante ver quais sistemas de arquivos você usa (alguns são mais intensivos de CPU que outros, alguns são menos "provados"), e se você tem um hardware ou RAID de software, bem como os HBAs que você possui.

Assumindo que 2.6.18-238.1.1.el5 #1 é o kernel oficial do RedHat, você pediu o apoio deles sobre o problema? Pode haver todos os tipos de correções de "melhoria" neste kernel que causam esse tipo de comportamento inesperado que não estaria no kernel 2.6.18 vanilla.

Meio que é chato ter esse tipo de problema com um servidor tão bom, não é?

    

Answer 5

Você tentou excluir os arquivos bin-log e index, ou todos os logs relacionados ao mysql do tar? mesmo problema?

Talvez o "sync_binlog = 1" + tar tenha algum efeito de bloqueio?

    

Answer 6

Eu devo considerar o uso de pmp (perfilador do homem pobre) para rastrear todas as chamadas do sistema feitas pelo processo do MySQL durante um desses períodos de desaceleração.

Com isso, você pode descobrir o que está fazendo o processo esperar por tanto tempo que parece pendurado.

Boa sorte.

    

Answer 7

Concordo com o poisonbit, mas ainda não posso votar. Então aqui está minha versão:

Tem certeza absoluta de que isso acontece em caminhos arbitrários ? Como em qualquer um dos caminhos que não têm absolutamente nada a ver com /var/log ou /var/lib ?? Esse problema ocorre quando você está fazendo backup de seu diretório inicial ou /etc , por exemplo? Suspeito que o seu problema seja apenas um conflito entre MySQL e tar .

Não há nada arbitrário sobre /var/log e muito mais quando se fala de MySQL com o binlog ativado.

tar é um comando de arquivamento; Significa "Arquivador de fitas". Não é um utilitário de compressão e, como tal, terá um uso muito diferente de CPU / Mem / disco do que qualquer utilitário de compressão. Você pode ver e confirmar isso quando ler a página man .

Sua intenção principal é pegar uma cópia internamente consistente de um arquivo e colocá-lo em outro lugar. Se MySQL se excitar somente quando tar estiver em execução, é provável que tar esteja irritando MySQL , e você deve desligar MySQL ao executar backups em /var/log ou usar outro utilitário de backup como Por exemplo, mysqldump ou mysqlhotcopy . Embora, se tudo o que você está fazendo for copiar os log binários, talvez um simples cp funcione melhor que tar .