5 votos

ejecuta tar completamente mysql se bloquea

Estoy teniendo un serio extraño asunto. Si I tar aleatoria de directorios con muchos archivos o un solo archivo grande tar -pcvf files.tar /var/log, mysql consigue completamente encerrado y todas las conexiones de mysql obtener utilizados para el tiempo tar está ejecutando.

Mi nginx error.de registro, se rellena con

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"

Veo que muchos Bloqueado las conexiones si me quedo

SHOW PROCESSLIST;

Mi servidor tiene 4 Cpu con 8 núcleos (32 núcleos, 64 hilos) y 64 GB de RAM. Se ha 6x discos SSD en RAID 10. Top muestra el 100% de la cpu en 1 básico en el uso de tar , pero sólo después de la tar acabados, mysql uso de la cpu salta a más de 600% durante un segundo o dos.

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
  • Versión de Mysql es 5.1.56
  • Linux 2.6.18-238.1.1.el5 #1 SMP Tue Jan 4 13:32:19 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
  • Mysql ha habilitado binlog

mi.cnf es optimizada de acuerdo a la afinación de cebadores y mysqltuner sugerencias y sin ninguna advertencia. (excepto para las conexiones al máximo porque de tar problema)

[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

He probado algunas otras herramientas de compresión como pigz y gzip y todo es normal. pigz es multiproceso para que se utiliza todos los núcleos al máximo. La parte superior muestra más de 3000% de cpu uso si lo ejecuto y mysql se ejecuta sin problema - no una sola consulta o bloqueo de tabla.

De todos modos, no sé si esto es tar o mysql problema y cómo solucionarlo. Agradezco cualquier ayuda. Lo siento por mi español :)

Gracias!

EDITAR:

mayor 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

mayor 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

mayor 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

mayor 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

salida para cat /proc/mdstat

Personalities :
unused devices: <none>

salida 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)

salida 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

16voto

Kevin Puntos 21

¿Ha tratar de excluir los archivos de registro de bin y el índice, o mysql todos relacionados con registros de la tar? ¿mismo problema?

¿Tal vez "sync_binlog = 1" + alquitrán tiene un efecto de bloqueo?

4voto

Vince Spinelli Puntos 36

Tenía exactamente el mismo problema. Hardware a continuación...

-- HP DL180 G6 Nearline Servidor -- 4x 300 GB SAS 15k unidades -- 2x 1 TB SATA 10k unidades -- 2x Xeon 5340 2.53 GHz CPU (8 núcleos en total) -- 32 GB de memoria DDR3 a 1066 MHz -- HP Storageworks HBA P410 (PCI Express - 1 para todos los HDD) -- HP Storageworks HBA P212/Cero (PCI Express - 1 para la unidad de cinta externa) -- HP LTO Ultrium 4 externos unidad de cinta SAS (800/1600 MB)

Cuando corríamos el diario de cinta de copia de seguridad con "tar-opciones-fuente de /mnt/backup-destino a /dev/st0 (cinta)", básicamente se trataría de bloqueo de seguridad de todo el maldito ordenador. El primer servicio de sufrir era de MySQL, que sería inalcanzable a través del sistema de archivos Unix socket (/var/lib/mysql/mysql.calcetín) y, a continuación, los procesos de accidente, uno por uno. Incluso el terminal (bash) era inutilizable, y olvidarse de la apertura de cualquier cosa, desde dentro de la interfaz gráfica de usuario (Escritorio Gnome).

La solución fue no usar 'bonito', pero en lugar de utilizar 'ionice'. No era de la CPU de la carga que era el problema pero carga en el disco. Los discos y los procesadores están lo suficientemente rápido, pero la columna vertebral (disco duro / adaptador de bus PCI-express / etc.) simplemente no podía mantener el ritmo.

Así que, aquí estaba la solución...

VIEJO TAR DE COPIA DE SEGURIDAD DE COMANDOS: -- [root@en algún lugar]# /bin/tar-clpzvf /dev/st0 /mnt/backup

