У меня очень странная проблема. Если я tar какой-то случайный каталог с множеством файлов или одним большим файлом tar -pcvf files.tar /var/log, mysql полностью блокируется, и все соединения mysql на время используются tar это работает.
Мой журнал ошибок nginx заполняется
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"
Я вижу много заблокированных соединений, если бегу
SHOW PROCESSLIST;
На моем сервере 4 процессора по 8 ядер (32 ядра, 64 потока) и 64 ГБ RAM. Оно имеет 6x SSD-дисков в RAID 10. Top показывает, что 100% ЦП на 1 ядре используется для tar но сразу после tar заканчивается, mysql cpu использует скачки до более чем 600% на секунду или две.
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
my.cnf оптимизирован в соответствии с предложениями tuning-primer и mysqltuner и без каких-либо предупреждений. (за исключением соединений, превышающих максимальное значение из-за 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
Я пробовал другие инструменты сжатия, например pigz и gzip и все нормально. pigz является многопоточным, поэтому максимально использует все ядра. Лучшие шоу закончились 3000% ЦП используйте, если я запускаю его, а mysql работает без проблем - ни одного запроса или блокировки таблицы.
В любом случае я не знаю, так ли это tar или проблема с mysql и как ее устранить. Буду признателен за любую помощь. Извините за мой английский :)
Спасибо!
РЕДАКТИРОВАТЬ:
самый высокий iostat 2 в течение 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
самый высокий top в течение 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 в течение 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
самый высокий slabtop в течение 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
выход для cat /proc/mdstat
Personalities :
unused devices: <none>
выход для 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)
выход для 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
Была точно такая же проблема. Оборудование, как показано ниже ...
Когда мы запускали ежедневное резервное копирование на ленту с tar -options -source from /mnt/backup -destination to /dev/st0 (tape), это в основном заблокировало бы весь проклятый компьютер. Первым пострадавшим сервисом был MySQL, который был бы недоступен через сокет файловой системы Unix (/var/lib/mysql/mysql.sock), и тогда процессы один за другим падали. Даже терминал (приглашение bash) не использовался, и забудьте об открытии чего-либо из графического интерфейса (Gnome Desktop).
Решением было не использовать «хороший», а «ионный». Проблема была не в загрузке процессора, а в загрузке диска. Диски и процессоры достаточно быстрые, но магистраль (адаптер жесткого диска / шина PCI-express и т. Д.) Просто не успевала.
Итак, вот исправление ...
Старая команда резервного копирования tar:
[root@somewhere]# /bin/tar -clpzvf /dev/st0 /mnt/backup
Новая команда резервного копирования tar:
[root@somewhere]# /usr/bin/ionice -c2 -n5 /bin/tar -clpzvf /dev/st0 /mnt/backup
Для справки, вот страница руководства для команды iowait ... она поддерживается в ядрах 2.6.13 и новее: - http://linux.die.net/man/1/ionice - ионные приоритеты для систем класса 2 имеют «нормальные» значения от 3 до 5, если вы пытаетесь что-то замедлить, не заставляя это длиться вечно. где 3 умеренно замедлен, а 5 очень сильно замедлен.
Фактически вдвое увеличилось время, необходимое для выполнения резервного копирования на ленту (с получаса, теперь это около часа), но кого это волнует, теперь оно работает так, как нужно.
Проблема в раздоре. Подтверждением этому является высокий уровень нагрузки.
Решение sorta-ok было бы запустить процесс tar с nice для понижения приоритета. Этого может хватить, а может и хватить, чтобы mysql не подавился.
Лучшее решение - установить mysql на разные шпиндели. Судя по именам устройств, все это работает на одном локальном диске. Я бы посоветовал взять другой диск и перенести на него mysql.
Какой планировщик ввода-вывода вы используете? (Используйте cat /sys/block/sda/queue/scheduler чтобы определить это).
Другая проблема может заключаться в том, что вы отравляете кеш-диск ОС, читая большой файл, и данные mysql замещаются этим файлом. В этом случае вы можете попробовать использовать какой-нибудь инструмент сжатия / резервного копирования, который поддерживает directio (и обходит кеш ОС).
Другой вариант - увеличить внутренний кеш страниц mysql (я считаю, что это возможно только для innodb).
Я думаю, что проблема, скорее всего, связана с вашими дисками / файловой системой / ядром / шиной / драйверами, а не с tar или mysql.
Тот факт, что добавление сильного сжатия может использоваться для решения проблемы, указывает на то, что проблема заключается в конфликте где-то на уровнях ввода-вывода, файловой системы или блокировки, так как нагрузка, которую tar может возложить на файловую систему, меньше, когда процессор занят. со сжатием. Вероятно, оставив достаточно места для нужд ввода-вывода MySQL.
РЕДАКТИРОВАТЬ: Просто подумайте ... Может быть, ваш дисковый массив просто "слишком быстр", а ядро Linux не "настроено" и не подготовлено для такого рода быстрых ответов?
Может быть, есть sysctl настройка, которая может помочь уменьшить блокировку. Я слишком мало знаю о внутреннем устройстве ядра Linux, чтобы дать здесь правильный совет, но если вы можете позволить себе немного поэкспериментировать, вы можете попробовать поиграть (после прочтения / консультации) со следующим:
vm.pagecache
vm.max-readahead
vm.overcommit
vm.overcommit_ratio
vm.max_map_count
kernel.sched_interactive
vm.vfs_cache_pressure
и аналогичные sysctls.
RedHat Magazine имеет статья о виртуальной памяти в Linux, это может быть хорошей отправной точкой для анализа проблемы.
(конец раздела ответа)
Мне кажется странным, что вы используете менее 8 ГБ ОЗУ для mysql, когда у вас 64 ГБ на сервере. Есть ли у сервера и другие обязанности? Возможно, файловый сервер?
Сколько данных вы помещаете в tar-файл, когда сталкиваетесь с зависаниями MySQL?
Хочу поделиться результатами cat /proc/mdstat и mount также? (И df -i if не слишком частный :-)) Было бы интересно посмотреть, какие файловые системы вы используете (некоторые из них более загружены ЦП, чем другие, некоторые менее "проверены"), и если у вас есть аппаратный или программный RAID, а также как у вас есть HBA.
Предполагая 2.6.18-238.1.1.el5 #1 это официальное ядро RedHat, спрашивали ли вы их службу поддержки о проблеме? В этом ядре могут быть всевозможные «улучшающие» исправления, которые вызывают такого рода неожиданное поведение, которого не было бы в ядре vanilla 2.6.18.
Отстойно иметь такие проблемы с таким хорошим сервером, не так ли?
Вы пытались исключить файлы bin-log и индекс или все журналы, связанные с mysql, из tar? такая же проблема?
Может быть, что "sync_binlog = 1" + tar имеет какой-то блокирующий эффект?
Я должен подумать об использовании pmp (профайлер бедняков) для отслеживания всех системных вызовов, выполняемых процессом MySQL во время одного из этих периодов замедления.
С его помощью вы можете узнать, что заставляет процесс так долго ждать, что кажется зависшим.
Удачи.
Я согласен с ядом, но пока не могу проголосовать за. Итак, вот моя версия:
Вы абсолютно уверены, что это произойдет произвольный пути ?? Например, любые / все пути, которые не имеют абсолютно ничего общего с /var/log или /var/lib ?? Возникает ли эта проблема при резервном копировании домашнего каталога или /etc например ?? Я подозреваю, что ваша проблема - это просто конфликт между MySQL и tar.
В этом нет ничего произвольного /var/log и многое другое, когда речь идет о MySQL с включенным binlog.
tar архивная команда; Это означает «Ленточный архиватор». это не утилита сжатия, и поэтому она будет иметь совершенно другое использование ЦП / памяти / диска, чем любая другая утилита сжатия. Вы можете увидеть и подтвердить это, когда прочитаете man страница.
Его основная цель - взять внутренне непротиворечивую копию файла и поместить ее в другое место. Если MySQL сходит с ума только когда tar работает, то вероятно tar бесит MySQL, и вы должны закрыть MySQL при запуске резервного копирования на /var/logили воспользуйтесь другой утилитой резервного копирования, например, mysqldump или mysqlhotcopy. Хотя, если все, что вы делаете, это копируете бинлоги, то, возможно, простой cp будет работать лучше чем tar.