基于准静态自适应环型缓存器(QSARC)的taskBus万兆吞吐实现

文章目录

    • 概要
    • 整体架构流程
    • 技术名词解释
    • 技术细节
      • [1. 数据结构](#1. 数据结构)
      • [2. 自适应计算队列大小](#2. 自适应计算队列大小)
      • [3. 生产者拼接缓存](#3. 生产者拼接缓存)
      • [4. 高效地通知消费者](#4. 高效地通知消费者)
    • 小结
      • [1. 性能表现情况](#1. 性能表现情况)
      • [2. 主要改进和局限](#2. 主要改进和局限)
      • [3. 源码和发行版](#3. 源码和发行版)

概要

准静态自适应环形缓存器(Quasi-Static Adaptive Ring Cache)是taskBus用于数据吞吐的软件结构。

  • 准静态:缓存器的大小并不是静态分配,而是随着吞吐需求的提高,缓慢增长,并最终适应最高峰时的内存消耗。当缓存器已经达峰后,不再有堆内存分配。
  • 自适应:根据包大小的不同,缓存器在恒定的最大峰值内存容积下,根据统计获得包的大小数据,决定环状缓存队列元素的个数、每个元素的大小。
  • 环形: 队列收尾相接形成环状,生产者、消费者使用两个时钟前后相随,时钟本身采用atomic保护,无需额外的锁。

使用该缓存器,基于增强管道数据流转技术(EPDR)的业余软线无线电平台taskBus可在Linux 系统 i7 6700K 主频 4GHz下达到3GBps(24Gbps)的总交换能力。该交换能力被各个通道均分,共同支撑taskBus平台按照工程的连接关系,把各个生产者产出的数据包及时、完整、有序地输送给消费者。尽管采用了本技术,但与采用内核层面的zero-copy函数进行管道直接交换的性能极限还差了20倍。

整体架构流程

taskBus的整体架构是一种多进程的合作机制,平台管理N个子进程,各个进程可以充当消费者和生产者的角色。平台收集各个子进程的stdout输出,并按照用户给定的消费关系,送入消费者的stdout.在这样的整体架构下,数据流转流程如下:
stdout stdin stdin stdin stdout 生产者1 平台 QSARC 消费者1 消费者2 消费者2 生产者2

在202409版本之前,taskBus使用的是消费者队列。由1个生产者产出的数据,会复制N份进入各个消费者的队列。这种情况下,平台既要为生产者部位保留一个用于包拼接的缓存,又要做N次memcpy。在消费者显著多于生产者时,吞吐能力下降的很厉害。

202409版本之后,设计成每份包只有唯一的1个副本,存储在生产者队列。消费者根据索引去拉取:

  • 平台为每个生产者维护1个环状缓存队列。
  • 平台按照消费关系,把每个包的队列位置索引播发给各个消费者。
  • 播发时,会维护一个待消费计数器,将值加1
  • 消费者消费包后,会将计数器的值减1
  • 如果生产者队列绕了一圈,发现下一个位置的计数器不为0,说明消费的速度赶不上生产速度,此时平台不再接受生产者的数据,等待。

整个流程如下图所示(动图):

注意的是,上图中队列的大小是4个包,即使包消费完毕,可用的容积也不会释放,这样,随着程序的运行,渐渐地动态内存分配会越来越少,速度会越来越快。当然,如果包长是固定的,则不存在此问题,可以提前全部分配。

值得注意的是,在时钟11时,因为下一个位置依旧有消费者在驻留,因此生产被暂停等待。这种架构的缺点是整体的吞吐能力存在"木桶效应",即由消费最慢的消费者决定1秒内能够流转多少包。

技术名词解释

  • 包:用于一次功能操作的数据单位,可以理解为1段连续内存的数据。包由包头、数据段组成。包头含有长度指示,正常的数据包之间是紧密衔接的。
  • 时钟:用于控制生产、消费的整形变量,从0开始无限增长。每处理1个包,时钟会加1。
  • 当前位置:生产者、消费者操作队列的当前位置,数值= 时钟 % 队列大小。

技术细节

1. 数据结构

生产者为taskNode类型,拥有如下成员变量维护自己的生产队列:

cpp 复制代码
QVector<int> m_status_stdin;
QVector<QByteArray> m_array_stdin;
QVector<qsizetype> m_size_stdin;
QVector<QAtomicInteger<qsizetype> > m_cnt_stdin;

变量1 控制生产的状态。管道到来的数据,是一个无限有序无损流,类似TCP。但是,每次流可能会被切断,导致包头、数据块可能被切割到多次调用里。这个变量用于在各次调用中记忆上次的生产状态。

变量2 就是缓存的内存本身。这个列表的QByteArray元素个数是缓存的包个数,每个QByteArray会保持在历史最大包的高位。这样,只有到来的包大于当前体积时,才会重新分配内存。

变量3 存储缓存内当前的写入位置。如果包已经写完了,则等于包长。如果是空闲,则为0。

变量4 就是待消费计数器,每次生产完毕1个包,会根据消费者等待队列广播包的索引(时钟),并把计数设置为消费者个数。消费者消费完,会减一。

2. 自适应计算队列大小

这种队列存在1个重大的问题,就是很难控制内存的用量。由于各个QByteArray都只增加不释放,因此期望的用量是:

C = M ∗ N C = M * N C=M∗N

M是最大包大小,N是队列包个数。

由于taskBus设计时,建议包的大小小于64KB,在假设包的种类小于K时,可以预先统计前K个包的最大长度M,从而确定按照最大内存门限,如C=128MB,要设置的N。

N = C / M N = C/M N=C/M

当然,这种算法是极为简陋的。这是建立在taskBus的具体应用场景上的。对包变化幅度很大、无法简单统计的情况,要考虑一定的shink策略,如在每次消费指针归0时,裁剪队列的大小,并释放尾部的内存。

cpp 复制代码
//Adjust buf size
			if (m_pos_stdin==8)
			{
				qsizetype sza = 0;
				for (int ia = 0;ia<8;++ia)
					if (sza < m_size_stdin[ia])
						sza = m_size_stdin[ia];
				if (sza < 32)
					sza = 32;
				m_bufsize_adjust = taskCell::default_ringcache * 1024 * 1024 / sza;
				if (m_bufsize_adjust > m_bufsize_stdin)
					m_bufsize_adjust = m_bufsize_stdin;
				if (m_bufsize_adjust < 8)
					m_bufsize_adjust = 8;
				emit_message(QString("Adjusted buffer ring size : %1 MB / %2 Bytes = %3 frames.").arg(taskCell::default_ringcache).arg(sza).arg(m_bufsize_adjust).toUtf8());
			}

3. 生产者拼接缓存

在当前生产位置上,平台为生产者拼接一个完整的包。这里用到了状态机。状态机拥有如下状态:

状态名 取值 意义
头部捕获中 0 正在捕获头部
数据缓存中 1 正在根据头部指示的状态,缓存数据
数据缓存完毕 2 包接收完整,触发消费。
数据缓存完毕 3 触发消费完毕,待回收。

在每个状态上,都会进行进程管道读操作,不断的从stdout获取数据。直到状态2,会触发消费,并在全部消费通知播发后,进入状态3。当下一次生产者访问状态3的队列成员时,如果没有消费者还在消费这个包,则会把包位置归零,状态归零。否则,会阻塞生产者,直到消费者消费完毕为止。

cpp 复制代码
void taskNode::slot_readyReadStandardOutput()
{
	LOG_PROFILE("IO","Start Recieving packs.");
	qsizetype total_sz = m_process->size();
	int badHeader = 0;
	while (total_sz)
	{
		const qsizetype pos = m_pos_stdin % m_bufsize_adjust;
		QByteArray & curr_array = m_array_stdin[pos];
		qsizetype & readBufMax = m_size_stdin[pos];
		QAtomicInteger<qsizetype> & cnt = m_cnt_stdin[pos];
		int & stat = m_status_stdin[pos];
		//生产者被阻塞了,因为下一个缓存位置依旧有消费者在消费数据。
		if (cnt>0)
			break;
		//Old data
		if (stat==3)
		{
			readBufMax = 0;
			stat = 0;
		}
		auto * header =	reinterpret_cast<const TASKBUS::subject_package_header *>  (curr_array.data());
		//Header
		if (stat==0)
		{
			if (total_sz<sizeof(TASKBUS::subject_package_header))
				break;
			auto needRead = sizeof(TASKBUS::subject_package_header) - readBufMax ;
			auto red = m_process->read(curr_array.data()+readBufMax,needRead);
			readBufMax += red;
			if (readBufMax == sizeof(TASKBUS::subject_package_header))
			{
				if (header->prefix[0]==0x3C && header->prefix[1]==0x5A &&	header->prefix[2]==0x7E && header->prefix[3]==0x69)
				{
					stat = 1;
				}
				else
				{
					++badHeader;
					readBufMax = 0;
				}
			}
			Q_ASSERT(readBufMax <= sizeof(TASKBUS::subject_package_header));
		}
		//data
		if (stat==1)
		{
			const qsizetype packAllSize = sizeof(TASKBUS::subject_package_header)+header->data_length;
			if (curr_array.size()<packAllSize)
			{
				curr_array.resize(packAllSize);
				header = reinterpret_cast<const TASKBUS::subject_package_header *>  (curr_array.data());
			}
			auto needRead = packAllSize - readBufMax ;
			auto red = m_process->read(curr_array.data()+readBufMax,needRead);
			readBufMax += red;
			if (readBufMax==packAllSize)
			{
				stat = 2;
			}
			Q_ASSERT(readBufMax <= packAllSize);
		}

		//Send
		if (stat==2)
		{
			const qsizetype pack_size = sizeof(TASKBUS::subject_package_header)+header->data_length;
			extern QAtomicInteger<quint64>  g_totalrev;
			g_totalrev += readBufMax;
			++m_spackage_sent;
			m_sbytes_sent += sizeof(TASKBUS::subject_package_header)+header->data_length;
			if (header->subject_id == TB_SUBJECT_CMD)
			{
				//Command must endwith \0
				const char * pCmd = (const char *)header+sizeof(TASKBUS::subject_package_header);
				QString cmd = QString::fromUtf8(pCmd,header->data_length);
				QMap<QString, QVariant> map_z = taskCell::string_to_map(cmd);
				//remember uuid
				if (map_z.contains("source"))
				{
					if(m_uuid.size()==0 )
						m_uuid = map_z["source"].toString();
					if (map_z.contains("destin"))
						emit sig_new_command(map_z);
				}
			}
			else if (m_currPrj)
				m_currPrj->routing_new_package(this,pos);
			if (m_bDebug)
				log_package(true,(char *)header,pack_size);
			stat = 3;
			++m_pos_stdin;
			//Adjust buf size
			if (m_pos_stdin==8)
			{
				qsizetype sza = 0;
				for (int ia = 0;ia<8;++ia)
					if (sza < m_size_stdin[ia])
						sza = m_size_stdin[ia];
				if (sza < 32)
					sza = 32;
				m_bufsize_adjust = taskCell::default_ringcache * 1024 * 1024 / sza;
				if (m_bufsize_adjust > m_bufsize_stdin)
					m_bufsize_adjust = m_bufsize_stdin;
				if (m_bufsize_adjust < 8)
					m_bufsize_adjust = 8;
				emit_message(QString("Adjusted buffer ring size : %1 MB / %2 Bytes = %3 frames.").arg(taskCell::default_ringcache).arg(sza).arg(m_bufsize_adjust).toUtf8());
			}
		}
		total_sz = m_process->size();
	}

	if (badHeader)
		emit_message(QByteArray("Error header recieved. "
								"Header must be 0x3C, 0x5A, 0x7E,"
								" 0x69. Aborting."));
	LOG_PROFILE("IO","End Recieving packs.");
}

4. 高效地通知消费者

如果每个包很小,则QEvent触发的密度会很大,开销很大。我们设置一个消费者的索引队列,存储待消费的生产者队列、索引:

cpp 复制代码
	QMutex m_mtx_queue;
	QList<taskNode *> m_write_queue;
	QList<qsizetype> m_write_pos;

而后,只在队列为0时,触发Event。

cpp 复制代码
bool taskNode::enqueue_write(taskNode * node, qsizetype pos)
{
	m_mtx_queue.lock();
	int z = m_write_queue.size() + m_write_cmd.size();
	m_write_queue.push_back( node);
	m_write_pos.push_back(pos);
	m_mtx_queue.unlock();
	if (!z)
	{
		QCoreApplication::postEvent(this,new QEvent(m_nPackEvent));
	}
	return  true;
}

同时,在消费时,一次性获取队列,并清空。这样减少锁的碰撞。

cpp 复制代码
void taskNode::flush_write()
{
	m_mtx_queue.lock();
	QList<taskNode *> write_queue = m_write_queue;
	QList<qsizetype> write_pos = m_write_pos;
	QByteArrayList write_cmd = m_write_cmd;
	m_write_queue.clear();
	m_write_pos.clear();
	m_write_cmd.clear();
	//qDebug()<<write_queue.size();
	m_mtx_queue.unlock();

	while (write_queue.size())
	{
		taskNode * node = write_queue.first();
		qsizetype pos = write_pos.first();

		write_queue.pop_front();
		write_pos.pop_front();

		QByteArray & arr = node->get_stdin_array(pos);
		m_process->write(arr.constData(),sz);
		--cnt;
	}

小结

尽管采用了环形队列,由于在QProcess上还是存在mem-alloc,这使得峰值状态下CPU占用还是很大的。整体速率距离PCI总线和DDR4的能力还相去甚远,即使和bash直接管道连接相比,也有不小的差距。不过,为了构造灵活的管道吞吐能力,允许数据被多对多流转和反馈回环,损失一些性能也差强人意。

1. 性能表现情况

通过上述操作,taskBus的吞吐能力得到了保证,在只使用用户态的内存操作情况下,缓存64MB时,可以获得10Gbps以上的性能。在Linux下,可达 24Gbps,即3GBps^1^。

平台 系统 峰值吞吐 单路流量 平均来回延迟
i7-10700U^[1](#平台 系统 峰值吞吐 单路流量 平均来回延迟 i7-10700U1 Linux x64 3354MBps 1340MBps 1ms i7-6700K Linux x64 2844MBps 1050MBps 2.2ms i7-10700U2 win10 home x64 1561MBps 400MBps 22ms i7-6700K win10 home x64 1345MBps 340MBps 40ms RaspberryPi 4(8GB) Rasbain 64 263MBps 102MBps 6ms)^ Linux x64 3354MBps 1340MBps 1ms
i7-6700K Linux x64 2844MBps 1050MBps 2.2ms
i7-10700U^[2](#平台 系统 峰值吞吐 单路流量 平均来回延迟 i7-10700U1 Linux x64 3354MBps 1340MBps 1ms i7-6700K Linux x64 2844MBps 1050MBps 2.2ms i7-10700U2 win10 home x64 1561MBps 400MBps 22ms i7-6700K win10 home x64 1345MBps 340MBps 40ms RaspberryPi 4(8GB) Rasbain 64 263MBps 102MBps 6ms)^ win10 home x64 1561MBps 400MBps 22ms
i7-6700K win10 home x64 1345MBps 340MBps 40ms
RaspberryPi 4(8GB) Rasbain 64 263MBps 102MBps 6ms

上表是运行双进程点对点双向PING的状态下达到的。多进程下,总速率会稍高。可以发现,同样的硬件配置下:

  • windows下taskBus的吞吐能力要比Linux少1倍
  • windows下taskBus的带宽利用率要低于Linux,总速率/单路速率Linux更优。
  • windows下的延迟更大。

这是非常奇怪的现象,讲起来windows应该更快才对。对于里面的细节原因,只有后面慢慢研究了。

2. 主要改进和局限

与2024年8月版本相比,少了一层生产者-->消费者的memcpy,转而只是传递int类型的索引,在生产者:消费者个数=1:N的情况下,吞吐能力会得到较大提高。这种memcpy次数的降低,对于老旧CPU影响更大,即使在2进程互PING(1:1)的测试中,也能达到 20-30%的提速。

同时要注意到,3GBps已经很接近用户态内存的吞吐极限。若要追求极为苛刻的传输,需要按照文章开始的链接里的vmsplice zero-copy来定制,取得额外10-20倍的性能提升。

3. 源码和发行版

源码和发行版参考

GitCode.net

或者

GitCode.com


  1. i7-10700U是一个笔记本上的低功耗cpu,在最大睿频4GHz下的Manjaro Linux系统上,3GBps持续了5秒。由于温度上升,温度墙导致频率下降到1.8GHz,速度降低1倍。 ↩︎ ↩︎

  2. i7-10700U是一个笔记本上的低功耗cpu,通过在windows-10下去除温度墙,可以在97摄氏度的高温状态下,保持在4GHz,维持1.5GBps的流量。 ↩︎

相关推荐
亿牛云爬虫专家3 天前
动态与静态网站抓取的区别:从抓取策略到性能优化
爬虫·爬虫代理·网站·代理ip·抓取·动态·静态
HKJ_numb115 天前
Linux 常用命令
linux·常用命令·管道
胜天半月子16 天前
Scrapy | Scrapy框架中管道的使用
数据库·python·scrapy·管道
无双@1 个月前
Linux操作系统小项目——实现《进程池》
linux·操作系统·进程·管道·大作业·作业·操作系统项目
w_outlier1 个月前
进程间通信(一)【管道通信(下)】
linux·进程·通信·管道
小明学C++2 个月前
Linux命令分享 三 (ubuntu 16.04)
linux·服务器·管道·重定向·linux常用命令·linux打包解包压缩解压文件·linux查看进程
Amd7942 个月前
使用 nuxi generate 进行预渲染和部署
html·部署·nuxt·性能·安全性·预渲染·静态