关于find_busiest_group函数提现出的Linux性能问题

最近在查一个pgoneproxy的性能问题，发现当pgoneproxy与postgresql数据库部署到一台主机上面的时候，通过perf top可以看到find_busiest_group函数占有很大的比例，而当pgoneproxy和postgresql部署到不同的机器上面的时候此函数则不出现。初步分析应该是某些资源不足导致的。

为了弄清楚这个问题，首先的搞清楚find_busiest_group这个函数的作用，根据参考文献1）和2）了解到这个函数是与多核cpu的负载均衡有关系，及当有大量任务的时候分布不均的话那么此函数会被调用。那么通过查看cpu的负载均衡情况，发现具有如下的信息：



其中load average的平均15分钟的负载情况是37.58.由于我的主机是16逻辑CPU的，平均一个是2.34。这个cpu的队列长队比较长了。按照网络上各位的说法有0.7的，也有2的。现在是2.34肯定是超负载了。故当某个cpu的负载稍轻松点，那么cpu将会通过find_busiest_group查找最繁忙的cpu队列，把一部分进程移到轻松的cpu队列中。

这种情况下，最好是把pgoneproxy与postgresql数据库部署到不同的主机上面来解决cpu负载的问题。

在通过atop工具，可以查看到在进行大量的写操作，见下图的黑体部分：



查看上图中的进程信息，可以看到postgres在进行大量的写磁盘操作。从而导致整个cpu的利用率不高（通过top观察）。

参考文献：

1）linux在多核处理器上的负载均衡原理

2）多处理器运行队列的平衡

3）Linux Scheduling Domains

4）你值得拥有：25个Linux性能监控工具