我有一个非常奇怪的问题。 如果我使用多个文件或单个大文件tar -pcvf files.tar /var/log tar一些随机目录，那么mysql会被完全locking，所有的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"
我看到许多locking连接，如果我运行
SHOW PROCESSLIST;
我的服务器有4个8核 （32核心，64线程）和64GB内存的 CPU 。 它具有RAID 10中的6个SSD磁盘 。 Top显示1核心使用tar 100％CPU，但在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根据调优引擎和mysqltuner的build议进行了优化，没有任何警告。 （除了由于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是multithreading的，所以它最大限度地利用了所有内核。 顶部显示超过3000％的CPU使用，如果我运行它和MySQL运行没有问题 – 没有一个单一的查询或表锁。
无论如何，我不知道这是否是tar或MySQL问题，以及如何排除故障。 我将不胜感激任何帮助。 对不起我的英语不好 ：）
谢谢！
编辑：
tar最高的iostat 2
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
tar最高的top
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
tar最高的vmstat
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
tar最高的slabtop
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)运行每日磁带备份tar -options -source from /mnt/backup -destination to /dev/st0 (tape) ，它基本上locking了整个该死的电脑。 受到的第一个服务是MySQL，它将通过Unix文件系统套接字（/var/lib/mysql/mysql.sock）无法访问，然后进程将一个接一个地崩溃。 即使terminal（bash提示符）也是不可用的，忘记了在gui（gnome桌面）中打开任何东西。
解决办法不是使用“nice”，而是使用“ionice”。 这不是CPU加载问题，而是磁盘加载。 磁盘和处理器速度不够快，但主干（硬盘适配器/ 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类系统的ionice优先级如果你想把速度放慢一些，而又没有把它放在一边，你的理智值应该在3到5之间。 其中3级缓慢下降，5级非常缓慢。
运行磁带备份所花费的时间（从半小时到现在大约一个小时）有效地增加了一倍，但是谁在乎，它现在正在按照需要工作。
问题是争用。 负载水平高的事实证实了这一点。
sorta-ok解决scheme将运行tar进程，并降低优先级。 这可能会或可能不足以让MySQL不呛。
更好的解决scheme是把MySQL放在不同的主轴上。 我假设通过设备名称，这是全部运行在一个本地磁盘上。 我会build议获得另一个磁盘和移动到它的MySQL。
你使用什么I / O调度程序？ （使用cat /sys/block/sda/queue/scheduler来确定它）。
另一个问题可能是你正在读取大文件和mysql数据被这个文件所replace，正在中毒磁盘caching。 在这种情况下，您可能会尝试使用一些支持directio的压缩/备份工具（并绕过oscaching）。
另一个select是增加mysql的内部页面caching（我相信这只适用于innodb）。
我认为这个问题很可能是你的磁盘/文件系统/内核/总线/驱动程序，而不是与tar或mysql 。
事实上，增加大量压缩可以用来解决问题，表明问题是在I / O，文件系统或locking层中的某个地方的争用，因为tar可以放在文件系统上的负担较less，而CPU忙与压缩。 可能为MySQL的I / O需求留下足够的空间。
编辑：只是一个想法…难道是你的磁盘arrays是“太快”，而Linux内核不是“调整”或准备这种快速响应？
也许有一些sysctl调优，可以帮助减less阻塞。 我对Linux内核的内部知识太less了，无法给出适当的build议，但是如果你可以进行一点小小的试验，你可以试试下面的方法：
vm.pagecache vm.max-readahead vm.overcommit vm.overcommit_ratio vm.max_map_count kernel.sched_interactive vm.vfs_cache_pressure
和类似的系统。
RedHat杂志有一篇关于 linux中的虚拟内存的文章 ，可能是分析问题的一个很好的起点。
（结束答案部分）
我觉得当你在服务器上有64GB的时候，你使用less于8GB的内存是很奇怪的。 服务器还有其他的责任吗？ 文件服务器，也许？
当您遇到这些MySQL挂起时，您将多less数据放在tar文件中？
想要分享cat /proc/mdstat的输出并mount吗？ （和df -i如果不是太私人的话:-)）看看你使用的是什么文件系统会比较有趣（有些比其他的更占用CPU资源，有些不太“被certificate”），如果你有硬件或软件RAID，以及你有什么样的HBA。
假设2.6.18-238.1.1.el5 #1是官方的RedHat内核，你是否问过他们对这个问题的支持？ 在这个内核中可能会有各种各样的“改进”补丁，导致这种意想不到的行为，不会在2.6.6内核中出现。
有这么好的服务器有点麻烦，不是吗？
您是否尝试从tar中排除bin-log文件和索引，或所有mysql相关的日志？ 同样的问题？
也许这个“sync_binlog = 1”+ tar有一些阻塞效果？
我应该考虑使用pmp（穷人的分析器）来跟踪所有系统调用MySQL进程在这些放缓时期之一。
有了它，你可能会发现什么使得这个过程等待了很长时间，似乎已经挂起。
祝你好运。
我同意poisonbit，但我不能upvote呢。 所以这是我的版本：
你绝对肯定，这发生在任意path？ 就像在/var/log或/var/lib完全没有任何/所有的path一样。 当你备份你的主目录或者/etc时，会发生这个问题吗？ 我怀疑你的问题只是MySQL和tar之间的冲突。
关于/var/log没有什么特别的，所以在启用binlog的情况下讨论MySQL 。
tar是档案指挥; 它代表“磁带存档”。 这不是一个压缩实用程序，因此它将具有与任何压缩实用程序完全不同的CPU / Mem /磁盘使用率。 当您阅读man页时，您可以看到并确认这一点。
它的主要目的是取一个文件内部一致的副本，并把它放在别的地方。 如果MySQL只在tar运行的时候吓着了，那么很可能是tar被麻烦了，你应该在/var/log上运行备份时closuresMySQL ，或者使用一个不同的备份工具，比如mysqldump或者mysqlhotcopy 。 虽然如果你只是在拷贝binlog，那么简单的cp可能会比tar更好。