UnixBench算分介绍

关于如何用UnixBench，介绍文章很多，这里就不展开了。这里重点描述下它是如何算分的。

运行参数
碰到很多客户，装好后，直接./Run，就把结果跑出来了，然后还只取最后一个分值，比谁高谁低。
下面列一下4C8G的结果：


Benchmark Run: 一 6月 25 2018 20:25:47 - 20:54:19
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 30971628.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3928.1 MWIPS (12.4 s, 7 samples)
Execl Throughput 3117.6 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 645027.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 229505.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1288742.6 KBps (30.0 s, 2 samples)
Pipe Throughput 1635960.9 lps (10.0 s, 7 samples)
Pipe-based Context Switching 337333.8 lps (10.0 s, 7 samples)
Process Creation 8238.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 5817.0 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2183.9 lpm (60.0 s, 2 samples)
System Call Overhead 2465754.7 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 30971628.9 2654.0
Double-Precision Whetstone 55.0 3928.1 714.2
Execl Throughput 43.0 3117.6 725.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 645027.2 1628.9
File Copy 256 bufsize 500 maxblocks 1655.0 229505.4 1386.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 1288742.6 2222.0
Pipe Throughput 12440.0 1635960.9 1315.1
Pipe-based Context Switching 4000.0 337333.8 843.3
Process Creation 126.0 8238.2 653.8
Shell Scripts (1 concurrent) 42.4 5817.0 1371.9
Shell Scripts (8 concurrent) 6.0 2183.9 3639.9
System Call Overhead 15000.0 2465754.7 1643.8

System Benchmarks Index Score 1362.9


Benchmark Run: 一 6月 25 2018 20:54:19 - 21:22:54
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables 114984418.6 lps (10.0 s, 7 samples)
Double-Precision Whetstone 16614.2 MWIPS (11.6 s, 7 samples)
Execl Throughput 13645.3 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 751698.4 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 230211.7 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1964420.6 KBps (30.0 s, 2 samples)
Pipe Throughput 5999380.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1095000.2 lps (10.0 s, 7 samples)
Process Creation 34454.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 18218.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2493.1 lpm (60.0 s, 2 samples)
System Call Overhead 5643267.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 114984418.6 9853.0
Double-Precision Whetstone 55.0 16614.2 3020.8
Execl Throughput 43.0 13645.3 3173.3
File Copy 1024 bufsize 2000 maxblocks 3960.0 751698.4 1898.2
File Copy 256 bufsize 500 maxblocks 1655.0 230211.7 1391.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 1964420.6 3386.9
Pipe Throughput 12440.0 5999380.0 4822.7
Pipe-based Context Switching 4000.0 1095000.2 2737.5
Process Creation 126.0 34454.9 2734.5
Shell Scripts (1 concurrent) 42.4 18218.1 4296.7
Shell Scripts (8 concurrent) 6.0 2493.1 4155.1
System Call Overhead 15000.0 5643267.3 3762.2

System Benchmarks Index Score 3357.0
很多人就拿了3357那个分数去比了，但是上面那个单进程结果1362.9也有意义，但凡接触了这么多案例，没人关心过。多进程结果就是根据系统CPU核数，同时起多个进程的结果；单进程就是只起一个进程的结果，对于系统性能来说，两个结果都是有意义的。

话说回来，./Run 到底执行了什么？默认执行的是Index模块，它包含下面几个小程序：

"dhry2reg", "whetstone-double", "execl"，
"fstime", "fsbuffer", "fsdisk", "pipe", "context1", "spawn", "shell1", "shell8","syscall"

