grimper complètement verrouille mysql

J'ai un problème sérieusement étrange. Si je tar un directory random avec de nombreux files ou un seul grand file tar -pcvf files.tar /var/log , mysql est complètement verrouillé et toutes les connections mysql sont utilisées pour le time tar est en cours d'exécution.

My nginx error.log est rempli avec

 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" 

Je vois de nombreuses connections verrouillées si je cours

 SHOW PROCESSLIST; 

Mon server dispose de 4 CPU avec 8 kernelx (32 kernelx, 64 threads) et 64 Go de RAM . Il dispose de disques SSD 6x dans RAID 10 . Top montre 100% de processeur sur 1 kernel utilisé pour le tar mais juste après la finition du tar , l'utilisation du processeur mysql passe à plus de 600% pendant une seconde ou deux.

 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 
  • La version de Mysql est 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 a binlog activé

my.cnf est optimisé en fonction des suggestions d'optimization et de mysqltuner et sans aucun avertissement. (sauf pour les connections maximisées en raison de la question du tar )

 [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 

J'ai essayé d'autres outils de compression comme pigz et gzip et tout est normal. pigz est multithread afin qu'il utilise tous les kernelx au maximum. Top montre plus de 3000% d' utilisation de la CPU si je l'exécute et mysql s'exécute sans problème – pas une seule requête ou un verrou de table.

Quoi qu'il en soit, je ne sais pas si ce problème est tar ou mysql et comment le résoudre. J'apprécierai toute aide. Désolé pour mon anglais 🙂

Merci!

MODIFIER:

iostat 2 plus élevé pendant le 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 

plus top cours du 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 

vmstat plus élevé pendant le tar

 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ rb 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 

slabtop plus slabtop pendant le 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 

sortie pour cat /proc/mdstat

 Personalities : unused devices: <none> 

sortie pour 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) 

sortie pour 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 

A eu exactement le même problème. Matériel comme ci-dessous …

  • HPline DL180-G6 Nearline Server
  • 4x 300 GB SAS 15k lecteurs
  • 2x 1TB SATA 10k drives
  • CPU 2x Xeon 5340 2,53 GHz (total de 8 cœurs)
  • 32 Go DDR3 1066 MHz
  • HP Storageworks HBA P410 (PCI Express – 1 pour tous les disques durs)
  • HP Storageworks HBA P212 / Zero (PCI Express – 1 pour le lecteur de bande externe)
  • Lecteur de bande externe externe HP Ulsortingum LTO 4 (800/1600 Mo)

Lorsque nous avons exécuté la sauvegarde sur bande quotidienne avec tar -options -source from /mnt/backup -destination to /dev/st0 (tape) , il verrouillerait essentiellement tout le putain d'ordinateur. Le premier service à souffrir était MySQL, qui serait inaccessible à travers le socket du système de files Unix (/var/lib/mysql/mysql.sock), et les process s'écraseront un par un. Même le terminal (bash prompt) était inutilisable, et oubliez d'ouvrir n'importe quoi dans le gui (Gnome Desktop).

La solution n'était pas d'utiliser «agréable», mais plutôt d'utiliser «ionice». Ce n'était pas le chargement du processeur, mais le chargement du disque. Les disques et les processeurs sont assez rapides, mais le backbone (adaptateur de disque dur / PCI-express bus / etc.) ne pouvait tout simplement pas se maintenir.

Alors, voila la solution …

Ancienne command de sauvegarde de tar:

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

Nouvelle command de sauvegarde tar:

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

Pour votre reference, voici la page de manuel pour la command 'iowait' … elle est prise en charge sur les kernelx 2.6.13 et plus récents: – http://linux.die.net/man/1/ionice – les priorités ionice pour les systèmes de class 2 ont des valeurs «saines» entre 3 et 5 si vous essayez de ralentir quelque chose sans que cela ne prenne une éternité. où 3 est modérément ralenti et 5 est très ralenti.

Également doublé le time nécessaire pour exécuter la sauvegarde sur bande (d'une demi-heure, maintenant il s'agit d'environ une heure), mais qui s'en occupe, il fonctionne maintenant comme vous le souhaitez.

Le problème est la contention. Le fait que le niveau de charge est élevé confirme cela.

La solution sorta-ok serait d'exécuter la procédure tar afin de réduire la priorité. Cela peut ou non être suffisant pour get mysql de ne pas étouffer.

La meilleure solution est de mettre mysql sur différentes broches. Je suppose que par les noms de périphériques, tout cela s'exécute sur un disque local. Je suggérerais d'get un autre disque et de passer mysql à cela.

Quel planificateur i / o utilisez-vous? (Utilisez cat /sys/block/sda/queue/scheduler pour le déterminer).

Un autre problème pourrait être que vous empoisonniez le cache du disque dur en lisant un file volumineux et que datatables mysql étaient déplacées avec ce file. Dans ce cas, vous pouvez essayer d'utiliser un outil de compression / sauvegarde qui supporte directio (et contourne le cache).

Une autre option est d'augmenter le cache de la page interne de mysql (je crois que cela n'est possible que pour innodb).

