关于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性能监控工具