【Mysql】主机cpu之-sys使用率过高

学习大神的http://mp.weixin.qq.com/s/hXtCzSnlVfo9Cq92538ipw自己整理一点思路
1.0top看cpu消耗,发现sys比usr要高不少,这非常不正常

目前创新互联公司已为千余家的企业提供了网站建设、域名、雅安服务器托管绵阳服务器托管、企业网站设计、高州网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

1.1使用pstack看 MySQL所有线程的调用栈:

InnoDB线程同步机制

我们知道linux线程同步有Mutex,spin lock,条件变量,rw lock等多种同步机制,InnoDB并没有直接使用系统的同步机制,而是自己定义了互斥结构数据结构kernel_mutex,将系统的spin lock,mutex,和条件变量融合一起

【Mysql】主机cpu 之-sys使用率过高

如图,kernel_mutexmutex对象的中重要的结构成员为os_event和lock_word。

  • kernel_mutex主要涉及mutex_create,mutex_enter,mutex_exit函数,会分别使用glibc的malloc()和free()调用动态分配和释放内存

  • 封装mutex和条件变量,图中绿色框区域
    MySQL线程之间发送异步信号来进行同步主要通过os_event_struct结构体中的os_mutex(封装os的pthread_mutex_t)和cond_var(封装os的pthread_cond_t)成员对象实现。当InnoDB在获取锁的时候,首先先努力自旋一段时间,如果超过innodb_sync_spin_loops的阈值,就会通过函数os_event_wait_low()在os_event_struct->cond_var上等待。如图,当某个线程释放了锁的时候,通过os_cond_broadcast尝试发送广播唤醒所有等待os_event_struct->cond_var条件变量的线程.这些线程被唤醒后又继续竞争争抢os_event_struct->os_mutex

  • spin lock,图中黄色框区域
    通过lock_word做spin wait。线程想要争抢锁的时候先判断这个值,如果lock_word为1就继续自旋等待。如果发现其他线程释放了锁该值变为0的时候,就通过test_and_set改为1,"告诉"其他线程这把锁被持有了

InnoDB这样设计的目的都是延缓线程被挂起并进入os wait的速度,因为每一次进入os wait等待被唤醒或者唤醒都会进行一次上下文切换.但是也只能是延缓,并不能阻止,如果持续恶化得不到环境,最后仍然会进入os的等待队列,将会产生大量的上下文切换。但是有两个问题:

  • kernel_mutex是个全局锁,保护事务,buffer pool,锁,等InnoDB存储引擎实现的大部分对象.当MySQL突然有大量访问,并发一旦非常高的时候,mutex冲突非常剧烈,此时临界区变得非常大,同时也会浪费cpu很多时间空转。所以这也解释了sys cpu大量消耗在自选空转中

  • 并且并发高的时候会频繁调用malloc()申请内存,而glibc本身的malloc()本书频繁调用系统mutex_lock()和unlock(),在多线程高并发场景下并且资源不足的场景下,也会造成系统各种mutex竞争严重。大量线程被挂起等待os pthread_cond_broadcast广播被唤醒,随之而来的是大量的上下文切换

通过dstat看到此时cpu每秒有近20W次的上下文切换,综上所述,sys cpu负载高主要以下:

  • (1)cpu内核态spin,大量线程cpu在内核态自旋等待

  • (2)系统上下文切换,又分为:

    • spin仍然失败的,最终进入os wait,调用pthread_cond_wait等待条件满足时被唤醒

    • malloc()频繁加减os mutex,且系统内存紧张


1.3继续观察内存分配使用的情况.
sar -B 看内存页回收,其中pgscank/s,对应kswapd回收,pgscand/s对应的MySQL线程直接回收
【Mysql】主机cpu 之-sys使用率过高

pgscand/s不为0,说明内存资源紧张,MySQL直接回收内存。

可是free命令看内存free并没有用光。经过一番调查发现是numa搞的鬼
用numactl --hardware命令看:

available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3node 0 size: 32733 MB
node 0 free: 1900 MB
node 1 cpus: 4 5 6 7node 1 size: 32768 MB
node 1 free: 20 MB
node distances:
node   0   1  0:  10  20  1:  20  10 

虽然内存整体free没有用光,但是在numa默认的内存分配机制下,内存使用严重不均,node0还十分充足,但是node1几乎用光

还可以使用strace来诊断!

https://huoding.com/2015/10/16/474


当前名称:【Mysql】主机cpu之-sys使用率过高
当前地址:http://myzitong.com/article/jihddg.html