目 录1 概述................................................................................................................................................... 11.1 内容简介........................................................................................................................................................................ 11.2 写作目的........................................................................................................................................................................ 11.3 面向读者........................................................................................................................................................................ 11.4 修订记录........................................................................................................................................................................ 12 芯片介绍........................................................................................................................................... 22.1 Ascend 310 的内存带宽................................................................................................................................................ 22.2 Ascend 310 的内存........................................................................................................................................................ 22.3 Ascend 310 的功耗........................................................................................................................................................ 22.4 Ascend 310 的LPDDR4x 位宽..................................................................................................................................... 32.5 Ascend 310 的主频........................................................................................................................................................ 33 Matrix...............................................................................................................................................43.1 数据类型序列化与反序列化........................................................................................................................................ 43.2 Graph 对应关系............................................................................................................................................................. 53.3 GraphID 参数约束......................................................................................................................................................... 53.4 Graph 创建实例............................................................................................................................................................. 53.5 Graph 流程执行............................................................................................................................................................. 53.6 Enigne 创建port............................................................................................................................................................ 53.7 Engine 配置参数............................................................................................................................................................53.8 Engine 创建线程............................................................................................................................................................63.9 Engine 通信方式............................................................................................................................................................63.10 Engine 消息触发方式..................................................................................................................................................63.11 Engine 间数据收发机制.............................................................................................................................................. 63.12 Engine 线程调度..........................................................................................................................................................73.13 Device 侧守护进程......................................................................................................................................................73.14 Matrix 传输机制.......................................................................................................................................................... 73.15 多芯片使用.................................................................................................................................................................. 83.16 多路视频解码Engine 实现.........................................................................................................................................84 DVPP................................................................................................................................................94.1 VdecCtrl 调用方式.........................................................................................................................................................94.2 DvppCtrl 创建................................................................................................................................................................ 94.3 HFBC 数据说明.............................................................................................................................................................94.4 数据空间大小说明...................................................................................................................................................... 104.5 VDEC 回调说明.......................................................................................................................................................... 104.6 VDEC 多路实现.......................................................................................................................................................... 104.7 DVPP 功能实现........................................................................................................................................................... 104.8 VPC 功能实现............................................................................................................................................................. 104.9 VENC 输出帧说明...................................................................................................................................................... 104.10 VENC 回调说明.........................................................................................................................................................114.11 DVPP 使用异常......................................................................................................................................................... 115 ModelManage.............................................................................................................................. 125.1 模型图形化.................................................................................................................................................................. 125.2 模型输入数据类型...................................................................................................................................................... 125.3 数据输入大小与模型要求大小不匹配...................................................................................................................... 125.4 TensorFlow 模型转换.................................................................................................................................................. 135.5 模型的算子精度.......................................................................................................................................................... 135.6 模型多batchsize 处理................................................................................................................................................. 135.7 模型输出节点.............................................................................................................................................................. 145.8 模型输出格式.............................................................................................................................................................. 145.9 模型转换异常.............................................................................................................................................................. 146 AIPP................................................................................................................................................156.1 AIPP 配置参数.............................................................................................................................................................156.2 AIPP 抠图功能.............................................................................................................................................................156.3 AIPP 色域转换.............................................................................................................................................................15

目 录1 概述................................................................................................................................................... 11.1 内容简介........................................................................................................................................................................ 11.2 写作目的........................................................................................................................................................................ 11.3 面向读者........................................................................................................................................................................ 11.4 修订记录........................................................................................................................................................................ 12 芯片介绍........................................................................................................................................... 22.1 Ascend 310 的内存带宽................................................................................................................................................ 22.2 Ascend 310 的内存........................................................................................................................................................ 22.3 Ascend 310 的功耗........................................................................................................................................................ 22.4 Ascend 310 的LPDDR4x 位宽..................................................................................................................................... 32.5 Ascend 310 的主频........................................................................................................................................................ 33 Matrix...............................................................................................................................................43.1 数据类型序列化与反序列化........................................................................................................................................ 43.2 Graph 对应关系............................................................................................................................................................. 53.3 GraphID 参数约束......................................................................................................................................................... 53.4 Graph 创建实例............................................................................................................................................................. 53.5 Graph 流程执行............................................................................................................................................................. 53.6 Enigne 创建port............................................................................................................................................................ 53.7 Engine 配置参数............................................................................................................................................................53.8 Engine 创建线程............................................................................................................................................................63.9 Engine 通信方式............................................................................................................................................................63.10 Engine 消息触发方式..................................................................................................................................................63.11 Engine 间数据收发机制.............................................................................................................................................. 63.12 Engine 线程调度..........................................................................................................................................................73.13 Device 侧守护进程......................................................................................................................................................73.14 Matrix 传输机制.......................................................................................................................................................... 73.15 多芯片使用.................................................................................................................................................................. 83.16 多路视频解码Engine 实现.........................................................................................................................................84 DVPP................................................................................................................................................94.1 VdecCtrl 调用方式.........................................................................................................................................................94.2 DvppCtrl 创建................................................................................................................................................................ 94.3 HFBC 数据说明.............................................................................................................................................................94.4 数据空间大小说明...................................................................................................................................................... 104.5 VDEC 回调说明.......................................................................................................................................................... 104.6 VDEC 多路实现.......................................................................................................................................................... 104.7 DVPP 功能实现........................................................................................................................................................... 104.8 VPC 功能实现............................................................................................................................................................. 104.9 VENC 输出帧说明...................................................................................................................................................... 104.10 VENC 回调说明.........................................................................................................................................................114.11 DVPP 使用异常......................................................................................................................................................... 115 ModelManage.............................................................................................................................. 125.1 模型图形化.................................................................................................................................................................. 125.2 模型输入数据类型...................................................................................................................................................... 125.3 数据输入大小与模型要求大小不匹配...................................................................................................................... 125.4 TensorFlow 模型转换.................................................................................................................................................. 135.5 模型的算子精度.......................................................................................................................................................... 135.6 模型多batchsize 处理................................................................................................................................................. 135.7 模型输出节点.............................................................................................................................................................. 145.8 模型输出格式.............................................................................................................................................................. 145.9 模型转换异常.............................................................................................................................................................. 146 AIPP................................................................................................................................................156.1 AIPP 配置参数.............................................................................................................................................................156.2 AIPP 抠图功能.............................................................................................................................................................156.3 AIPP 色域转换.............................................................................................................................................................15

在使用Atlas500进行推理时，发现引擎内部的队列没起作用，都是push一条数据，pop一条数据，这样两个模型串联，单线程的话速度较慢，直接修改引擎的thread_num程序不报错，但是运行会自动中断，请问有什么好的启用多线程的方法吗？

