Postgresql CPU相关性能问题分析

在项目中，极可能会遇到CPU使用率过多。在跑测试过程当中，不少人若是发现了CPU不够用怎么办？现分享出本身的性能分析思路。

      首先仍是多唠叨几句CPU相关的话题吧。CPU自己是熟悉计算机系统的硬件之一，从字面意思上应该也能想到其重要程度。能够简单地把CPU干活理解为“处理数据”，那么数据从哪里来？仍是简单起见（这里不是很严谨，可是为了理解上的方便），能够理解为从磁盘和内存。好比更改“数据库某行上的某个字段上值，首先把磁盘上存储内容读到内存中，处理完以后，更新过的数据存放在内存中，最后再写回到磁盘中。这其中涉及到CPU,内存，磁盘。其实从全局的角度看，还包含操做系统（文件系统，磁盘IO等），网络IO等。

      因此，1> 从以上你能够发现和CPU问题相关的介质或组件其实有不少，可是遇到CPU的问题，咱们仍是优先想到，内存是否是也不够了。这种想法是对的。由于从上一段落的分析能够看到：数据存放到内存和数据存放到磁盘，对效率的影响是蛮大的。即便你用的是SSD,这种速度上的差异也是差多少个数量级。因此有多是内存也已经用完了，致使SQL执行效率不高。能够考虑增大内存分配，再进行测试验证。
      2> CPU在等待磁盘IO，或者磁盘IO比较忙，怎么去判断磁盘IO是否是繁忙呢？能够经过以下命令，直接获取，看最磁盘适用率，若是接近100%，证实是比较繁忙，能够进一步深刻问题，能不能使用数据库cache，或者将这部分逻辑的后台迁移到memory store类型的存储介质中，如redis等。避免此部分的业务逻辑形成瓶颈。

iostat -d -x -k 1

3> 线程资源争抢，须要分析线程相关log。若是发现现场死锁，无论是锁在对象资源仍是数据库资源，都须要优先修复。若是出现共享资源争抢，那么这部分逻辑的后台，最好不要放在关系型数据库中。

你们也能够扫描并关注以下公众号“TimTest”，会有更多性能测试相关内容分享。