数据库
性能参数
p99 latency:
99th percentile latency 是一种用于衡量系统性能的指标,特别是在网络、计算和存储领域。它表示系统在一定时间范围内,例如一秒钟或一分钟内,对请求的响应时间进行排序后,取排在第99%位置的值作为度量标准。
换句话说,p99 latency表示在一定时间内,99%的请求都能够在这个时间之内得到响应,而有1%的请求的响应时间超过了这个值。因此,p99 latency是一种反映系统性能的高百分位数指标,它关注的是在绝大多数情况下系统的表现,而忽略了一小部分可能出现的极端情况。
对于一个服务而言,p99 latency通常比平均值更能反映系统的真实性能,因为平均值容易受到极端值的影响。如果p99 latency较高,说明系统中有一小部分请求的响应时间相对较长,可能需要进一步优化以提高整体性能。
QPS:
QPS代表”Queries Per Second”,即每秒查询数。这是衡量系统性能的一个指标,尤其常用于描述数据库、网络服务和其他计算系统的吞吐量。
QPS表示在每秒内系统能够处理的查询或请求的数量。这个指标对于评估系统的性能、稳定性和容量有重要意义。高QPS通常表示系统具有较高的吞吐量,能够处理大量的请求,而低QPS则可能暗示系统性能不足或者存在瓶颈。
需要注意的是,QPS是一个宽泛的指标,具体的应用场景可能需要考虑响应时间、并发性等其他因素。在一些高并发的系统中,除了QPS外,还可能关注每个请求的响应时间以及系统的可靠性。
Redis
- 安装:https://blog.csdn.net/shuryuu/article/details/111950157
- 自带的工作负载是redis上线前对redis单机、哨兵、cluster的压力测试————redis-benchmark.不用下载直接都自带https://www.cnblogs.com/haha029/p/15610140.html
- memtier_benchmark是基于Redis Labs推出的多线程压测工具。https://blog.csdn.net/u010503464/article/details/129855319(也包含一些redis基本操作,很详细)
- 在第3步中的生成配置文件时报错:
configure: error: Package requirements (libssl) were not met:No package 'libssl' found
等后面部分报错让你自己把libssl路径加上去。but我找不到我的,甚至都不知道安装没有,sudo apt-get install libssl-dev会安装libssl-doc,libssl1.0.0,zlib1g,zlib1g-dev再次运行就OK了。 - 在make install的时候会在/user下创建以一些文件,报错说权限不够,加上sudo就没有报错了。
- 验证表示安装成功。
测试案例可以参照:https://www.cnblogs.com/haha029/p/15610140.html
Memcached
转载自https://www.lxlinux.net/5406.html
- 安装Memcached
sudo apt install memcached libmemcached-tools
- 查看memcached服务状态
sudo systemctl status memcached
YCSB
YCSB:雅虎推出的云数据库基准测试套件。
参考论文[MULTI-CLOCK: Dynamic Tiering for Hybrid Memory Systems]使用的数据库是Memcached,测量内存吞吐量和延时。
运行工作负载 6 个步骤
核心工作负载包属性
下载工作包
配置和性能开销
ycsb-0.15.0/bin/ycsb load memcached -s -P ycsb-0.15.0/workloads/workloada -p "memcached.hosts=127.0.0.1" -p "memcached.port=11211" -p recordcount=1000000000 -threads 64
ycsb load memcached:指示 YCSB 工具加载数据到 memcached 数据库中。
s:指示 YCSB 工具以同步模式执行操作。
ycsb-0.15.0/workloads/workloada:指定要使用的工作负载配置文件。
“memcached.hosts=127.0.0.1”:指定 memcached 服务器的主机地址。
“memcached.port=11211”:指定 memcached 服务器的端口号。
recordcount=1000000000:指定要加载到数据库中的记录数量,这里是 10 亿条记录。
threads 64:指定加载数据时使用的线程数量为 64。
ycsb-0.15.0/bin/ycsb run memcached -s -P ycsb-0.15.0/workloads/workloada -p "memcached.hosts=127.0.0.1" -p "memcached.port=11211" -p recordcount=1000000000 -p operationcount=666666667 -threads 64
- operationcount:指定要执行的操作数量。在这个命令中,operationcount=666666667 表示要执行大约 6.67 亿个操作。
考虑适当增大recordcount和operationcount,以更全面地测试Memcached在当前操作系统上的性能表现。但需要注意,如果设置太大可能会耗尽系统内存导致测试结束。threads可以适当增大,比如从64增到128或256线程。在增大测试负载的参数时,需要留意系统的CPU和内存使用情况。如果CPU使用率已接近100%,或者内存使用量已接近操作系统总容量,则继续增大参数意义不大,对测试结果也没有帮助。
对于内存数据库如Memcached来说,其性能瓶颈主要存在以下几个方面:
- 内存容量瓶颈。当数据库中的数据量大于系统可用内存时,会频繁触发淘汰机制(swap),导致性能下降。
- 内存带宽瓶颈。如果内存读写带宽不能满足数据库的需求,也会限制数据库的性能。
- 锁争用。高并发场景下数据库内部的数据结构和访问存在争用,可能会引起线程阻塞。
- 缓存击穿、穿透。缓存未命中可能导致数据库压力剧增。
设计原理
目标是检查广泛的工作负载特征,以便了解工作负载系统的哪些部分表现良好或较差。例如,某些系统可能针对读取进行了高度优化,但不针对写入进行高度优化,或者针对插入进行了高度优化,但不针对更新进行了优化,或者针对扫描进行了高度优化,但不针对点查找进行了高度优化。选择核心包中的工作负载是为了直接探索这些权衡。
- Insert:插入一条新记录
- Update:通过替换一个字段的值来更新记录
- Read:读取一条记录,随机选择一个字段或所有字段
- Scan:从随机选择的记录键开始按顺序扫描记录。要扫描的记录数是随机选择的
执行以上操作的随机分布情况:
- 统一:随机统一选择一个项目。例如,当选择一条记录时,数据库中的所有记录都有同等可能被选择。
- Zipfian:根据Zipfian 分布选择一个项目。例如,在选择记录时,某些记录将非常受欢迎(分布的头部),而大多数记录将不受欢迎(分布的尾部)。
- 最新:与Zipfian 分布类似,只不过最近插入的记录位于分布的头部。
- 多项式:可以指定每个项目的概率。例如,我们可以为读取操作分配 0.95 的概率,为更新操作分配 0.05 的概率,为扫描和插入分配 0 的概率。结果将是读取繁重的工作负载。
提供的工作负载基准的区别:安装和运行
安装Java
总的一句命令可以直接sudo apt install openjdk-8-jdk
直接用安装JDK的命令也行,会把JRE也安装上的。8版本兼容会好一些,11版本是最新的。
- 检查是否已安装Java
java -version
- 如果没有执行安装命令
apt install openjdk-11-jre-headless
命令安装Java运行时环境(JRE)这将允许运行几乎所有Java软件。 - 验证一下安装上了没
java -version
- 还需要Java DevelopmentKit(JDK)才能编译和运行某些特定的基于Java的软件,验证是否已安装JDK
javac -version
- 安装JDK命令
apt install openjdk-11-jdk-headless
- 再次检查Java编译器的javac版本,来验证是否已安装JDK
javac -version
- 设置JAVA_HOME环境变量,许多使用Java编写的程序使用JAVA_HOME环境变量来确定Java安装位置。首先确定Java的安装位置。使用update-alternatives命令:
sudo update-alternatives --config java
此命令显示Java的每个安装及其安装路径 - 复制路径然后使用文本编辑器打开
sudo gedit /etc/environment
- 在此文件的末尾,添加以下行或者替换已有路径,修改此文件将为系统上的所有用户设置JAVA_HOME路径。
但是可能会出现如下报错,在运行脚本时,通过最后一项报错,可以发现最后两段路径/bin/java可能是脚本自己加上去的或者这个工作负载某处规定的,所以这里我们在文件里只添加前半部分。JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64/bin/java"
JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"
- 保存文件并退出编辑器。
- 重新加载此文件
source /etc/environment
- 验证是否已设置环境变量
echo $JAVA_HOME
这部分转载自https://www.jianshu.com/p/5a25b9535016
如果不小心装错了,可以参照如下方式卸载:
- 首先,检查是安装的哪个 OpenJDK包
dpkg --list | grep -i jdk
- 移除 openjdk包
apt-get purge openjdk*
- 卸载 OpenJDK 相关包
apt-get purge icedtea-* openjdk-*
- 检查所有 OpenJDK包是否都已卸载完毕
dpkg --list | grep -i jdk
这部分转载自https://www.cnblogs.com/jaysonteng/p/13453244.html
修改YCSB脚本文件
在这篇论文的仓库里其实已经有脚本了,但是由于multi-clock内核的Python版本问题,要想运行需要做一些修改。在正常的内核上面运行整个程序是不用改的。通过报错信息可以看到文件位于路径:ycsb-0.15.0/bin/ycsb
第一句,改为python3:
全局查找>>替换为括号
抛出错误的逗号分隔改为as
运行YCSB脚本
原论文的路径看一看,脚本应该放在放ycsb-0.15.0文件夹的地方,和它同级。
脚本第一句#! /bin/sh
有的脚本第一句是不完整的
运行该脚本的命令./run_ycsb_workloads.sh
图计算
GAPBS
GAP基准测试套件旨在通过标准化评估来帮助图形处理研究。图形处理评估之间的差异越小,就越容易比较不同的研究工作和量化改进。构建图形最多可能需要 8 小时。构建输入图形后,您可以删除以释放一些磁盘空间。执行基准测试本身只需要几个小时。github下载工作负载和快速入门
构建
下载:
wget https://github.com/sbeamer/gapbs/archive/refs/heads/master.zip
unzip master.zip
单独来跑的话:
- 构建项目:
make
- 覆盖默认C++编译器:
CXX=g++-8 make
- 测试构建:
make test
- 在 1,024 个顶点上运行 BFS 进行 1 次迭代:
./bfs -g 10 -n 1
自动执行基准测试:
- 构建输入图:
make bench-graphs
- 执行基准测试套件:
make bench-run
从发布官网上看具体图的数据The graph loading infrastructure understands the following formats:
- .el plain-text edge-list with an edge per line as node1 node2每行包含一个边,格式为
node1 node2
,这种格式通常用于无向图,因为它没有指定边的方向。 - .wel plain-text weighted edge-list with an edge per line as node1 node2 weight每行包含一个边,格式为
node1 node2 weight
,其中weight
表示边的权重。 - .gr 9th DIMACS Implementation Challenge format这种格式可以用于无向图,但具体是否无向取决于文件内容和DIMACS挑战的具体实现。
- .graph Metis format (used in 10th DIMACS Implementation Challenge)这种格式通常用于无向图,但同样,是否无向取决于文件的具体内容和实现。
- .mtx Matrix Market format
- .sg serialized pre-built graph (use converter to make)
- .wsg weighted serialized pre-built graph (use converter to make)格式是序列化预构建图的格式,它们可能包含权重信息(在
.wsg
中),但不一定是无向图,这取决于原始图的结构。
在bench.mk的文件中加载新增的命令格式构建出需要的图:
.PHONY: gen-twitter
gen-twitter: ${RAW_GRAPH_DIR} ${GRAPH_DIR}/twitter.sg
.PHONY: gen-web
gen-web: ${RAW_GRAPH_DIR} ${GRAPH_DIR}/web.wsg
.PHONY: gen-road
gen-road: ${RAW_GRAPH_DIR} ${GRAPH_DIR}/road.wsg
运行
不同类型的图算法支持的输入图和操作有些不一样:
root@PowerEdge-R750:/home/ssd/workloads/gapbs# ./bfs --help
./bfs: invalid option -- '-'
breadth-first search
-h : print this help message
-f <file> : load graph from file
-s : symmetrize input edge list [false]
-g <scale> : generate 2^scale kronecker graph
-u <scale> : generate 2^scale uniform-random graph
-k <degree> : average degree for synthetic graph [16]
-m : reduces memory usage during graph building [false]
-a : output analysis of last run [false]
-n <n> : perform n trials [16]
-r <node> : start from node r [rand]
-v : verify the output of each run [false]
-l : log performance within each trial [false]
-h:打印帮助信息。
-f <file>:从指定的文件加载图。这个文件应该包含图的结构信息。
-s:将输入的边列表对称化。如果图不是对称的,这个选项会生成一个对称的图。
-g <scale>:生成一个2^scale阶的Kronecker图。Kronecker图是一种多尺度的随机图模型,常用于模拟现实世界中的网络。
-u <scale>:生成一个2^scale阶的均匀随机图。均匀随机图是一种每个节点都以相同概率连接到其他节点的图。
-k <degree>:为合成图设置平均度数。这个参数用于控制生成的随机图的平均连接度数。
-m:在构建图时减少内存使用。这个选项可能会牺牲一些性能以节省内存。
-a:输出最后一次运行的分析。这可能包括搜索过程中的一些统计信息。
-n <n>:执行n次试验。这个选项允许程序运行多次搜索,以获取平均性能或结果。
-r <node>:从指定的节点r开始搜索。如果不设置,程序可能会随机选择一个起始节点。
-v:验证每次运行的输出。这个选项可能用于确保搜索结果的正确性。
-l:在每次试验中记录性能。这可能包括记录搜索的时间、节点访问次数等。
root@PowerEdge-R750:/home/ssd/workloads/gapbs# ./pr -h
pagerank
-h : print this help message
-f <file> : load graph from file
-s : symmetrize input edge list [false]
-g <scale> : generate 2^scale kronecker graph
-u <scale> : generate 2^scale uniform-random graph
-k <degree> : average degree for synthetic graph [16]
-m : reduces memory usage during graph building [false]
-a : output analysis of last run [false]
-n <n> : perform n trials [16]
-r <node> : start from node r [rand]
-v : verify the output of each run [false]
-l : log performance within each trial [false]
-i <i> : perform at most i iterations [20]
-t <t> : use tolerance t [0.000100]
-i <i>:执行最多i次迭代。PageRank计算通常会迭代直到收敛,但这个选项允许你限制迭代的次数。
-t <t>:使用容差t。这是PageRank算法中判断是否收敛的容差值。当变化小于这个值时,算法可能会停止迭代。
root@PowerEdge-R750:/home/ssd/workloads/gapbs# ./cc -h
connected-components-afforest
# 和bfs一样
# tc参数同上
/home/ssd/workloads/gapbs$ ./bc -h
betweenness-centrality
# 同上
-i <i> : perform i iterations [1]
# sssp参数
-d <d> : delta parameter [1]
graph500
- 只要您的PATH中加载了有效的 MPI-3 库,编译就应该非常简单。不再有OpenMP、Sequential和XMT版本的基准测试。
- 要构建二进制文件,请将目录更改为src并执行make。
graph500_reference_bfs
运行BFS内核(并跳过权重生成);graph500_reference_bfs_sssp
同时运行BFS和SSSP内核。- 如果您的环境中存在SKIP_BFS=1,bfs_sssp二进制文件将跳过BFS部分。
- 如果要在文件中存储/读取生成的图形,请使用环境变量
TMPFILE=<文件名>
以及REUSEFILE=1
来保留文件。 - 建议使用
bfs_sssp
二进制文件生成图形文件,因为它会生成边和权重文件(文件名.权重)。bfs
二进制文件只会使用/写入边缘文件。一旦bfs_sssp
无法打开权重文件,即使存在边文件,它也会生成这两个文件。
当前设置假设您使用 2 的幂:核心总数和每个节点的核心数量。
如果您注释 common.h SIZE_MUST_BE_POWER_OF_TWO 中定义的宏,则可能使用非2的幂节点数。
请注意,通常这会使您的性能下降 20% 以上。
如果要在每个节点使用两个进程的非幂,则应将 -DPROCS_PER_NODE_NOT_POWER_OF_TWO 添加到 src/Makefile 中的 CFLAGS,这将自动启用 SIZE_MUST_BE_POWER_OF_TWO。
对于 GreenGraph500 运行,定义编译时宏 ENERGYLOOP_BFS 或 ENERGYLOOP_SSSP 来测量足够长的循环中的能量以测量平均功率。
AML 是建立在 MPI3 基础上的 SPMD 通信库
bfs_custom.c 是使用参考数据结构和基础架构编写自己的 BFS 的模板。您可以就地修改该文件,或复制它(调整 Makefile)创建自己的版本。复制它(调整 Makefile)以创建自己的版本。 文档中的注释,说明有哪些数据结构可用以及如何使用它们。
- 生成的程序名为
graph500_mpi_*
,最多采用两个参数:问题的规模和边缘因素,问题的尺度是对数以 2 为底,图中的顶点数;仅具有2次幂的图无需修改源代码即可支持顶点计数。 - 边缘因子是边数与顶点数的比率;即,它是一半图中的平均顶点度数。比例参数为必填项;这边缘因子是可选的,默认为16。运行任何不带任何参数的
graph500_*
程序都会产生使用消息。
mpicc编译src里面的文件,生成可运行的文件。
运行时直接使用那个文件,同时加上规模和边的参数比如/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libpthread.so: error adding symbols: DSO missing from command line # makefile: LDFLAGS = "-Wl,--copy-dt-needed-entries,-lpthread"
-s 22 -e 16
一个可以参考的脚本:mpiexec -n 32 ./graph500_reference_bfs 32 16
#!/bin/bash set -e set -x if [ "$1" = 'graph500_reference_bfs' ]; then /root/graph500/src/graph500_reference_bfs $2 $3 elif [ "$1" = 'graph500_reference_bfs_sssp' ]; then /root/graph500/src/graph500_reference_bfs_sssp $2 $3 else exec "$@" fi
HPC
一些高性能计算workload也是需要很多内存。
NAS 并行基准测试 (NPB)
0.NPB中每个基准测试程序有7类问题规模,分别为S、WA、B、C、D和E。其中A类规模最小,S(Sample)类是样例程序,W(Workstation)类通常用于工作站。
1.EP(Embarrassingly parallel),繁杂并行,用于计算Gauss伪随机数,主要执行浮点数计算,EP的显著特点是不执行任何处理器间的通信,因此用不同的互相连接得到的结果显示同样的执行特点。(但是属于计算密集,内存)
2.快速Fourier转换(FT)检测长距离通信,利用快速傅里叶变换来解决3维的偏微分方程。
3.CG(Conjugate Gradient)用于求解大型稀疏对称正定矩阵的最小特征值的近似值。
4.LU(Lower upper triangular)用于基于对称超松弛法求解块稀疏方程组。
5.SP(scalar penta-diagonal)用于求解5对角线方程组(特别慢,放最后)
6.BT(Block Tri-Diagonal)用于求解3对角线方程组(特别慢,放最后)
算法概述
CG - 共轭梯度
在CG算法中,由于问题的稀疏性质,存在不规则的内存访问和通信模式。这意味着不同计算节点在访问和处理矩阵数据时可能需要跨越不同的内存位置,并且节点之间的通信操作可能会涉及不同数量的数据传输。CG算法的性能评估主要关注并行计算和通信的效率,以及处理不规则访问模式的能力。
CG算法在迭代过程中涉及矩阵向量乘法和内积计算。这些操作通常具有较好的局部性特征,尤其是空间局部性。在矩阵向量乘法中,由于稀疏矩阵的性质,只有非零元素才会被访问和处理。这种局部性使得算法能够有效地利用缓存,因为只有涉及到非零元素的内存位置才会被频繁访问。在内积计算中,通常需要对向量进行元素的逐个相乘,并对结果进行累加。这种操作模式充分利用了时间局部性,因为计算的结果可以在寄存器或高速缓存中重复使用,而不需要频繁地从内存中加载数据。
BT - 三对角矩阵的分块求解
三对角矩阵分块分配给不同的计算节点。每个节点负责处理一个或多个矩阵块,并在计算过程中与其他节点进行通信以满足数据依赖关系。分块矩阵求解:在BT算法中,每个计算节点需要对其分配的矩阵块进行求解。这涉及到对每个块矩阵进行扫描,按照三对角矩阵求解的方法,更新块矩阵中的值。边界值更新:在每个迭代步骤中,节点之间需要进行通信以更新边界值。这是因为块矩阵之间的边界值在求解过程中会相互影响。节点之间通过消息传递来交换边界值,并保持数据的一致性。收敛判据:在每次迭代之后,需要检查解向量的收敛情况。通常,会计算残差向量的范数,并与预先定义的收敛阈值进行比较,以确定是否终止迭代。更新解向量:根据求解过程的结果,使用先前计算得到的值更新解向量。
在每个节点上,块矩阵的元素在内存中是连续存储的。边界值的交换这种通信操作通常是局部的,即只涉及节点之间的边界区域数据的传输。
运行
- 下载方式:https://www.nas.nasa.gov/software/npb.html往下划
- 安装对应的编译器呀, MPI安装:这个相当于把readme翻译了。遇到没有fortran的报错时也再安装一个:最简单的安装步骤。
- 在进入NPB3.4-MPI/OMP后在readme.install中有编译和运行的介绍,还会发现有测试脚本可以参考,config文件夹放的是参考的配置。
- 编译,首先需要一个make.def的配置文件可以从模板里拿一个。这里的参考是对MPI的使用。
- 运行指令,在使用时,先编译指定用哪个程序算法、问题规模和处理器个数,之后会在bin文件下生成可执行文件,直接跑就行。比如SWABCDE是指问题规模,EP,MG,IS,CG是指要运行的程序算法。
执行的时候选择工作负载,详细参考官方:https://www.nas.nasa.gov/software/npb.html
编译:
cd NPB2.4.1
make IS CLASS=A NPROCS=2
执行:
cd NPB2.4.1/bin
HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so ./cg.D.x >> ./cgd.out
# 或者
mpirun -np 4 ./cg.D.x
测试:
sudo perf stat -e cpu-cycles,cache-misses,cache-references,page-faults,major-faults,minor-faults -a -p
sh ./mem.sh
cat /proc/5852/status | grep -A 1 VmHWM
PARSEC
https://blog.csdn.net/weixin_43124861/article/details/102913343
官方的下载安装方法:https://parsec.cs.princeton.edu/parsec3-doc.htm
配置环境:
source env.sh
每次关机后都要设置一下
麻烦的在于native模式的输入要额外移动过去
要做的测试SPLASH-2 高性能测试用的,运行了这下面所有的工作负载(只能运行test)SPLASH-2X部分有native
安装:
parsecmgmt -a build -p bodytrack -c gcc-tbb
parsecmgmt -a build -p blackscholes
有的时候编译报错,是缺库
sudo apt install -y libtbb2 tbb-examples
执行:
# 参数 -p 是指明 -a 操作的模块 , 当前是 blackscholes 模块, 和图像有关的工作负载用gcc-tbb编译,-c gcc-serial 编译加了运行也要加
HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so parsecmgmt -a run -p splash2x.radiosity -i native >> ./parsec1GB/radiosity.out
# -i 是输入参数,输入有test ,simdev ,simlarge ,native ,...
工作负载类型参考:https://parsec.cs.princeton.edu/parsec3-doc.htm
https://parsec.cs.princeton.edu/download/tutorial/3.0/parsec-tutorial.pdf
MG(MultiGrid)多栅格基准测试,监测短距和长距离通信。MG是一个简化的多栅格核心。IS(Integer sort)用于求解基于桶排序的二维大整数排序。
SPEC
首先是向这个组织申请,然后获得权限下载4组workoad,但是有时间限制要在一个月内装好。
SPEC ACCEL
重点关注使用硬件加速(此处称为“加速器”)的高度并行计算密集型应用程序的性能。这些基准测试强调以下性能:
- 加速器
- 主机CPU
- 主机和加速器之间的内存传输
- 支持库和驱动程序
- 编译器
SPEC ACCEL 包含一个专注于使用 OpenCL 1.1、OpenMP 4.5 和 OpenACC 1.0 标准的并行计算性能的套件。SPEC ACCEL 用户文档详细介绍了安装和使用。readme会告诉基本步骤。
XSBench
蒙特卡罗中子传输算法的一个关键计算内核,是在高性能计算架构上进行性能分析的有用工具。
配置还挺简单的:https://github.com/ANL-CESAR/XSBench
CloudSuite 4.0
CloudSuite 4.0安装地址
按照readme的命令运行,如果没有镜像会自动去下载docker container ls -a
命令可以查看所有已经创建的包括终止状态的容器。
运行data-analysis
直接网上pull的镜像有点问题,会报错因为没有java库等原因
下载压缩包后里面的Dockerfile是定制镜像,可以自己构建镜像
docker build -t cloudsuite/data-analytics:latest .
docker build [选项] <上下文路径/URL/->
# 镜像的名称 -t cloudsuite/data-analytics,latest是个tag
# 用户会指定构建镜像上下文的路径,build将路径下的所有内容打包,然后上传给Docker引擎
DLRM
推荐系统也是耗费内存的一直常见应用,这个配置和运行也比较简单。
facebookresearch/dlrm: An implementation of a deep learning recommendation model (DLRM)