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

丁劲犇2024-09-12 9:31

文章目录

    • 概要
    • 整体架构流程
    • 技术名词解释
    • 技术细节
      • [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的流量。 ↩︎

相关推荐
小明学C++8 天前
Linux命令分享 三 （ubuntu 16.04）
linux·服务器·管道·重定向·linux常用命令·linux打包解包压缩解压文件·linux查看进程
Amd79416 天前
使用 nuxi generate 进行预渲染和部署
html·部署·nuxt·性能·安全性·预渲染·静态
Oflycomm1 个月前
QCA2066 Linux下5g 6g自适应测试方法
linux·wifi·自适应·qca2066·wifi6e
菜鸟小码2 个月前
Redis基础教程（十八）：Redis管道技术
redis·管道
efls1113 个月前
Linux_管道通信
linux·运维·服务器·管道
仙魁XAN4 个月前
Python 机器学习 基础 之 算法链与管道 【算法链与管道/预处理进行参数选择/构建管道/在网格搜索中使用管道】的简单说明
python·机器学习·管道·网格搜索·算法链
Anakki4 个月前
【MySQL精通之路】InnoDB-内存结构-自适应哈希索引
数据库·mysql·hash·索引·自适应
YIOUTH4 个月前
【进程间通信】管道如何实现全双工，原理与实践
linux·服务器·操作系统·管道·全双工
热门推荐
01RAG 实践- Ollama+RagFlow 部署本地知识库02组基轨迹建模 GBTM的介绍与实现（Stata 或 R）032024年高教社杯数学建模国赛C题超详细解题思路分析04yolov8实战第五天——yolov8+ffmpg实时视频流检测并进行实时推流——（推流，保姆教学）05苍穹外卖面试总结06【2024数模国赛赛题思路公开】国赛B题思路丨附可运行代码丨无偿自提07浏览器插件——ModHeader 的分享和学习08Coze扣子平台完整体验和实践（附国内和国际版对比）09【2024高教社杯全国大学生数学建模竞赛】B题 生产过程中的决策问题——解题思路 代码 论文10CCF-CSP认证考试 202406-3 文本分词 100分题解