记录一次线上pthread_cond_broadcast引发的性能问题

最新推荐文章于 2022-09-01 16:13:47 发布

Sweet_Oranges

最新推荐文章于 2022-09-01 16:13:47 发布

阅读量639

点赞数

分类专栏： c

本文链接：https://blog.csdn.net/Sweet_Oranges/article/details/108142647

版权

本文记录了一次由于使用pthread_cond_broadcast引发的线上性能问题。在多进程消息队列的pub sub模型中，广播操作导致消费者对锁的激烈竞争，从而影响生产者写入速度。通过测试验证了问题，并提出解决方案：由单独线程负责唤醒，生产者改为使用sem_post，有效提高了系统性能。

摘要由CSDN通过智能技术生成

前言

pthread_mutex 和 pthread_cond_broadcast是在多线程编程中必不可少的一个工具，其底层采用了futex实现，能够在用户态解决大部分的锁竞争，其性能是非常高效的。

背景

最近上线的一个多进程间消息队列就采用了pthread_mutex_lock和pthread_cond_t来实现pub sub模型。生产者在写入消息的时候，调用pthread_cond_broadcast来唤醒消费者。本来以为这样很完美，在测试环境也没有测出什么问题。

然而上线后上游直接报ring buffer full，定位出下游接收数据端也就是我们这边的生产者qps不够导致的，测试环境测试生产者每秒写入800w应该是没有问题的，上游qps最多也就100w怎么会有性能问题呢？

定位

经过仔细阅读代码，推测可能是在pthread_cond_broadcast的时候有一把互斥锁来保护条件，消费者对这把锁竞争太激烈，导致生产者写入数据时迟迟获取不到锁，导致qps直线下降。

写个demo测试，通过测试不同的线程数总耗时来观察是否存在这个问题。

#include <thread>
#include <pthread.h>
#include <unistd.h>
#include <sys/time.h>

pthread_mutex_t mutex_;
pthread_cond_t pcond_;

bool ready = false;


void waiter() {
        while(true) {
                pthread_mutex_lock(&mutex_);
                pthread_cond_wait(&am