☰

运行 tar 会完全锁定 mysql

tag-icon • tag-icon linux mysql tar
运行 tar 会完全锁定 mysql

我遇到了一个非常奇怪的问题。如果我的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"

如果我运行，我会看到许多锁定的连接

SHOW PROCESSLIST;

我的服务器有4 个 CPU，每台 8 核（32 核，64 线程）和64GB 内存. 它有RAID 10 中的 6 个 SSD 磁盘. Top显示 1 个核心上的 CPU 使用率为 100%，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
  • Mysql版本是5.1.56
  • Linux 2.6.18-238.1.1.el5 #1 SMP 2011 年 1 月 4 日星期二 13:32:19 EST x86_64 x86_64 x86_64 GNU/Linux
  • Mysql已经启用binlog了

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% CPU如果我运行它并且mysql运行没有问题 - 没有单个查询或表锁。

无论如何，我不知道这是否是tarmysql 问题以及如何解决它。我将不胜感激任何帮助。抱歉我的英语不好 :)

谢谢！

编辑：

最高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

答案1

遇到了完全相同的问题。硬件如下...

  • HP DL180-G6 近线服务器
  • 4 个 300 GB SAS 15k 驱动器
  • 2 个 1TB SATA 10k 驱动器
  • 2x Xeon 5340 2.53 GHz CPU（共 8 核）
  • 32 GB DDR3 1066 MHz
  • HP Storageworks HBA P410（PCI Express - 1 适用于所有 HDD）
  • HP Storageworks HBA P212/Zero（PCI Express - 1 用于外部磁带驱动器）
  • HP Ultrium LTO 4 外置 SAS 磁带驱动器 (800/1600 MB)

当我们使用 运行每日磁带备份时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

新的 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 表示非常减慢。

实际上，运行磁带备份所需的时间增加了一倍（从半小时，现在大约一小时），但谁在乎呢，它现在正在按预期工作。

答案2

问题在于争用。负载水平高的事实证实了这一点。

还算可以的解决方案是使用 nice 来运行 tar 进程以降低优先级。这可能足以或可能不足以让 mysql 不阻塞。

更好的解决方案是将 mysql 放在不同的主轴上。根据设备名称，我假设它们都在一个本地磁盘上运行。我建议获取另一个磁盘并将 mysql 移到该磁盘上。

答案3

您正在使用什么 I/O 调度程序？（使用cat /sys/block/sda/queue/scheduler来确定）。

另一个问题可能是你通过读取大型文件而毒害了操作系统磁盘缓存，mysql 数据被此文件取代。在这种情况下，你可以尝试使用一些支持 directio（并绕过操作系统缓存）的压缩/备份工具。

另一个选择是增加mysql的内部页面缓存（我相信这只对innodb是可能的）。

答案4

您是否尝试过从 tar 中排除 bin-log 文件和索引，或者所有与 mysql 相关的日志？同样的问题？

也许“sync_binlog = 1”+tar 有一些阻塞效果？

相关内容