Je pense que le problème est très probable avec vos disques / système de files / kernel / bus / drivers, et non avec tar ou mysql .

Le fait que l'ajout de compression lourde peut être utilisé pour contourner le problème indique que le problème est une contenance quelque part dans l'E / S, le système de files ou les couches de locking, car le fardeau que tar peut mettre sur le système de files est inférieur alors que la CPU est occupée avec la compression. Probablement laisser suffisamment de place pour les besoins d'E / S de MySQL.

EDIT: Juste une pensée … Est-ce que votre réseau de disque est simplement «trop rapide» et que le kernel linux n'est pas «réglé» ou préparé pour ce type de réponses rapides?

Peut-être existe-t-il un accord sysctl qui pourrait aider à réduire le blocage. Je sais trop peu sur les éléments internes du kernel linux pour donner des conseils appropriés ici, mais si vous pouvez vous procurer un peu d'expérimentation, vous pouvez essayer de faire de la violence (après avoir lu / consulté) avec ce qui suit:

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

et des sysctls similaires.

RedHat Magazine a un article sur la memory virtuelle dans linux qui pourrait être un bon sharepoint départ pour parsingr le problème.

(section de réponse finale)

Je pense qu'il est étrange que vous utilisiez less de 8 Go de RAM pour mysql lorsque vous disposez de 64 Go dans le server. Le server a-t-il d'autres responsabilités? Le server de files peut-être?

Combien de données placez-vous dans le file tar lorsque vous rencontrez ces MySQL se bloque?

Voulez-vous partager la sortie de cat /proc/mdstat et mount aussi? (Et df -i si ce n'est pas trop privé :-)) Il serait intéressant de voir les filesystems que vous utilisez (certains sont plus intensifs en CPU que d'autres, certains sont less "éprouvés") et si vous avez un matériel ou logiciel RAID, ainsi que les HBA que vous avez.

En supposant que 2.6.18-238.1.1.el5 #1 est le kernel officiel RedHat, avez-vous demandé leur soutien sur le problème? Il peut y avoir toutes sortes de correctifs "d'amélioration" dans ce kernel qui provoquent ce type de comportement inattendu qui ne serait pas dans le kernel vanilla 2.6.18.

Quelque fois ça manque un tel problème avec un si bon server, n'est-ce pas?

Avez-vous essayer d'exclure les files bin-log et l'index, ou tous les logs liés à mysql du tar? même problème?

Peut-être que "sync_binlog = 1" + tar a un certain effet de blocage?

Je devrais envisager d'utiliser pmp (prof. Homme pauvre) pour tracer tous les appels système effectués par le process MySQL pendant l'une de ces périodes de ralentissement.

Avec cela, vous pouvez découvrir ce qui fait que le process attend tellement longtime qui semble suspendu.

Bonne chance.

Je suis d'accord avec le poisonbit, mais je ne peux pas encore évoluer. Voici donc ma version:

Êtes-vous absolument certain que cela se produit sur des paths arbitraires ? Comme dans, tous les paths qui n'ont absolument rien à voir avec /var/log ou /var/lib ?? Ce problème se produit lorsque vous sauvegardez votre directory personnel ou /etc par exemple ?? Je soupçonne que votre problème n'est qu'un conflit entre MySQL et le tar .

Il n'y a rien d'arbitraire sur /var/log et beaucoup plus quand on parle de MySQL avec binlog activé.

tar est une command d'archivage; Il représente «Tape Archiver». Ce n'est pas un utilitaire de compression, et en tant que tel, il aura une utilisation différente de CPU / Mem / disk par rapport à tout utilitaire de compression. Vous pouvez le voir et le confirmer lorsque vous lisez la page man .

L'intention principale est de prendre une copy interne d'un file et de le mettre ailleurs. Si MySQL ne se triggers que lorsque tar est en cours d'exécution, il est probable que le mysqlhotcopy MySQL et que vous devez fermer MySQL lorsqu'il exécute des sauvegardes sur /var/log ou utiliser un autre utilitaire de sauvegarde comme, par exemple, mysqldump ou mysqlhotcopy . Bien que si tout ce que vous faites est de copyr les binlogs, alors peut-être un cp simple fonctionnera mieux que le tar .