1.1使用pstack看 MySQL所有线程的调用栈:
我们知道linux线程同步有Mutex,spin lock,条件变量,rw lock等多种同步机制，InnoDB并没有直接使用系统的同步机制，而是自己定义了互斥结构数据结构kernel_mutex,将系统的spin lock,mutex,和条件变量融合一起
如图,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，且系统内存紧张
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来诊断！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