修改引擎对应的thread_num值的作用？？？在Atlas200DK上运行模型推理，使用两个模型串行。从流程打印出的日志看出，数据是一条一条的顺序处理的，速度比较慢想问下如何让程序并行处理多条数据呢？

【云管理网络线上课堂】“一课在手，上线无忧”——我的云AP为什么上不了线 1      查看云管理侧事件日志进入设计-设备管理页面：单击设备，进入单设备详情页面：单击进入事件日志页面，就可以看到设备离线的原因（最近5次）和设备上线失败的原因（最近5次）：查看上下线日志,过滤配置通道，可以查看详细的上下线情况：如何是设备主动断开，可能的原因一般是网络有中断或者是AP设备掉电等原因。具体可以登录AP设备查看相关信息。这种情况请排查网络情况。参考链接如下：http://support.huawei.com/onlinetoolsweb/ptmngsys/Web/tsrev_s/cn/content/s/index.html2   查看AP侧日志信息2.1 display cloud-mng info命令用来查看当前设备配置的CloudCampus@AC-Campus信息。2.2  display cloud-mng offline-record命令用来查看设备最近10次下线记录信息。2.3 display cloud-mng offline-record diagnostic-information显示设备最近10次下线的原因表1 常见设备重启原因常见设备重启原因解释处理建议Reset for others其他原因。联系技术支持人员。Reset by user command执行重启设备的命令。无需处理。Np initialize failedNP启动失败。联系技术支持人员。Startup np overtimeNP启动超时。联系技术支持人员。Reset for memory use out内存耗尽。检查内存占用情况。Reset by ac command resetAC下发命令重启AP成功。无需处理。Reset for power off设备断电。无需处理。Reset for kernel panic内核KP重启。联系技术支持人员。Reset for switch zone after update versionAP升级主备区切换重启。无需处理。Reset for update version successAP升级成功重启。无需处理。Reset for update version failedAP升级失败重启。检查AP升级失败原因。Reset for exceptionVOS异常信号重启。联系技术支持人员。Reset for watchdog看门狗异常重启。联系技术支持人员。Reset for cpld写CPLD寄存器重启。联系技术支持人员。Reset for reset-key按设备的复位按钮重启。无需处理。Reset for the radio type is different from that specified by the configuration file射频类型与配置文件不一致。无需处理。Reset for the radio type is changed射频类型被修改。无需处理。Reset for 11ac target chip abnormalWIFI芯片固件异常。联系技术支持人员。Reset for tx dma stopTX DMA停止，发包异常。联系技术支持人员。Reset for restoration to factory defaults(by command)通过命令恢复出厂配置。无需处理。Reset for MFPI detect MSC module abnormalMFPI监控到MSC模块异常。联系技术支持人员。Reset for MFPI detect MSU module abnormalMFPI监控到MSU模块异常。联系技术支持人员。Reset for MFPI detect KAP module abnormalMFPI监控到KAP模块异常。联系技术支持人员。Reset for configuration synchronization command重启以同步配置。配置同步场景，主备公有配置不一致，通过手动方式同步，根据重启提示确认重启。无需处理。Reset for auto configuration synchronization重启以同步配置。配置同步场景，主备公有配置不一致，自动同步后，根据重启提示确认重启。无需处理。Reset for a country code change变更国家码。无需处理。Reset for an AP MAC or SN change变更AP的MAC或SN。无需处理。Reset for an AP upgradeAP升级重启。无需处理。Reset for the ap-reset command执行重启AP的命令。无需处理。Reset for the undo ap command执行删除AP的命令。无需处理。Reset for license expirationLicense过期。购买并激活License。Reset for the AP added to the blacklistAP被加入黑名单。无需处理。Reset for the CAPWAP link and AP status mismatchAP状态与CAPWAP链路状态不一致。无需处理。Reset for a DTLS configuration change变更DTLS开关。无需处理。Reset for a CAPWAP link faultCAPWAP链路状态不正常。无需处理。Reset for restoration to factory defaults恢复出厂配置。无需处理。Reset for a dual-link backup switch changeAC双链路备份切换。无需处理。Reset for the ap-rename command下发修改AP名称的命令。无需处理。Reset for the ap-regroup command下发修改AP组的命令。无需处理。Reset for an AP conflict state changeAP状态冲突。无需处理。Reset for an AP management VLAN changeAP的管理VLAN变更。无需处理。Reset for commands in the provision-ap view下发AP上线参数的命令。无需处理。Reset for a country code mismatch不支持的国家码。检查国家码配置。Reset for a central AP type change中心AP类型发生变化。无需处理。Reset for AP deleted by controllerAP被AC删除。无需处理。Reset for abnormal network port self-healing网口异常自愈。检查网口。Reset for the radio type mismatch between the AP and ACAC和AP间射频类型不匹配。无需处理。Reset for batch deleteHSB批量删除。无需处理。Reset for the DTLS configuration change of the data link数据链路DTLS配置变更。无需处理。Reset for the AC IP address list change修改AC IP地址列表。无需处理。Reset for the address mode change修改地址模式配置。无需处理。Reset for the IP address change修改IP地址配置。无需处理。Reset for AP self-healing (The AP is not online on the AC for consecutive 24 hours)AP连续24小时未上线自愈重启。检查AP上线失败原因。Reset for a channel set switching室外AP加载室内国家码信道集配置。无需处理。Reset for the online configuration switching误配置导致设备离线，自恢复重启。无需处理。Reset for slow task switching系统运行慢导致的重启。检查内存占用情况。Reset for restoration to factory defaults(by button)通过复位按钮恢复出厂设置。无需处理。Reset for a configuration delivery failure配置下发失败。检查配置下发失败原因。Reset for MFPI detect CAP PBUF use outMFPI监控到转发PBUF耗尽。联系技术支持人员。Reset for abnormal wifi txrx self-healingWIFI驱动侧收发包长时间异常。联系技术支持人员。Reset for exception(redis-server exit)Redis-server进程异常退出。联系技术支持人员。Reset for exception(confd exit)Confd进程异常退出。联系技术支持人员。Reset for exception(callhome exit)Callhome进程异常退出。联系技术支持人员。Reset for an abnormal process进程异常。联系技术支持人员。Reset for a smart upgrade智能升级重启。无需处理。Reset for the branch group of AP change修改AP分支组。无需处理。Reset for the AC license expiresAC上License过期。购买并激活License。Reset for the AC port mode change between 40GE and XGEAC端口模式在40GE和XGE之间切换。无需处理。Reset for AP self-healing (The AP is not online for consecutive 24 hours)AP连续24小时未上线自愈重启。检查AP上线失败原因。Reset for the version rollback because the AP does not go online after the online upgrade在线升级后AP未上线回退版本重启。检查AP上线失败原因。2.4 display cloud-mng online-fail-record命令用来查看设备最近5次上线失败记录信息。display cloud-mng online-fail-record diagnostic-information显示设备最近5次上线失败的原因。表1 上线失败原因上线失败原因解释处理建议AP can't obtain address设备无法获取IP请检查DHCP服务器，确保设备能获取IP地址。Connect to confd failedconfd进程异常请联系技术支持人员进行具体定位。DNS failed设备无法通过DNS解析控制器地址请检查DNS服务器，确保设备能正确解析到云管理平台的IP地址。Connect to controller failed连接控制器失败请检查网络连通性和端口，确保设备能正常访问云管理平台的10020端口。Could not load host key证书加载失败请联系技术支持人员进行具体定位。Register Fail: Internal error, the controller is not already控制器未启动完成，或者正在获取当前部署场景请联系云管理平台系统管理员，确认云管理平台运行正常。Register Fail: Get the device's information timeout or the device returns fail控制器获取设备信息失败请联系技术支持人员进行具体定位。Register Fail: Illegal device's information format设备上报的信息格式有误请联系技术支持人员进行具体定位。Register Fail: The device is not added to the controller设备的ESN未添加到控制器请将设备的ESN添加到云管理平台的站点中。Register Fail: License is not authorized or expiredLicense未授权或过期请确保云管理平台上的License资源充足。Register Fail: Distribution controller node failure控制器节点分配失败请联系技术支持人员进行具体定位。Register Fail: The device unreports device models设备未向控制器上报款型信息请联系技术支持人员进行具体定位。Register Fail: The device model do not match with esn设备向控制器上报的款型信息和ESN不匹配请联系技术支持人员进行具体定位。Register Fail: The device unreports MAC设备未向控制器上报MAC或不符合MAC规则请联系技术支持人员进行具体定位。Register Fail: The cloud APs cannot add to AC site云AP不能加入到AC类型的站点请将设备添加到AP类型的站点。Register Fail: The ESN is not in allow rule设备不在白名单中请联系云管理平台的系统管理员检查配置，将当前设备的ESN添加到设备白名单中。Register Fail: Unsupport fail reason未知原因请联系技术支持人员进行具体定位。

atlas200 支持多线程吗？ send Data 是触发式的吗？，可以异步把数据加入队列吗？

copy是cqlsh中的逻辑导入导出命令。包括两个命令COPY TO / COPY FROM.使用这组命令可以在Cassandra与其他RDBMS或Cassandra之间迁移数据。目前已经支持csv, json文件格式以及标准输出和输入。 1. 如何执行copy?    1. 执行copy时，首先要启动cqlsh. 启动cqlsh后，接着执行copy命令。如下1    ./cqlsh 127.0.0.1 9042 -u {user_name} -p {password}1COPY cycling.cyclist_name TO '/home/cas/copydata';2. 如果数据量很大，可以放在后台执行。使用cqlsh的-e 参数。-e 参数用来后台执行给定的语句，然后退出。命令如下1    ./cqlsh 127.0.0.1 9042 -u {user_name} -p {password} -e "COPY cycling.cyclist_name TO '/home/cas/copydata'";2. COPY TO 1    COPY <table name> [(<column>, ...)] TO <file name> WITH <copy option> [AND <copy option> ...]COPY TO 常见的参数有: NUMPROCESSES, RATEFILE, PAGESIZE, BEGINTOKEN, ENDTOKEN, MAXATTEMPTS, MAXOUTPUTSIZE; 新增的参数有: RESULTFILE, DATAFORMATS, WHERECONDITION.重点介绍常见和新增的参数，关于其他COPY TO的参数可以参考Cassandra官网文档:copy-to1. `file name` 导出时，可以指定文件名称为目录, 也可以指定文件名称为文件。默认导出到文件。如果指定导出文件为存在的目录时，将会按照range范围导出到目录下的不同的文件中，如果某一个range范围导出没有数据，则不会生成文件。如果指定的文件名是文件，那将会导出到指定的文件中。如果文件不存在，则新创建该文件。1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata'"1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name'"2. `NUMPROCESSES` 导出的线程数。在导出时，会将range范围进行细分。导出的线程数越多，细分range的范围数也就越多。但当线程数太多的时候，容易对服务端造成压力，造成导出失败。所以要选择一个合适的线程数进行导出，默认的线程个数是（CPU核数 - 1）3.  `RATEFILE` 速率文件。指定文件路径后，会打印导出过程的瞬时速率，可以用来评价导出的性能。4.  `PAGESIZE` 在一次page查询中。获取的row数。 默认为 1000。 建议不要设的调小。设置太小会影响导出性能。5.  `BEGINTOKEN， ENDTOKEN` 执行要导出的range范围。默认是全部数据导出。6.  `MAXATTEMPTS` 每一个查询重试的次数。如果某次查询达到最大重试次数，那么导出将会直接失败。 7.  `MAXOUTPUTSIZE` 每一个导出文件中的最大的行数。如果导出数据大于这个值。将会轮转生成另一个文件。默认是不限制的。1    ./cqlsh 127.0.0.1 9042 -e "COPY cycling.cyclist_name to '/home/cas/copydata/cycling.cyclist_name' with MAXOUTPUTSIZE=1"8.  `RESULTFILE` 导出结果文件路径，如果不设置。默认生成在当前执行目录下。如果执行目录中存在之前的结果文件，将会重命名之前的结果文件。导出结果的内容主要包括：导出成功与否，总共导出的行数和速率，导出的range范围数，以及成功失败的range范围数，并展示每一个range范围的结果和导出的行数。9. `DATAFORMATS` 导出的数据格式。取值为csv， json。默认为csv格式。指定为json时，导出为json格式的数据。10. `WHERECONDITION` 导出的查询条件。支持查询条件的导出。对于非主键列，如果通过索引来查询，提高导出性能。         1. wherecondition 格式如下 `[key(operators)value,key(operators)value...]`        2. operators 支持 `[">=", "<=", ">", "<", "="]`，例如: `'keyspace_name=system,table_name>=local'`        3. 如果value中包含有特殊字符，比如保留字符 【" ,><=’】, 那么需要给字符加上双引号，例如：`'keyspace_name=system,table_name>="loc>=al"'`一个完整的COPY TO例子：1    nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user to '/home/cas/copydata' with WHERECONDITION='update_timestamp=1' NUMPROCESSES=12 AND RATEFILE='rate.txt' AND RESULTFILE='export_result' AND dataformats='json';"  >export.log 2>&1 &3. COPY FROM   1    COPY <table name> [(<column>, ...)] FROM <file name> WITH <copy option> [AND <copy option> ...]COPY FROM 常见的参数有: NUMPROCESSES, MAXROWS, INGESTRATE, ERRFILE, MAXBATCHSIZE, MINBATCHSIZE, CHUNKSIZE， MAXPARSEERRORS, MAXINSERTERRORS, SKIPROWS, SKIPCOLS;新增的参数有: DATAFORMATS.重点介绍常见和新增的参数，关于其他COPY FROM参数可以参考Cassandra官网文档： copy-from1. `file name` 导入数据时，指定导入的文件路径，可以是一个目录，或者是一个文件，或者是逗号分隔的文件名列表。如果是目录，则导入该目录下的所有文件。2. `NUMPROCESSES` 导入的线程数3. `MAXROWS` 导入的最大行数。默认不限制。4. `INGESTRATE` 每一秒导入的最大行数。默认为 1000005. `ERRFILE` 导入失败的列将放在这个文件中。6. `MAXBATCHSIZE` 每一次batch导入的最大行数。默认为207. `MINBATCHSIZE` 每一次batch导入的最小行数。默认为28. `CHUNKSIZE` 导入主线程给子线程每次传递的行数，默认为 10009. `MAXPARSEERRORS` 可以忽略的语法解析错误的最大行数。默认不限制10. `MAXINSERTERRORS` 可以忽略的写入失败的最大行数。默认为100011. `SKIPROWS` 导入时初始跳过的行数。默认为0，不跳过12. `SKIPCOLS` 导入时忽略的列名，以逗号分隔。默认不忽略。13. `DATAFORMATS` 导入的数据格式。取值为csv，json。默认为csv格式。数据为json格式时，必须指定为json。一个完整的COPY FROM例子：1    nohup ./cqlsh 127.0.0.1 9042 --request-timeout=3600 --debug -e "COPY nihao.sz_user FROM '/home/cas/copydata' with NUMPROCESSES=12 AND RATEFILE='rate.txt' AND dataformats='json';"  >import.log 2>&1 &

大家好，请问LiteOS中如果某一段代码运行过程中不希望发生任务调度该怎么做？在这段代码运行期间，高优先级任务不能打断低优先级任务。能不能在运行这段代码之前把优先级变为最高？或者是类似UCOS进入临界区，LiteOS需要怎么做？

基于CSE和Vert.x 开发API Gateway。单机多用户访问下，APIGateway CPU占用飙高，页面响应增长。环境上apigateway 进程号：1286791. 查看CPU占用top -p 128679查看线程cpu占用。ps -mp 128679 -o THREAD,tid,time  128722 占用高。发现有2个线程占用高，最高到80-90%。2.查看堆栈3. 修改APIGateway配置，增加thread-count值后能缓解，但是cpu占用依然很高。求助，是APIGateway微服务配置问题还是APIGateway实现问题？

想问一下多线程问题，就是我想多线程处理解码H264视频的问题，这个该怎么写？

鲲鹏开发套件已经在鲲鹏社区发布，欢迎大家试用并提宝贵意见。地址:  华为云-》鲲鹏社区-》鲲鹏软件栈-》开发工具，在开发工具列表中包含这三个工具。也可以直接访问如下链接下载试用：(1)Denpendency Advisorhttps://www.huaweicloud.com/kunpeng/software/dependencyadvisor.html 华为鲲鹏分析扫描工具是一款可以简化客户应用迁移到TaiShan服务器过程的工具。该工具安装在X86服务器上，当客户有软件需要移植到TaiShan服务器上时，可先用该工具分析可移植性和移植投入。该工具解决了客户软件移植评估分析过程中人工分析投入大、准确率低、整体效率低下的痛点，通过该工具能够自动分析并输出指导报告。工具支持的功能特性如下：l   检查用户软件资源包（RPM、JAR、TAR、zip、gzip文件）中包含的SO依赖库，并评估SO依赖库的可移植性。l   检查指定的用户软件安装路径下的SO依赖库，并评估SO依赖库的可移植性。l   检查用户软件C/C++软件构建工程文件，并评估该文件的可移植性。l   检查用户软件C/C++源码，并评估软件源文件的可移植性。l   向用户提供软件移植报告，提供移植工作量评估。l   支持命令行方式和Web两种工作模式。(2)Porting Advisorhttps://www.huaweicloud.com/kunpeng/software/portingadvisor.html软件介绍华为鲲鹏代码迁移工具是一款可以简化客户应用迁移到TaiShan服务器的过程的工具。当客户有X86平台上源代码的软件要移植到TaiShan服务器上时，可用该工具自动分析出需修改的代码内容，并指导用户如何修改。该工具解决了用户代码兼容性人工排查困难、移植经验欠缺、反复依赖编译调错定位等痛点。支持的功能特性如下：l   检查用户C/C++软件构建工程文件，并指导用户如何移植该文件。l   检查用户C/C++软件构建工程文件使用的链接库，并提供可移植性信息。l   检查用户C/C++软件源码，并指导用户如何移植源文件。l   检查用户软件中X86汇编代码，并指导用户如何移植。l   支持命令行方式和Web两种工作模式。（3）Tuning Kithttps://www.huaweicloud.com/kunpeng/software/tuningkit.html软件介绍华为鲲鹏性能优化工具是针对TaiShan服务器的性能分析和优化工具，能收集服务器的处理器硬件、操作系统、进程/线程、函数等各层次的性能数据，分析出系统性能指标，定位到瓶颈点及热点函数。华为鲲鹏性能优化工具支持的功能特性如下：l   支持采集整个系统或指定进程（包括运行中的进程或直接启动的进程）的CPU Cycles性能事件，能够快速定位到热点函数，包括应用程序函数、模块函数与内核函数，甚至能够定位到热点指令。l   支持热点函数按照CPU核/线程/模块进行分组，支持查看热点函数调用栈。l   支持通过火焰图查看热点函数及其调用栈。l   支持代码映射功能，即查看函数内的热点指令及该指令对应的高级语言文件及行号。l   支持显示汇编代码的控制流图。l   支持分析Java代码的热点函数及热点指令。

1、前言华为云TaurusDB结束有一段时间了，这几天抽时间写一下参赛总结，我是从阿里第三届中间件比赛开始参加类似比赛的，TaurusDB这次是第三次，虽然有过两次参赛经验，但是数据库比赛还是第一次，报名也是无意中看到朋友在朋友圈的分享，正好想要学习一下数据库相关知识，于是报名参加了比赛，熬了无数个夜晚，很幸运最终以第10名的成绩擦边入围，主要还是cpp大佬和其他选手承让^_^。2、赛题回顾比赛分成了初赛和复赛两个部分，初赛要求实现一个简化、高效的本地 kv（为简化开发，K固定大小8B，V固定大小4KB）存储引擎，其中每个KVStore为一个实例，每个线程操作独立的KV实例，线程间互不影响，复赛在初赛的基础上增加了计算存储分离的架构，计算节点需要通过网络传输将数据递交给存储节点存储。程序主要提供三个接口：评测程序分为2个阶段正确性评测此阶段评测程序会并发写入随机数据（key 8B、value 4KB），写入数据过程中进行任意次进程意外退出测试，引擎需要保证异常中止不影响已经写入的数据正确性。异常中止后，重启引擎，验证已经写入数据正确性和完整性，并继续写入数据，重复此过程直至数据写入完毕。只有通过此阶段测试才会进入下一阶段测试。性能评测随机写入：16个线程并发随机写入，每个线程使用Set各写400万次随机数据（key 8B、value 4KB）。顺序读取：16个线程并发按照写入顺序逐一读取，每个线程各使用Get读取400万次随机数据。热点读取：16个线程并发读取，每个线程按照写入顺序热点分区，随机读取400万次数据，读取范围覆盖全部写入数据。热点的逻辑为：按照数据的写入顺序按10MB数据粒度分区，分区逆序推进，在每个10MB数据分区内随机读取，随机读取次数会增加约10%。评测环境计算节点：内存占用不得超过4G(CPP), 5G(JAVA)，不得写入和读取磁盘空间。存储节点：内存占用不得超过2G(C++),3G(JAVA)，磁盘占用不得超过320G。注：后台将CPU统一限制为16核。语言限定CPP & Java，一起排名3、赛题分析拿到赛题后首先我们对赛题已知条件做下分析：数据总量为4M*16(64M)条数据Key数据总量为64M*8(B)，索引可以完全加载到内存定长Key(8B)和Value(4KB)极大简化索引构建和写入缓存设计读取分为顺序和逆序遍历(10M内随机)可以考虑使用LRU作为缓存策略kill -9保证数据不丢需使用mmap保证数据最终落盘因为我们比系统更了解程序的缓存策略读写考虑使用DirectIO+自管理缓存计算存储分离可以把存储节点当作一块磁盘对外提供read, write接口，把索引构建及索引查找放到计算节点因为DB是分布式的应考虑使用大块网络传输来减少rtt带来的性能损耗可以看出此次大赛的核心考察点是计算存储分离，因为计算量不大，存储介质性能又非常强悍，程序的瓶颈可能是在网络层面，如何高效利用网络是本次比赛重点思考内容。4、程序设计4.1 功能设计首先要考虑的是功能评测，即保证kill -9数据不丢，因为一个程序只有功能正确才能谈性能，保证kill -9数据不丢有两种方式，第一种是来一条数据写一次盘，每条数据都即时落盘，这个方式虽然可以保证数据不丢，但是性能堪忧，好在操作系统给我们提供了另一种方式mmap（memory mapping），通过mmap可以将文件直接映射到user内存区，user可以直接操作这块内存，程序可以通过主动（force）或者被动（程序结束或崩溃）方式将内存中的数据持久到磁盘，这个过程不经过kernel内存区，省去一次内存拷贝，同时也保证了数据安全。保证了存储节点数据不丢后下面要考虑在有网络传输的情况下数据不丢，如果允许数据丢失则可以使用异步io方式传输数据，但是要保证数据不丢则计算机点需要一直阻塞直到存储节点数据落盘并返回ack后计算节点set方法才能返回，这样网络模型为PING/PONG模型。4.2 文件分布设计因为程序是多实例数据库，实例之间互不干扰，这里没有对数据进行分片操作，其实换一个角度看我们可以把每个实例看作一个数据库分片，因为分片的目的是为了让分片之间互不干扰，提高程序并行能力，每个实例(分片)内的写操作都比较简单，采用追加写的方式。每个实例包含3个文件： MergeIO(mmap)：merge io索引文件(mmap)：Key实际存储文件数据文件：Value实际存储文件写入Value时先写入MergeIO文件，Merge满后批量写入数据文件，即使程序被kill，也可以从MergeIO文件恢复Value数据。这里感谢一下徐靖峰(岛风)同学开源的kdio(java操作DirectIO的库)4.3 索引设计数组二分查找：构建索引时需要排序，单点查询对cpu分支预测不友好，但是方便进行范围LongIntMap(开放寻址法)：可以动态构建索引，单点查询可快速定位（key冲突量不大时），难以范围查询因为这里考虑只有单点get没有范围查询，所以用了LongIntMap 4.4 读取设计读取采用LRU算法对数据进行缓存读取，每个LRU Item包含4M Value数据(1K个Value，参数可调)每个实例包含14个LRU Item，包含4M(总消息数)/1K个空Item，比如说通过Key找到Index为1，对1取模得到缓存位置0，因为缓存已存在则直接使用item.get(),如果Index为1024，因为缓存不存在，则根据缓存最后访问时间找到需要失效的缓存，通过read方法从存储节点读取该缓存的内容，然后get出结果。4.5 网络传输设计存储节点：存储节点采用Epoll EventLoop模式，节点启动16条线程，计算节点与存储节点tcp连接均匀分布在16条线程上，后面数据交互均在固定线程完成，充分利用多核优势。计算节点：计算节点采用bio方式与存储节点建立连接，计算节点与存储节点交互均采用req/res阻塞模式交互。计算节点从存储节点read数据时，存储节点dio读取的数据直接使用ByteBuf.wrap，没有内存拷贝(程序层面)，直接发送给计算节点。连接建立后开启tcp_nodelay以减少网络延迟。在比赛结束最后一天之前计算节点一直用的nio开发，写入耗时始终在719秒往上，因为一直觉得虽然nio在发送接收时与set/get线程有cpu切换，但是这些切换耗时与网络rtt相比应该不算什么，可事实总是在啪啪啪打脸，最后一天（其实也就写好两三天的样子，java环境最后几天才好，(/ □ \)）把nio改写成bio传输，写入时间从725降到560左右（不确定是否是因为cpu切换导致），总结一下就是不能搞经验主义，一定要benchmark everything。5、可探索的改进一般情况下我们使用nio都是将其fd绑定到某个event loop上，该event loop监听该fd的事件，这里其实我们可以改变nio使用方式，在set/get当前线程监听fd事件来读写数据，有set/get线程充当event loop，可能会有一个不错的提升。6、一些感想第一次参加数据库相关的比赛，收获颇多，对数据库相关知识有了初步的了解，也学到了其他选手不错的分享，同时也非常感谢举办方举办这次比赛，给选手提供一个展示和学习的平台，预祝比赛越办越好。源码地址：https://github.com/wangkaish/hw_race2019_r2_kvstore 

大家好，我们是watermelon团队，今天我们的答辩展示主要分为四个部分来介绍。首先是我们的团队和成员的简介然后是我们对这次题目重点的理解接下来，我会介绍一下我们最基础的架构，包括网络、磁盘、缓存等最后，重点介绍我们每一个性能优化点团队名叫watermelon，我们三个人都是在读的研究生，分别来自浙江大学和上海交通大学，都是明年毕业。初赛和复赛的成绩都是第四名，历史成绩非常的稳定。我们总结了几个题目重点：首先，KV 都是定长的：这样简化了⽂件和内存的操作和管理。第二点，value远大于key：把 KV 分离存储，解除索引和数据之间的耦合性。第三点，线程数固定：测评程序固定使用 16 个线程访问数据库。第四点，只需要保证进程意外退出时的持久性：所以可以利用操作系统的缓存对写入方式进行一些优化。第五点，分阶段测评：随机写、随机读、顺序读三个阶段互相没有重叠。第六点，计算节点无状态：我们知道，在这种基于共享存储的计算存储分离架构下，所有持久化数据只能存于存储节点，计算节点只进行逻辑操作。第七点，数据读取的线程和数据写入线程之间没有绑定关系：就是说，每个线程不是只读取自己写入的数据。  //与初赛不一样，读取线程id不一读的是相同id写入的数据最后一点，随机读的随机性在每个时刻只局限在一个 10M 热点分区内：并且热点分区按写入的顺序逆序推进。 下面是我们方案的核心架构:    我们计算节点和存储节点的线程采用一对一的tcp连接，因为测评程序是16线程，所以连接数就是16。在存储节点，我们有数据持久化产生的文件，以及读写文件的缓存。在计算节点，我们维护了读数据的缓存，但是没有写数据的缓存，因为要保证计算节点被 kill 的数据持久性。并且我们的索引也是只在计算节点上维护的，在数据库启动阶段从存储节点把索引数据拉到计算节点。接下来，具体介绍一下我们的文件组织形式:首先，按写入线程进行数据的分区，就是说，每个写入线程只顺序写自己的分区文件，这样就避免了多线程写同一个文件冲突的问题。然后，在每个分区内，将 key 和 value 分离存储为两个文件，一个是key log，一个是value log。可以解除索引和数据之间的耦合性。并且我们为了提高写入value 的速度，对 value 进行了缓存，缓存中凑齐若干个value后，再一起进行刷盘。为了保证缓存不丢失，缓存也使用了mmap的形式，因此对应有一个缓存文件。我们的索引也是按分区进行构建的，每个分区是一个hash，里面存的是该分区所有数据的索引项，索引项就是一个 key 和 一个value offset复赛的优化历程，我们从最开始跑通的 2300 分，到最后的 780 分，中间经过了好几次架构和方法的改变。首先我们的第一个优化是，我们在启动阶段把 key 从存储节点批量的传到计算节点，这样相比每个 key 都请求一次，批量的方法相当于减少了一半的网络请求，使得时间提升了 300 秒。接下来，由于我们无法搞定网络传输大数据包的问题，因此我们选择先在存储节点实现顺序读和随机读的缓存，这样减少了存储节点的 io 次数，时间提升了 500s再后来，我们解决了网络传输的问题，所以先在计算计算节点进行了顺序读的缓存，成绩提升到 1100s这样紧接着，我们按存储节点缓存一样的思路，把随机读缓存也拿到了计算节点，这样做之后我们的成绩就已经突破了 800s在最后阶段，我们又优化了一些细节问题，最终成绩是 781s围绕读写文件，缓存策略，和网络传输这三个方面，来讲解我们是如何把这个系统的性能压榨到极致的。对于 key 这种小数据量的读写模式，采用 mmap 可以利用 page cache 将小数据读写转换为整个内存页的读写，减少了系统调用的时间消耗。value 的大小为固定 4KB，我们知道，写入数据大小要对齐 ssd 的内部 page 时，可以达到最优写入性能。我们经过线上测试，按 1M 大小顺序写入数据可以达到最大吞吐量。所以，为每一个分区分配一个容量为 1M 的写缓冲区，写满 256 个 value 再将缓存数据一起刷盘，刷盘方式采用 direct io。并且，用 mmap 做缓存，可以保证数据持久性。第二点，我们来看，如何做随机读的缓存，使得缓存命中率最高。现在背景是，随机读在每个时刻只局限在一个 10M 热点分区内，并且热点分区按写入的顺序逆序推进。看图，上面是我们实际存储的文件，按10M分为了若干个block，就是说，我们的缓存只能按 block 对齐进行加载数据。然后，下面是测评的热点分区示意图，我们发现一共 400w 数据，热点分区的边界跟实际数据 10M 边界很可能是不对齐的，并且边界值未知。所以，如果我们只用单个 10M 的缓存，会出现下面这样的问题。假设当前阶段，测评程序要随机访问 hot1 这个热点分区。第一个位置，我们缓存加载了block3，然后，访问第二个位置，发现缓存失效，加载了block2，继续访问第三个位置，缓存又失效了，重现加载回了block3所以，这样就产生了一个缓存来回震荡的问题，极端情况是，我要访问400万数据，一共要加载400万次大块的缓存，肯定超时，还不如不做缓存。我们的方案是，采用两个 10M 的buffer，一前一后，一起往前推进，这样非常完美了避免了缓存来回震荡的问题。并且这个 buffer 不一定是10M，只要大于10M都可以解决这个问题。第三点，我们来看，如何使得网络的传输效率最高。我们发现，写入阶段的网络传输时间主要瓶颈是在周转时间上，也就是说，不是网络有多么拥塞导致网络传输变慢，而是说，value发过去再回来，本身就需要这么长的时间。所以我们的优化只能是让存储节点尽可能快的返回ack信号，我们的做法是在数据写入存储节点的mmap之后，就返回ack，而不用等待page cache 刷盘。对于持久性，recover 阶段会把 cachebuffer 里面的数据都重新写进 value 文件里。对于大块数据进行拆分，然后进行多次发送，可以在发送的同时进行流量控制，使吞吐量保持在一个较高的水平。我们的流量控制方法非常简单粗暴，在发送每两个 4k 数据之间，直接加一个延时，延时的方法是让 CPU 自旋一会。并且，存储节点也做了读缓存，把存储节点的读缓存，批量拆分传到计算节点。最后，回到一个宏观的位置上来看，通过这次比赛，我们严格按照计算存储分离的思想来设计了我们的系统架构。对基于共享存储的计算存储分离架构有了一些认知和理解。首先，我们看计算节点我们的架构只支持一个 RW 节点，进行数据的写入。但是 RO 节点在理论上是可以无限扩展的。并且，由于底层的共享存储，所以主从复制的延迟可以做到非常低。当 RW 写入一个 kv 数据，对于 RO 节点，它只需要更新已经存在自己 buffer pool 中的数据，而如果发现 RW 写入的数据不在它的 buffer pool 中，那它什么也不做。只有在 RO 节点读取数据时，发现要请求的数据不在自己的buffer pool中，它才去下面的存储节点中拉取这个数据到自己的 buffer pool 中。这样看来，我们在实现高可用功能时候，可以很直接的进行主从切换，RO 节点可以迅速提升为 RW 节点，直接开始对外服务。再看存储节点我们当前只是在单个节点上保证了数据的持久性，而这种 kv 存储可以扩展为分布式架构，采用多副本存储，从而能获得更好的容错性，和更好的读写性能。所以这样一整套架构，可以解决很多实际的痛点，因此，会成为当今云数据库的一个趋势。

缘起TaurusDB是华为云自主研发的最新一代云原生分布式数据库，完全兼容mysql8.0，采用计算与存储分离、日志即数据的架构设计，支持1写15读，性能达到原生Mysql的7倍。Taurus构建在共享分布式存储上，存储空间最高达128T，能跨AZ部署，具有可靠、高性能、易伸缩等特性。华为云TaurusDB性能挑战赛是由华为云主办的数据库领域顶级赛事，大赛将综合科研教学成果及商业领域需求，探索数据库领域的技术问题的可行性，为需求方和开发者提供联接的桥梁；并联合合作伙伴，搭建一个技术交流、人才培养、机遇共创数据库开发者平台和生态。听起来很激动人心吧，关键是奖金也很多, 同时还能刷脸! 最早是听一个同事说起的，恰好本人的工作也是“新一代数据库”开发，看着这么多人工智能的比赛不能参加，只能后悔自己选错了专业，但是机会来了，终于有自己擅长的领域了，心想不能错过这次机会，一边默默加了收藏。比赛内容一句话概括，就是实现一个kvstore，初赛是单机引擎，复赛要求存储计算分离，并且kv都是定长的，如果通用性做得好，可以直接用作块存储。题目初赛和复赛稍有区别，这里只说复赛的题目。存储引擎K,V都是定长的，key 8bytes， value 4K bytes。 测试分为三轮，第一轮, 16个线程写，每个线程写400万次；第二轮，16个线程读，每个线程按顺序读取400万次；第三轮，16个线程读,每个线程逆序读取400万次。第三轮的逆序是局部随机，总体逆序，也即在10M的数据范围内随机读，然后以10M为单位逆序推进。 成绩就是看总时间，时间越短越好。前面已经说过，初赛要实现的是单机引擎，复赛要实现的是存储计算分离的引擎，最大的限制是计算节点不能持久化任何数据。预选赛不得不说，华为可真会玩，这次预选赛竟然还要做题，并且是必须要学习他们的资料才能通过的题目，题目包括数据库的基本常识，但是也有产品介绍，经过深夜两个小时的学习，我算是第一次知道了这么多种不同的产品究竟是干嘛的。第一次答题还错了一道，以防万一，又做了一遍，这次错了两道，算了不玩了，95分也够了，睡觉去。但是心里总是不舒服，究竟是哪错了，又看了一遍，原来是幻读的理解这道题错了。初赛不出意外，预选赛顺利通过，初赛就开始写代码了，初赛只要写对差不多就可以晋级复赛。 当然任何一个程序员都不会满足刚好够用的状态，因此正常能想到的优化都加上了： 比如Direct IO, 多文件做数据分区，引入写buffer，比较频繁修改元数据，读取使用自己实现的page cache，以免4K读不能打满磁盘带宽。复赛复赛要求存储计算分离, 我认真做了一些分析，同时也对他们的硬件做了测试，分析下来，这个比赛比拼的点和我平时在工作中要追求的还是很不一样的。 平时无论做什么系统，都是在延迟差不多的情况下，把吞吐量做高，这次比赛最关键的一个点是：延迟第一，延迟是最重要的，特别是写的阶段，因为并发只有16，想通过聚合换吞吐量都不好使了。首先考虑持久化方法：4K恰好能对齐IO，所以key和value要分开存储,      想使用rocksdb之类的存储引擎即使不被禁止也是没有竞争力的。value非常随机，基本不用考虑压缩，就算有一点点好处，实现起来也太复杂了。再次考虑如何优化IO:SSD的IO吞吐量高于4K * iops, 不管是读还是写，IO聚合是必须的。单文件会遇到文件系统瓶颈，需要多文件, 也即要对数据做partition。关于同步IO还是异步IO的选择, 因为延迟优先，所以应该选同步IO。最后考虑网络框架:首先，我直接放弃考虑任何已有的网络框架，因为这是benchmark， 再小的开销也是开销，都会让程序变慢。其次，实际上任何IO      multiplexing的框架都会造成额外的延迟，不仅复杂，也是得不尝失的。综上，我决定就使用最简单的阻塞式IO来做socket通信。总体设计计算节点和存储节点分工, 关键就是索引维护在哪？经过思考, 决定索引维护在计算节点。 索引的内容是: key -> <file_id, pos>, 索引在计算节点的内存中维护为hash表。因为build索引大概需要400ms，写入再读取index比重新构建一遍index时间还长, 所以索引不需要持久化, 这其实是一个反直觉的决定。 计算节点在发送第一个读请求之前，会从存储节点把所有写入的key和pos发送过来, 然后由计算节点构造索引。存储节点起16个线程，listen在16个不同的端口。计算节点也会有16个线程， 每个计算节点的线程只会连接一个存储节点的端口，从而和一个存储节点线程通信。写入请求：写入过程不同的线程完全独立，每个线程负责一部分数据。请求发到存储节点后由接受请求的线程写入。读取过程:读取过程每个存储线程会读取任意一个线程写入的数据。由计算节点指定要读取那个分区的数据。也即写请求发到哪个存储线程，就由那个存储线程写入，每个存储线程实际上就对应了一个数据分区。 读请求发到一个存储线程，它可能要跨线程读取其它分区的数据。存储文件存储节点把数据分为16个partition，每个partition由一个线程负责写入。 每个partition共三个文件: 之所以有三个文件，是因为首先key和value要分开存储，这就要用两个文件；其次为了优化写，额外引入了文件做写入buffer。文件命名规则如下, 以第一个分区为例:00.k: 保存写入的key。 fallocate 4M * 8B， mmap到内存。00.v:      保存写入的value。fallocate 4M *      4K， DIO读写。00.b:      用作写入buffer。fallocate 16K      buffer + 4K 元数据，mmap到内存。写入原子性先写key和value，再更新key count。 key count改成功，则写成功；否则写失败，下次重启进程当作这次写没发生过。换句话说，key count改成功实际上表示这次写入commit成功。key count记录在00.k的第一个8字节, 如前所诉, 00.k是mmap到内存的，所以更新key count是没有什么代价的。value先记录到写buffer里，然后批量刷到00.v文件。key file内容如下:key countk1k2k3k4k5k6……value file内容如下:value countv1v2v3v4v5v6……buffer file内容如下:b0b1b2b3…………b15flushed poswrite buffer也是mmap到内存的， 前64K记录数据。 紧跟64K的8个字节记录flushed pos。 因为mmap必须以page为单位，所以实际内存占用64K + 4K。 它实际上是一个mmap持久化的ring buffer。 Ring Buffer的元数据包括filled pos和flushed pos。 filled pos由key count可以算出来, 所以不需要单独再记。build indexbuild index实际上是构造一个key -> offset的hash表。 要在400ms内完成build index，难点是如何并行：基本思路是把key做partition，每个partition内独立构造hash。这本质上是一个MapReduce的过程。map阶段: 并行划分range, 16个线程，每个线程负责处理一个key文件。reduce阶段: 并行构造hash, 16个线程，每个线程处理一个range。线程同步: 第二阶段开始之前要等第一全部完成，也即两个Stage之间是个Barrier, 这个同步过程和map reduce的shuffle是类似的。读取cache的实现cache是value的镜像，value文件分成了16个，cache也对应分成16组。 因为顺序和热点访问模式对cache都很友好，cache不需要特别大，每一组cache大小为64M。为了应对热点读，cache的最小单元设为16M，借用CPU cache的术语，我把它叫cache line，这是一个很大的值。 cache的内存因为是定长的，所以通过mmap一次申请好，不需要动态分配。 cache的索引本质是一个hash，但是不用解决冲突, 用file offset直接计算得到索引的下标。对16组cache中的每一组来说，有4个cache line, 每个cache line有三种状态，用一个uint32_t表示：Invalid: UINT32_MAXLocked:      UINT32_MAX - 1Valid:      file_offset »12cache line的状态被叫做indexStat，它被单独记在另外一个小数组里。读取不用加锁，使用double check即可:读取之前检查IndexStat有效，并且offset和我要读取的内容匹配。拷贝cache line的内容到私有buffer。拷贝完cache line的内容后再检查IndexStat是否发生过变化, 如果indexStat没有变化过，则说明我们拷贝的cache      line内容是对的。为了让上述double check生效, 更新cache的线程需要在写入之前把indexStat改为Locked，更新完成后再把indexStat改为有效值。关于网络通信关于网络框架还有一个问题，就是是否有必要用UDP，犹豫之下，觉得UDP还是会更复杂，稳妥起见，选择了TCP。后来得知在测试环境里UDP是不同的，也就释然了。但是TCP看起来开箱即用，用起来却暗藏机关，至少要调整以下三个参数:tcp_nodelaytcp_quickacksend/recv      buf最后为了规避TCP的流控，我们要避免另外两个坑:避免发送太快，超过交换机的队列长度，从而导致丢包，因为TCP的工作方式就是，只要你给它数据，它就会不停的加大，发送窗口，直到发生丢包，然后触发限流。要避免这种情况，本质是要限制TCP的连接数， 因为只要连接数限制住了，发送窗口总长度也就限制住了。避免TCP”冷却”之后重新进入慢启动状态，如果有root权限，是可以通过sysctl关闭slow start的，但是我们没法控制系统参数，这就要求我们一个连接最好要不停的发包，不要停下来。有人定义了packet格式，而我遵循一切从简的原则，没有实现通常RPC要有的功能:没有定义pcode，因为整个通信过程就只有读和写两种request，每一个socket只用来发送一种类型的request，如果要发送不同的request，只需要切换socket即可。没有实现序列化，因为request很简单，只需要把结构体直接发送到socket即可。细节决定性能细节也就是很多关于性能的小点：首先关于文件IO: 同步IO比异步IO延迟要小; open的时候加入O_NOATIME避免读取操作也修改元数据其次关于内存分配: 分配完内后提前触发page fault至少可以让性能更稳定，如果不能提高性能的话；      分配内存可以尝试hugepage, 失败之后再使用4K page; mmap的内存可以不用清零最好关于CPU, 绑核，通用可以让延迟更稳定, 理论上对性能是有提升的。正确性测试如前所属，我基本上是一切从简，但即使如此，提交了好多次，都通不过正确性测试。为了排查问题，专门写了一个随机的验证程序，这个比官方的测试强度高多了。确实发现了一个readv之后更新iovec的bug，还有一处cache的bug。 事后看来，在这个测试上花的时间非常值得，否则我可能到最后都没有成绩。总结这次比赛感觉有点像马拉松，听完大家的分享，感觉每个人的时间都比较有限，大家都是争分夺秒,每个人都有一些优化没来得及试。本人最大的一个遗憾是读预取没有实现。另外一个是写的过程中网络和IO并行化做的不好。最后听了第一名的方案，深有体会，要想拿到最好的成绩，需要把写和读分开考虑，同时把网络传输和本地IO分开考虑。单纯从工程上说，我的代码有一些特有的风格, 简单来说就是总爱重复造轮子，不愿意引入依赖：没有用pthread mutex/cond，全部用atomic      ops + futex没有spin，等待的地方都有睡眠和唤醒机制另外，本人虽然工作中用C++, 但是我情愿用plain old C, 所以我很少用高级C++特性。如果未来还做这种系统实现的比赛，希望有可以利用RDMA的和NVM的比赛, 毕竟，新硬件总是有更多的可能。当然比赛的设置要考虑引入更多自由度，这样会更加有趣。