服务器性能分析

简介:
## 安装 sysbench
wget https://codeload.github.com/akopytov/sysbench/zip/master

unzip master
cd sysbench-master/
./autogen.sh
./configure  --prefix=/usr/local/sysbench
make
make install

## 测试磁盘读写
 yum install fio    -y    注意:**不要对有数据的磁盘或者分区做测试,会破坏已存在的数据**

##
yum install mtr sysstat  -y
cd /usr/local/sysbench/bin/

./sysbench   cpu run

CPU speed:  ## 速度
    events per second:   720.34      ##每秒事件

Throughput:   ##吞吐量
    events/s (eps):                      720.3381      ##每秒事件
    time elapsed:                        10.0009s      ##已用时间
    total number of events:              7204          ##事件总数

Latency (ms): ##延迟 
         min:                                  1.21    ##最小
         avg:                                  1.39    ##平均
         max:                                  1.71    ##最大
         95th percentile:                      1.50    ##按照95值计算
         sum:                               9990.46    ##总和

Threads fairness:  ## 线程排期
    events (avg/stddev):           7204.0000/0.00   ## 时间
    execution time (avg/stddev):   9.9905/0.00   ##执行时间

./sysbench   memory  run  

Total operations: 13937010 (1393663.92 per second)  ##总的操作

13610.36 MiB transferred (1361.00 MiB/sec)   ##   每秒移动速度

Throughput:  ## 吞吐量
    events/s (eps):                      1393663.9154
    time elapsed:                        10.0003s
    total number of events:              13937010

Latency (ms):   ##延迟
         min:                                  0.00
         avg:                                  0.00
         max:                                  0.18
         95th percentile:                      0.00
         sum:                               3829.60

Threads fairness:
    events (avg/stddev):           13937010.0000/0.00
    execution time (avg/stddev):   3.8296/0.00

磁盘IO 在进行下列测试前,请确保磁盘已经 4K 对齐。

测试随机写IOPS:
fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Write_Testing
测试随机读IOPS:
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Read_Testing

测试写吞吐量:
fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Write_PPS_Testing
测试读吞吐量:
fio -direct=1 -iodepth=64 -rw=read -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Read_PPS_Testing

上述测试时 fio 相关参数说明:

-direct=1
测试时忽略 IO 缓存,数据直写。

-rw=randwrite
测试时的读写策略,可选值 randread (随机读)、 randwrite(随机写)、 read(顺序读)、 write(顺序写)、 randrw (混合随机读写)。

-ioengine=libaio
测试方式使用 libaio (Linux AIO,异步 IO)。 应用使用 IO 通常有二种方式:同步和异步。同步的 IO 一次只能发出一个 IO 请求,等待内核完成才返回。这样对于单个线程 iodepth 总是小于 1,但是可以透过多个线程并发执行来解决。通常会用 16-32 根线程同时工作把 iodepth 塞满。 异步则通常使用 libaio 这样的方式一次提交一批 IO 请求,然后等待一批的完成,减少交互的次数,会更有效率。

-bs=4k
单次 I/O 的块文件大小为 4k。未指定该参数时的默认大小也是 4k。

-size=1G
测试文件大小为 1G。

-numjobs=1
测试线程数为 1。

-runtime=1000
测试时间为 1000 秒。如果未配置则持续将前述 -size 指定大小的文件,以每次 -bs 值为分块大小写完。

-group_reporting
测试结果显示模式,group_reporting 表示汇总每个进程的统计信息,而非以不同 job 汇总展示信息。

-filename=/dev/[device]
指定测试文件(设备)的名称。测试裸盘可以获得真实的磁盘性能,但直接测试裸盘会破坏文件系统结构,请在测试前提前做好数据备份。

-name=Rand_Write_Testing
测试任务名称。
例如:
write: io=1024.0MB, bw=6355.9KB/s, iops=1588, runt=164979msec

表示fio做了1 GB I/O,速率约为6 MB/s,总IOPS为1588,运行时间为164秒。由IOPS值可知,该SSD云盘的IOPS性能为 1588.
DNS测试
dig  www.qq.com
;; Query time: 3 msec

外网网络延迟和丢包率测量    mtr

[root@111 ~]#  mtr -r  42.62.55.58  -c 15
Start: Fri Dec 29 11:35:03 2017
HOST: 111                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 42.62.55.58                0.0%    15    0.3   0.3   0.3   0.4   0.0

第二列:snt:10 设置追踪的次数,默认值是10 可以通过参数 -c来定制,例如mtr -r -c 15 202.108.33.94
第三列 Loss: 是显示的每个对应IP的丢包率
第四列 Last: 显示的最近一次的返回时延
第五列 Avg : 是平均值 这个应该是发送ping包的平均时延
第六列 Best: 是最好或者说时延最短的
第七列 Wrst: 是最差或者说时延最常的
第八列 StDev: 是标准偏差









本文转自 295631788 51CTO博客,原文链接:http://blog.51cto.com/hequan/2055809,如需转载请自行联系原作者
目录
相关文章
|
7月前
|
存储 监控 Java
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Counter篇)
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Counter篇)
164 0
|
XML 数据挖掘 Linux
服务器丨Linux安装测试单细胞分析软件copykat,遇到的常见报错与解决思路与方法
服务器丨Linux安装测试单细胞分析软件copykat,遇到的常见报错与解决思路与方法
|
7月前
|
监控 算法 Java
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Gauge和Histogram篇)
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Gauge和Histogram篇)
97 0
|
6月前
|
监控 关系型数据库 MySQL
|
2月前
|
机器学习/深度学习 弹性计算 缓存
阿里云服务器经济型e实例与通用算力型u1实例对比分析与选择指南
在阿里云服务器的实例规格中,经济型e实例和通用算力型u1实例是很多个人和普通企业级用户常见的选择,经济型e实例与通用算力型u1实例的主要区别在于性能、应用场景及价格策略。本文将详细对比这两种实例的性能、应用场景及价格策略,以供参考。
|
2月前
|
人工智能 运维 Kubernetes
87cloud案例分析:阿里云国际服务器如何支持在线教育
87cloud案例分析:阿里云国际服务器如何支持在线教育
|
2月前
|
弹性计算 安全 Linux
阿里云国际版ECS云服务器ping不通的原因分析
阿里云国际版ECS云服务器ping不通的原因分析
|
2月前
|
域名解析 弹性计算 缓存
阿里云国际云服务器全局流量分析功能详细介绍
阿里云国际云服务器全局流量分析功能详细介绍
|
3月前
|
存储 安全 算法
服务器数据恢复—Raid磁盘阵列的安全性分析及常见故障
出于尽可能避免数据灾难的设计初衷,RAID解决了3个问题:容量问题、IO性能问题、存储安全(冗余)问题。从数据恢复的角度讨论RAID的存储安全问题。 常见的起到存储安全作用的RAID方案有RAID1、RAID5及其变形。基本设计思路是相似的:当部分数据异常时,可通过特定算法将数据还原出来。以RAID5为例:如果要记录两个数字,可以通过再多记录这两个数字的和来达到记录冗余性的目的。例如记录3和5,同时再记录这2个数字的和8。在不记得到底是几和5的情况下,只需要用8-5就可以算出这个丢失的数字了,其余情况依此类推。
|
4月前
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
72 0