我有一个非常奇怪的问题。如果我的tar某个随机目录包含许多文件或单个大文件tar -pcvf files.tar /var/log,则 mysql 会完全锁定,并且所有 mysql 连接都会在tar运行时耗尽。
我的 nginx error.log 被填满了
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"
Run Code Online (Sandbox Code Playgroud)
如果我运行,我会看到许多锁定的连接
SHOW PROCESSLIST;
Run Code Online (Sandbox Code Playgroud)
我的服务器有4 个 CPU,8 个内核(32 个内核,64 个线程)和64GB RAM。它在 RAID 10 中有6 个 SSD 磁盘。
Top显示 100% cpu on 1 core is used fortar但就在tar完成后,mysql cpu use 跳到超过 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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
我已经尝试了一些其他的压缩工具,如pigz和gzip一切正常。
pigz是多线程的,因此它最大限度地使用所有内核。如果我运行它并且 mysql 运行没有问题,则顶部显示超过3000% 的 cpu使用 - 不是单个查询或表锁定。
无论如何,我不知道这是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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
输出 cat /proc/mdstat
Personalities :
unused devices: <none>
Run Code Online (Sandbox Code Playgroud)
输出 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)
Run Code Online (Sandbox Code Playgroud)
输出 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
Run Code Online (Sandbox Code Playgroud)
小智 5
有完全相同的问题。硬件如下...
当我们使用 运行每日磁带备份时tar -options -source from /mnt/backup -destination to /dev/st0 (tape),它基本上会锁定整个该死的计算机。第一个受到影响的服务是 MySQL,它无法通过 Unix 文件系统套接字 (/var/lib/mysql/mysql.sock) 访问,然后进程会一个一个崩溃。甚至终端(bash 提示符)也无法使用,忘记从 gui(Gnome 桌面)中打开任何内容。
解决方案不是使用“nice”,而是使用“ionice”。问题不是 CPU 负载而是磁盘负载。磁盘和处理器足够快,但主干(硬盘适配器/PCI-express 总线等)却跟不上。
所以,这里是修复...
旧的 tar 备份命令:
[root@somewhere]# /bin/tar -clpzvf /dev/st0 /mnt/backup
Run Code Online (Sandbox Code Playgroud)
新的 tar 备份命令:
[root@somewhere]# /usr/bin/ionice -c2 -n5 /bin/tar -clpzvf /dev/st0 /mnt/backup
Run Code Online (Sandbox Code Playgroud)
供您参考,这里是“iowait”命令的联机帮助页……它在内核 2.6.13 和更新版本上受支持: - http://linux.die.net/man/1/ionice - 2 类系统的 ionice 优先级如果您试图减慢某些事情的速度而不让它永远持续下去,请使用 3 到 5 之间的“理智”值。其中 3 中度放慢,5 放慢很多。
有效地将运行磁带备份所需的时间增加了一倍(从半小时开始,现在大约是一个小时),但谁在乎,它现在可以正常工作了。