NUEVA TAR DE COPIA DE SEGURIDAD DE COMANDOS: -- [root@en algún lugar]# /usr/bin/ionice-c2-n5 /bin/tar-clpzvf /dev/st0 /mnt/backup

Para su referencia, aquí está la página del manual para 'iowait' comando... es compatible con kernels 2.6.13 y más reciente: -- http://linux.die.net/man/1/ionice -- ionice prioridades para la clase 2 sistemas tienen 'sane' valores entre 3 y 5 si usted está tratando de reducir algo sin lo que es tomar por evvveeeeeee---rrrrrrrr... donde 3 es moderadamente disminuido y 5 es muy ralentizado.

Efectivamente se duplicó el tiempo que se tarda en ejecutar la copia de seguridad en cinta (de una media hora, ahora es alrededor de una hora), pero a quién le importa, ahora está trabajando como se desee.

1voto

Chris Puntos 364

El problema es contención. Esto confirma el hecho de que el nivel de carga es alto.

Sería la solución de sorta ok ejecutar el proceso de alquitrán con agradable para bajar la prioridad. Puede o puede no ser suficiente para que mysql no ahogarse.

La mejor solución es poner mysql en diferentes husos. Supongo que por los nombres de dispositivo que se está ejecutando en un disco local. Yo sugeriría conseguir otro disco y hacia mysql.

0voto

Sonamor Puntos 76

¿Qué programador de entrada-salida está usando? (Uso cat /sys/block/sda/queue/scheduler para determinarla).

Otro problema podría ser que son envenenamiento caché de disco de sistema operativo con la lectura de datos archivo y mysql ser desplazados con este archivo. En este caso puedes probar a utilizar alguna herramienta de compresión/copia de seguridad que soporta directio (y omite la memoria caché del sistema operativo).

Otra opción es aumentar la memoria caché de la página interna de mysql (creo que esto es posible sólo para innodb).

0voto

MattBianco Puntos 444

Creo que el problema es más probable con sus discos/sistema de archivos/kernel/bus/drivers, y no con tar o mysql.

El hecho de que la adición de compresión pesada puede ser utilizado para solucionar el problema, indica que el problema está en disputa en algún lugar de la e/S del sistema de archivos o el bloqueo de capas, como la carga que tar puede poner en el sistema de archivos es menor mientras la CPU está ocupada con la compresión. Probablemente, dejando espacio suficiente para MySQL I/O necesidades.

EDIT: Solo un pensamiento... ¿Podría ser que el disco de la matriz es simplemente "demasiado rápido" y el kernel de linux no es "tuned" o preparados para ese tipo de respuestas rápidas?

Tal vez hay algunos sysctl de optimización que podría ayudar a reducir el bloqueo. Yo sé muy poco acerca de los componentes internos del kernel de linux para dar asesoramiento adecuado aquí, pero si usted puede permitirse el lujo de experimentar un poco, usted podría tratar de tocar el violín (después de la lectura/consulta) con el siguiente:

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

y similares sysctls.

RedHat Revista tiene un artículo acerca de la memoria virtual en linux que podría ser un buen punto de partida para analizar el problema.

(respuesta final de la sección)

Creo que es raro que utilice menos de 8 GB de RAM para mysql cuando usted tiene 64 GB en el servidor. ¿El servidor tiene otras responsabilidades? Servidor de archivos, tal vez?

La cantidad de datos que se pone en el archivo tar cuando usted experimenta estos MySQL se bloquea?

Quiero compartir el resultado de cat /proc/mdstat y mount también? (Y df -i si no es demasiado privado :-)) sería interesante ver lo que los sistemas de archivo que use (algunos son más intensivo de la CPU que otros, algunos son menos "probado"), y si tienes un RAID de hardware o software, así como lo Hba tiene.

Asumiendo 2.6.18-238.1.1.el5 #1 es el oficial de RedHat kernel, le han pedido su apoyo sobre el problema? Puede haber todo tipo de "mejoras" parches en este kernel que causan este tipo de comportamiento inesperado que no estaría en el vanilla kernel 2.6.18.

Bastante fastidioso tener este tipo de problemas con un buen servidor, ¿no?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: