AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

Linux内核 RPS/RFS功能详细测试分析

2023-11-16 634
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云原生大数据计算服务MaxCompute，500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute，5000CU*H 100GB 3个月
简介： Linux内核 RPS/RFS功能详细测试分析

RPS和RFS

  • RPS 全称是 Receive Packet Steering, 这是Google工程师 Tom Herbert (therbert@google.com )提交的内核补丁, 在2.6.35进入Linux内核. 这个patch采用软件模拟的方式，实现了多队列网卡所提供的功能，分散了在多CPU系统上数据接收时的负载, 把软中断分到各个CPU处理，而不需要硬件支持，大大提高了网络性能。
  • RFS 全称是 Receive Flow Steering, 这也是Tom提交的内核补丁，它是用来配合RPS补丁使用的，是RPS补丁的扩展补丁，它把接收的数据包送达应用所在的CPU上，提高cache的命中率。
  • 这两个补丁往往都是一起设置，来达到最好的优化效果, 主要是针对单队列网卡多CPU环境(多队列多重中断的网卡也可以使用该补丁的功能，但多队列多重中断网卡有更好的选择:SMP IRQ affinity)

原理

RPS: RPS实现了数据流的hash归类，并把软中断的负载均衡分到各个cpu，实现了类似多队列网卡的功能。由于RPS只是单纯的把同一流的数据包分发给同一个CPU核来处理了，但是有可能出现这样的情况，即给该数据流分发的CPU核和执行处理该数据流的应用程序的CPU核不是同一个：数据包均衡到不同的cpu，这个时候如果应用程序所在的cpu和软中断处理的cpu不是同一个，此时对于cpu cache的影响会很大。那么RFS补丁就是用来确保应用程序处理的cpu跟软中断处理的cpu是同一个，这样就充分利用cpu的cache。

  • 应用RPS之前: 所有数据流被分到某个CPU, 多CPU没有被合理利用， 造成瓶颈
  • 应用RPS之后: 同一流的数据包被分到同个CPU核来处理，但可能出现cpu cache迁跃
  • 应用RPS+RFS之后: 同一流的数据包被分到应用所在的CPU核必要条件使用RPS和RFS功能，需要有大于等于2.6.35版本的Linux kernel.如何判断内核版本?
$ uname -r
.6.38-2-686-bigmem
  • 对比测试
类别 测试客户端 测试服务端
型号 BladeCenter HS23p BladeCenter HS23p
CPU Xeon E5-2609 Xeon E5-2630
网卡 Broadcom NetXtreme II BCM5709S Gigabit Ethernet Emulex Corporation OneConnect 10Gb NIC
内核 3.2.0-2-amd64 3.2.0-2-amd64
内存 62GB 66GB
系统 Debian 6.0.4 Debian 6.0.5
超线程 否 是
CPU核 4 6
驱动 bnx2 be2net
  • 客户端: netperf
  • 服务端: netserver
  • RPS cpu bitmap测试分类: 0(不开启rps功能), one cpu per queue(每队列绑定到1个CPU核上), all cpus per queue(每队列绑定到所有cpu核上), 不同分类的设置值如下
  1. 0(不开启rps功能)
/sys/class/net/eth0/queues/rx-0/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-1/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-2/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-3/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-4/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-5/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-6/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-7/rps_cpus 00000000
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-1/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-2/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-3/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-4/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-5/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-6/rps_flow_cnt 0
/sys/class/net/eth0/queues/rx-7/rps_flow_cnt 0
/proc/sys/net/core/rps_sock_flow_entries 0
  1. one cpu per queue(每队列绑定到1个CPU核上)
/sys/class/net/eth0/queues/rx-0/rps_cpus 00000001
/sys/class/net/eth0/queues/rx-1/rps_cpus 00000002
/sys/class/net/eth0/queues/rx-2/rps_cpus 00000004
/sys/class/net/eth0/queues/rx-3/rps_cpus 00000008
/sys/class/net/eth0/queues/rx-4/rps_cpus 00000010
/sys/class/net/eth0/queues/rx-5/rps_cpus 00000020
/sys/class/net/eth0/queues/rx-6/rps_cpus 00000040
/sys/class/net/eth0/queues/rx-7/rps_cpus 00000080
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-1/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-2/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-3/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-4/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-5/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-6/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-7/rps_flow_cnt 4096
/proc/sys/net/core/rps_sock_flow_entries 32768
  1. all cpus per queue(每队列绑定到所有cpu核上)
/sys/class/net/eth0/queues/rx-0/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-1/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-2/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-3/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-4/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-5/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-6/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-7/rps_cpus 000000ff
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-1/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-2/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-3/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-4/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-5/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-6/rps_flow_cnt 4096
/sys/class/net/eth0/queues/rx-7/rps_flow_cnt 4096
/proc/sys/net/core/rps_sock_flow_entries 32768
  • 测试方法: 每种测试类型执行3次，中间睡眠10秒, 每种测试类型分别执行100、500、1500个实例， 每实例测试时间长度为60秒
  • TCP_RR 1 byte: 测试TCP 小数据包 request/response的性能
netperf -t TCP_RR -H $serverip -c -C -l 60
  • UDP_RR 1 byte: 测试UDP 小数据包 request/response的性能
netperf -t UDP_RR -H $serverip -c -C -l 60
  • TCP_RR 256 byte: 测试TCP 大数据包 request/response的性能
netperf -t TCP_RR -H $serverip -c -C -l 60 -- -r256,256
  • UDP_RR 256 byte: 测试UDP 大数据包 request/response的性能
netperf -t UDP_RR -H $serverip -c -C -l 60 -- -r256,256
  • TPS测试结果
  • TCP_RR 1 byte小包测试结果
  • TCP_RR 256 byte大包测试结果
  • UDP_RR 1 byte小包测试结果
  • UDP_RR 256 byte大包测试结果
  • CPU负载变化
    在测试过程中，使用mpstat收集各个CPU核的负载变化
  1. 关闭RPS/RFS: 可以看出关闭RPS/RFS时，软中断的负载都在cpu0上，并没有有效的利用多CPU的特性，导致了性能瓶颈
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
Average:     all    3.65    0.00   35.75    0.05    0.01   14.56    0.00    0.00   45.98
Average:       0    0.00    0.00    0.00    0.00    0.00  100.00    0.00    0.00    0.00
Average:       1    4.43    0.00   37.76    0.00    0.11   11.49    0.00    0.00   46.20
Average:       2    5.01    0.00   45.80    0.00    0.00    0.00    0.00    0.00   49.19
Average:       3    5.11    0.00   45.07    0.00    0.00    0.00    0.00    0.00   49.82
Average:       4    3.52    0.00   40.38    0.14    0.00    0.00    0.00    0.00   55.96
Average:       5    3.85    0.00   39.91    0.00    0.00    0.00    0.00    0.00   56.24
Average:       6    3.62    0.00   40.48    0.14    0.00    0.00    0.00    0.00   55.76
Average:       7    3.87    0.00   38.86    0.11    0.00    0.00    0.00    0.00   57.16
  1. 每队列关联到一个CPU TCP_RR: 可以看出软中断负载已经能分散到各个CPU核上，有效利用了多CPU的特性，大大提高了系统的网络性能
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
Average:     all    5.58    0.00   59.84    0.01    0.00   22.71    0.00    0.00   11.86
Average:       0    2.16    0.00   20.85    0.00    0.04   72.03    0.00    0.00    4.93
Average:       1    4.68    0.00   46.27    0.00    0.00   42.73    0.00    0.00    6.32
Average:       2    6.76    0.00   63.79    0.00    0.00   11.03    0.00    0.00   18.42
Average:       3    6.61    0.00   65.71    0.00    0.00   11.51    0.00    0.00   16.17
Average:       4    5.94    0.00   67.83    0.07    0.00   11.59    0.00    0.00   14.58
Average:       5    5.99    0.00   69.42    0.04    0.00   12.54    0.00    0.00   12.01
Average:       6    5.94    0.00   69.41    0.00    0.00   12.86    0.00    0.00   11.78
Average:       7    6.13    0.00   69.61    0.00    0.00   14.48    0.00    0.00    9.77
  1. 每队列关联到一个CPU UDP_RR: CPU负载未能均衡的分布到各个CPU, 这是由于网卡hash计算在UDP包上的不足， 详细请见本文后记部分
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
Average:     all    3.01    0.00   29.84    0.07    0.01   13.35    0.00    0.00   53.71
Average:       0    0.00    0.00    0.08    0.00    0.00   90.01    0.00    0.00    9.91
Average:       1    3.82    0.00   32.87    0.00    0.05   12.81    0.00    0.00   50.46
Average:       2    4.84    0.00   37.53    0.00    0.00    0.14    0.00    0.00   57.49
Average:       3    4.90    0.00   37.92    0.00    0.00    0.16    0.00    0.00   57.02
Average:       4    2.57    0.00   32.72    0.20    0.00    0.09    0.00    0.00   64.42
Average:       5    2.66    0.00   33.54    0.11    0.00    0.08    0.00    0.00   63.60
Average:       6    2.75    0.00   32.81    0.09    0.00    0.06    0.00    0.00   64.30
Average:       7    2.71    0.00   32.66    0.17    0.00    0.06    0.00    0.00   64.40
  1. 每队列关联到所有CPU: 可以看出软中断负载已经能分散到各个CPU核上，有效利用了多CPU的特性，大大提高了系统的网络性能
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
Average:     all    5.39    0.00   59.97    0.00    0.00   22.57    0.00    0.00   12.06
Average:       0    1.46    0.00   21.83    0.04    0.00   72.08    0.00    0.00    4.59
Average:       1    4.45    0.00   46.40    0.00    0.04   43.39    0.00    0.00    5.72
Average:       2    6.84    0.00   65.62    0.00    0.00   11.39    0.00    0.00   16.15
Average:       3    6.71    0.00   67.13    0.00    0.00   12.07    0.00    0.00   14.09
Average:       4    5.73    0.00   66.97    0.00    0.00   10.71    0.00    0.00   16.58
Average:       5    5.74    0.00   68.57    0.00    0.00   13.02    0.00    0.00   12.67
Average:       6    5.79    0.00   69.27    0.00    0.00   12.31    0.00    0.00   12.63
Average:       7    5.96    0.00   68.98    0.00    0.00   12.00    0.00    0.00   13.06
  • 结果分析
    以下结果只是针对测试服务器特定硬件及系统的数据，在不同测试对象的RPS/RFS测试结果可能有不同的表现
    TCP性能:
  • 在没有打开RPS/RFS的情况下，随着进程数的增加，TCP tps性能并明显没有提升，在184~188k之间。
  • 打开RPS/RFS之后，随着RPS导致软中断被分配到所有CPU上和RFS增加的cache命中, 小数据包(1字节)及大数据包(256字节，相对小数据包而言, 而不是实际应用中的大数据包)的tps性能都有显著提升
  • 100个进程提升40%的性能(两种RPS/RFS设置的性能结果一致), cpu负载升高40%
  • 500个进程提升70%的性能(两种RPS/RFS设置的性能结果一致), cpu负载升高62%
  • 1500个进程提升75%的性能(两种RPS/RFS设置的性能结果一致), cpu负载升高77%
  • UDP性能:
  • 在没有打开RPS/RFS的情况下，随着进程数的增加，UDP tps性能并明显没有提升，在226~235k之间。
  • 打开RPS/RFS之后，，随着RPS导致软中断被分配到所有CPU上和RFS增加的cache命中, 小数据包(1字节)及大数据包(256字节，相对小数据包而言, 而不是实际应用中的大数据包)的TPS性能, 在每队列关联到所有CPU的情况下有显著提升, 而每队列关联到一个CPU后反倒是导致了UDP tps性能下降1% (这是bnx2网卡不支持UDP port hash及此次测试的局限性造成的结果, 详细分析见: 后记)
  • 每队列关联到所有CPU的情况下, 在100个进程时小包提升40%的性能, cpu负载升高60%; 大包提升33%, cpu负载升高47%
  • 每队列关联到所有CPU的情况下, 在500个进程提小包提升62%的性能, cpu负载升高71%; 大包提升60%, cpu负载升高65%
  • 每队列关联到所有CPU的情况下, 在1500个进程提升65%的性能, cpu负载升高75%； 大包提升64%, cpu负载升高74%
  • 后记
    UDP在每队列绑定到一个CPU时性能下降，而绑定到所有CPU时，却有性能提升，这一问题涉及到几个因素，当这几个因素凑一起时，导致了这种奇特的表现。
  • 此次测试的局限性：本次测试是1对1的网络测试，产生的数据包的IP地址都是相同的
  • bnx2网卡在RSS hash上，不支持UDP Port，也就是说，网卡在对TCP数据流进行队列选择时的hash包含了ip和port, 而在UDP上的hash, 只有IP地址，导致了本次测试(上面的局限性影响)的UDP数据包的hash结果都是一样的，数据包被转送到同一条队列。
  • 单单上面两个因素，还无法表现出UDP在每队列绑定到一个CPU时性能下降，而绑定到所有CPU时，却有性能提升的现象。 因为RPS/RFS本身也有hash计算，也就是进入队列后的数据包，还需要经过RPS/RFS的hash计算(这里的hash支持udp port), 然后进行第二次数据包转送选择；如果每队列绑定到一个CPU, 系统直接跳过第二次hash计算，数据包直接分配到该队列关联的CPU处理，也就导致了在第一次hash计算后被错误转送到某一队列的UDP数据包，将直接送到cpu处理，导致了性能的下降； 而如果是每队列绑定到所有CPU， 那么进入队列后的数据包会在第二次hash时被重新分配，修正了第一次hash的错误选择。
文章标签：
云原生大数据计算服务 MaxCompute
Linux
网络协议
负载均衡
关键词：
Linux内核
Linux测试
测试分析
Linux分析
功能测试
相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析，通过分析能得到用户群体年龄分布，性别分布，地理位置分布，以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品，是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法，从场景到实践，体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库，助力开发者学习了解先进的技术栈，并能在实际业务中敏捷的进行大数据分析，赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景，可应用MaxCompute实现数仓搭建，快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理，需要搭建数据仓库？学它！ 没有足够人员和经验来运维大数据平台，不想自建IDC买机器，需要免运维的大数据平台？会SQL就等于会大数据？学它！ 想知道大数据用得对不对，想用更少的钱得到持续演进的数仓能力？获得极致弹性的计算资源和更好的性能，以及持续保护数据安全的生产环境？学它！ 想要获得灵活的分析能力，快速洞察数据规律特征？想要兼得数据湖的灵活性与数据仓库的成长性？学它！ 出品人：阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
流子
目录
相关文章
wljslmz
|
4天前
|
安全 Linux 虚拟化
Manjaro Linux 推出新不可变版本：扩展产品范围，开放社区反馈和测试
【10月更文挑战第29天】
wljslmz
16 0
Manjaro Linux 推出新不可变版本：扩展产品范围，开放社区反馈和测试
叫个什么名字
|
1天前
|
算法 Linux 开发者
深入探究Linux内核中的内存管理机制
本文旨在对Linux操作系统的内存管理机制进行深入分析，探讨其如何通过高效的内存分配和回收策略来优化系统性能。文章将详细介绍Linux内核中内存管理的关键技术点，包括物理内存与虚拟内存的映射、页面置换算法、以及内存碎片的处理方法等。通过对这些技术点的解析，本文旨在为读者提供一个清晰的Linux内存管理框架，帮助理解其在现代计算环境中的重要性和应用。
叫个什么名字
15 6
游客sjjs6jgz4gp7m1
|
1天前
|
人工智能 算法 大数据
Linux内核中的调度算法演变：从O(1)到CFS的优化之旅###
本文深入探讨了Linux操作系统内核中进程调度算法的发展历程，聚焦于O(1)调度器向完全公平调度器（CFS）的转变。不同于传统摘要对研究背景、方法、结果和结论的概述，本文创新性地采用“技术演进时间线”的形式，简明扼要地勾勒出这一转变背后的关键技术里程碑，旨在为读者提供一个清晰的历史脉络，引领其深入了解Linux调度机制的革新之路。 ###
游客sjjs6jgz4gp7m1
10 2
萝卜带泥
|
3天前
|
算法 Linux 定位技术
Linux内核中的进程调度算法解析####
【10月更文挑战第29天】 本文深入剖析了Linux操作系统的心脏——内核中至关重要的组成部分之一，即进程调度机制。不同于传统的摘要概述，我们将通过一段引人入胜的故事线来揭开进程调度算法的神秘面纱，展现其背后的精妙设计与复杂逻辑，让读者仿佛跟随一位虚拟的“进程侦探”，一步步探索Linux如何高效、公平地管理众多进程，确保系统资源的最优分配与利用。 ####
萝卜带泥
24 4
叫个什么名字
|
4天前
|
缓存 负载均衡 算法
Linux内核中的进程调度算法解析####
本文深入探讨了Linux操作系统核心组件之一——进程调度器，着重分析了其采用的CFS（完全公平调度器）算法。不同于传统摘要对研究背景、方法、结果和结论的概述，本文摘要将直接揭示CFS算法的核心优势及其在现代多核处理器环境下如何实现高效、公平的资源分配，同时简要提及该算法如何优化系统响应时间和吞吐量，为读者快速构建对Linux进程调度机制的认知框架。 ####
叫个什么名字
20 1
最好zzz
|
7天前
|
缓存 Linux
揭秘Linux内核：探索CPU拓扑结构
【10月更文挑战第26天】
最好zzz
23 1
潇洒洒
|
7天前
|
缓存 运维 Linux
深入探索Linux内核：CPU拓扑结构探测
【10月更文挑战第18天】在现代计算机系统中，CPU的拓扑结构对性能优化和资源管理至关重要。了解CPU的核心、线程、NUMA节点等信息，可以帮助开发者和系统管理员更好地调优应用程序和系统配置。本文将深入探讨如何在Linux内核中探测CPU拓扑结构，介绍相关工具和方法。
潇洒洒
9 0
丰宝宝
|
4天前
|
缓存 算法 Linux
Linux内核中的内存管理机制深度剖析####
【10月更文挑战第28天】 本文深入探讨了Linux操作系统的心脏——内核，聚焦其内存管理机制的奥秘。不同于传统摘要的概述方式，本文将以一次虚拟的内存分配请求为引子，逐步揭开Linux如何高效、安全地管理着从微小嵌入式设备到庞大数据中心数以千计程序的内存需求。通过这段旅程，读者将直观感受到Linux内存管理的精妙设计与强大能力，以及它是如何在复杂多变的环境中保持系统稳定与性能优化的。 ####
丰宝宝
11 0
科技小能手
|
测试技术 Linux Shell
动手制作简易功能Linux
科技小能手
1114 0
东方睿赢
|
15天前
|
运维 安全 Linux
Linux中传输文件文件夹的10个scp命令
【10月更文挑战第18天】本文详细介绍了10种利用scp命令在Linux系统中进行文件传输的方法，涵盖基础文件传输、使用密钥认证、复制整个目录、从远程主机复制文件、同时传输多个文件和目录、保持文件权限、跨多台远程主机传输、指定端口及显示传输进度等场景，旨在帮助用户在不同情况下高效安全地完成文件传输任务。
东方睿赢
111 5

热门文章

最新文章

  • 1
    测试开启MySQL performance_schema后对性能的影响
  • 2
    若依框架渗透测试用户名密码明文传输问题
  • 3
    5G加速商业化 移动边缘计算测试年内完成
  • 4
    【转】Orion - oracle提供的测试io性能的工具
  • 5
    postgresql 9.6 建立多列索引测试
  • 6
    VSTS 通过生成中未通过的测试自动创建 Bug 工作项
  • 7
    云数据库（国产）测试结果总结
  • 8
    【29】知识蒸馏(knowledge distillation)测试以及利用可学习参数辅助知识蒸馏训练Student模型
  • 9
    Go语言之基准测试
  • 10
    c++工程包含测试
  • 1
    Linux：进程等待 & 进程替换
    59
  • 2
    Linux：进程创建 & 进程终止
    68
  • 3
    Linux：进程地址空间
    58
  • 4
    Linux：环境变量
    51
  • 5
    Linux：进程调度
    60
  • 6
    Linux：进程状态
    58
  • 7
    Linux：进程概念
    55
  • 8
    Linux：调试器 - gdb
    66
  • 9
    Linux：自动化构建 - make
    48
  • 10
    xenomai内核解析--双核系统调用(二)--应用如何区分xenomai/linux系统调用或服务
    195

    • 相关课程

    更多
  • Linux高级网络应用 - 网络管理与配置实战
  • Linux MySQL服务器搭建与应用
  • Linux Web服务器Nginx搭建与配置
  • Linux用户和组管理
  • Linux服务器运维基本操作
  • 计算机基础与Linux入门

    • 相关电子书

    更多
  • 移动互联网测试到质量的转变
  • 给ITer的技术实战进阶课-阿里CIO学院独家教材（四）
  • F2etest — 多浏览器兼容性测试整体解决方案

    • 相关实验场景

    更多
  • 快速上手并跑通AnalyticDB PostgreSQL版TPC-H测试
  • Alibaba Cloud Linux操作系统的安装及使用
  • Alibaba Cloud Linux操作系统Shell程序

    • 推荐镜像

    更多
  • mxlinux-iso
  • archlinuxarm
  • archlinuxcn
    • 下一篇
    DataWorks智能数据建模全面公测开始啦！