对应的就是上面的结果的各个结果对应的case了。
翻看了下它的源代码，它的执行参数如下：./Run 模块 -i 迭代次数 -c 进程并发数 -q/-v (输出方式。

模块：有时候你只想测某一个小程序的结果，那你可以修改自己去新增一个模块，修改测试内容，这对于调试是非常方便的，也可以直接指定某个执行程序。
迭代次数：关于迭代次数，不能想当然的就理解成这就是要执行的次数了，默认框架分为两种迭代模式，一种是短迭代次数，默认 3次，一种是 长迭代次数，默认10 次。那输入的迭代次数就是默认的长迭代次数，短迭代次数=(迭代次数+1)/3,如果结果小于就是1. 程序配置好了，该选择哪个迭代次数。
进程并发数：如果你想进程并发数不是系统CPU数，那就可以通过这个调整；
输出方式：是静默还是详细输出方式；
算分
每个小程序在执行的时候都需要指定迭代模式和执行时间以及并发情况，所有的进程一次执行的结果都是统一模式。

单进程算分：
下面是单进程的一个举例：

Process Creation -- 1 copy
==> "/opt/unixbench/UnixBench/pgms/spawn" 30 2>&1 >> "/opt/unixbench/UnixBench/results/VM_0_13_centos-2018-06-25-05.log"

Pass 1

COUNT0: 247371 #分数

COUNT1: 1 # timebase 程序写死

COUNT2: lps # 测试项名称

elapsed: 30.003119 # 耗时

pid: 16803 # 进程ID

status: 0 # 是否成功退出

Pass 2

COUNT0: 242919

COUNT1: 1

COUNT2: lps

elapsed: 30.002898

pid: 5035

status: 0

Pass 3

COUNT0: 243989

COUNT1: 1

COUNT2: lps

elapsed: 30.002732

pid: 21228

status: 0

*Dump score: 242919.0
Count score: 243989.0
Count score: 247371.0

>>> Results of 1 copy
>>> score: 8188.34084738901
>>> time: 30.0029255
>>> iterations: 2
其中COUNT0，COUNT1，COUNT2是这么算出来的，每个进程的结果如：

COUNT|x|y|x
经过解析，变成如下：

COUNT0 = x
COUNT1 = y
COUNT2 = z

算分过程如下：

根据COUNT0从小到大，去掉 1/3 的最差结果；
如果timebase，耗时都是大于0， $product += log($COUNT0) - log(耗时/ $timebase) 否则就不需要考虑耗时这块： $product += log($COUNT0)
单项性能分：$score = exp($product/2),2是统计的迭代次数，经过计算恰好是这个分数，与系统输出一致。
它总的算法思想：就是先通过log降维，把不同次数不一样的结果尽可能拉平，平均然后在阶乘，后面多个结果也是这个思想，先降维，再平均，再阶乘。
多进程算分
那如果并发执行多个呢？举例如下：

Shell Scripts (1 concurrent) -- 4 copies
==> "/opt/unixbench/UnixBench/pgms/looper" 60 "/opt/unixbench/UnixBench/pgms/multi.sh" 1 2>&1 >> "/opt/unixbench/UnixBench/results/VM_0_13_centos-2018-06-25-05.log"

Pass 1

COUNT0: 4614

COUNT1: 60

COUNT2: lpm

elapsed: 60.005639

pid: 20858

status: 0

COUNT0: 4596

COUNT1: 60

COUNT2: lpm

elapsed: 60.009496

pid: 20859

status: 0

COUNT0: 4592

COUNT1: 60

COUNT2: lpm

elapsed: 60.011761

pid: 20862

status: 0

COUNT0: 4614

COUNT1: 60

COUNT2: lpm

elapsed: 60.011930

pid: 20864

status: 0

Pass 2

COUNT0: 4547

COUNT1: 60

COUNT2: lpm

elapsed: 60.005597

pid: 10791

status: 0

COUNT0: 4590

COUNT1: 60

COUNT2: lpm

elapsed: 60.013270

pid: 10793

status: 0

COUNT0: 4578

COUNT1: 60

COUNT2: lpm

elapsed: 60.006054

pid: 10794

status: 0

COUNT0: 4561

COUNT1: 60

COUNT2: lpm

elapsed: 60.014214

pid: 10797

status: 0

Pass 3

COUNT0: 4631

COUNT1: 60

COUNT2: lpm

elapsed: 60.013816

pid: 31734

status: 0

COUNT0: 4632

COUNT1: 60

COUNT2: lpm

elapsed: 60.012614

pid: 31735

status: 0

COUNT0: 4637

COUNT1: 60

COUNT2: lpm

elapsed: 60.005633

pid: 31737

status: 0

COUNT0: 4645

COUNT1: 60

COUNT2: lpm

elapsed: 60.006082

pid: 31740

status: 0

*Dump score: 18276.0
Count score: 18416.0
Count score: 18545.0

>>> Sum of 4 copies
>>> score: 18477.4244713467
>>> time: 60.009621375
>>> iterations: 2
算分过程如下：

分数：如18545，就是PASS3个项的加总： 4631+4632+4637+4645
耗时：平均值，即：(60.013816+60.012614+60.005633+60.006082)/4=60.00953625
timebase: 还是那个COUNT1
上述3步即是把一个并发结果合成一个结果，然后的积分方式跟单进程的方式一样
总分
那文章开头多进程的图例分数举例：

算出来的每项score有个加权分数，要除以10(作为单项比拼，我觉得除不除10无所谓,估计是为了跟总分接近）
总分计算：=exp(average(每项score分*10)),结果恰恰好就是我们要的结果。

原文地址：http://blog.51cto.com/14031893/2327187

时间： 2024-08-30 08:08:33

UnixBench算分介绍的相关文章

Lucene TF-IDF 相关性算分公式

转自: http://lutaf.com/210.htm Lucene在进行关键词查询的时候,默认用TF-IDF算法来计算关键词和文档的相关性,用这个数据排序 TF:词频,IDF:逆向文档频率,TF-IDF是一种统计方法,或者被称为向量空间模型,名字听起来很复杂,但是它其实只包含了两个简单规则 某个词或短语在一篇文章中出现的次数越多,越相关 整个文档集合中包含某个词的文档数量越少,这个词越重要 所以一个term的TF-IDF相关性等于 TF * IDF 这两个规则非常简单,这就是TF-IDF的核

Lucene TF-IDF 相关性算分公式(转)

Lucene在进行关键词查询的时候,默认用TF-IDF算法来计算关键词和文档的相关性,用这个数据排序 TF:词频,IDF:逆向文档频率,TF-IDF是一种统计方法,或者被称为向量空间模型,名字听起来很复杂,但是它其实只包含了两个简单规则 某个词或短语在一篇文章中出现的次数越多,越相关 整个文档集合中包含某个词的文档数量越少,这个词越重要 所以一个term的TF-IDF相关性等于 TF * IDF 这两个规则非常简单,这就是TF-IDF的核心规则,第二个的规则其实有缺陷的,他单纯地认为文本频率小的

Solr相似度算法一：Lucene TF-IDF 相关性算分公式

Lucene在进行关键词查询的时候,默认用TF-IDF算法来计算关键词和文档的相关性,用这个数据排序 TF:词频,IDF:逆向文档频率,TF-IDF是一种统计方法,或者被称为向量空间模型,名字听起来很复杂,但是它其实只包含了两个简单规则 某个词或短语在一篇文章中出现的次数越多,越相关 整个文档集合中包含某个词的文档数量越少,这个词越重要 所以一个term的TF-IDF相关性等于 TF * IDF 这两个规则非常简单,这就是TF-IDF的核心规则,第二个的规则其实有缺陷的,他单纯地认为文本频率小的

常用搜索引擎的算分，你get了嘛？

搜索引擎发展至今,已公布了多种算法.作为SEOER的你,还不懂,就out啦.懂了不会用,也是然并卵的一种行为.了解算法知识并不懂得如何把算法实践于SEO工作的你,还是处于学生思维,是时候该升级了.且听我介绍这9个算法及用法 NO.1 绿萝算法 算法内容:为了打击买卖外链.批量群发外链的行为.目的,避免站长不用心做用户体验,纯粹的利用搜索引擎漏洞投机取巧,影响搜索引擎自身用户体验.主要打击的网站类型有,超链中介.出售链接网站.购买链接的网站. 实操说明:还不知死活,拼命买卖外链的小伙伴,赶紧收手吧

算分-DESIGN THECHNIQUES

Divide-and-Conquer: 教材中是用快排作为例子介绍分治算法的,主要的是几个式子: 最坏情况下的快排:T(n) = n + T(n-1) 最好情况下的快排:T(n) = n + 2*T((n-1) / 2) 随机情况下的快排:T(n) = n + 1/n * sum(T(i) + T(n-1-i)) for i = 0,1,2,...,n-1 值得一提的是一个尾递归的问题,如果是带有尾递归的话,调用栈的空间占用会达到n的规模,但是取消尾递归且每次调用较小的那一段,调用栈的空间只需要

算分-Searching

Binary Search Trees: BST树里首先讲了插入删除查找等操作,比较常规.查找:最差O(n),最好O(logn),平均O(logn):插入:成功的插入平均O(logn),最差也是O(n):删除里有三种情况,对于一次成功的删除,待删除的结点v的子结点个数只可能是0.1.2,如果是0的话就直接删除无妨,是1的话就把其子结点作为待删除结点的父节点的子结点(原话是:make that child the child of the parent of v),如果有2个子结点的话,就从左子树

算分-PRIORITIZING

Heaps and Heapsort: 堆是一种快速访问最大优先级元素的数据结构,这是快速实现选择排序的基础,但是总体来说平均速度比快排要慢一点,不过其最坏情况和平均情况是差不多的. 首先是堆的定义,每个结点比它的孩子结点都小(所以父节点最小),或者每个结点都比它的孩子结点大(父节点最大),把A[1,n]看做一个堆,i的两个孩子结点分别是2i和2i+1,这个非常方便实用.接着是删除堆的最小值(最大值同理),想法就是先删除最小值,然后把最后一个元素放到根节点并且不断sift-down,这个是一个结

算分-NP COMPLETENESS

Easy and Hard Problems: NP完全理论是为了在可处理的问题和不可处理的问题之间画一条线,目前最重要的问题是是否这两者是本质不同的,而这个问题目前还没有被解决.典型的结果是一些陈述,比如“如果问题B有一个多项式时间的算法,那么C也会有一个多项式时间的算法”,或者逆否表述为“如果C没有多项式时间的算法,那么B也没有”.第二个表述是说,对于一些问题C以及一个新的问题B,我们先去找是否有这种关系,如果有的话我们可能不想去做问题B,先来看看C.为了描述这些东西,需要不少形式主义的记号

elasticsearch 算分脚本

可以将上一章的脚本,放到elasticsearch/config/scripts 目录下,比如命名为my_script.groovy. 然后使用下面的代码进行调用: "script_score" : { "script" : { "file" : "my_script" } } 这个文件夹的文件60s更新一次,可以随时增加或者删除.  script_score 官方网站上存在性能问题,建议使用Native Java Scrip