如何测试sqlserver性能

对于DBA来讲，我们都会做新服务器的性能测试。我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。
下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。
自己写负载测试代码很困难
为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。你不想总是对单一行更新相同的值，或者只是重复插入假的值。
自己动手使用Powershell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。
免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载
HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。你可以使用HammerDB来针对一个数据库生成脚本并导入测试。HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。
首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。你也可以用它来模拟用于示范或研究目的的不同负载。
用于SQL Server上的HammerDB的优缺点
HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。它的自动程序特性也是的运行工作负载相当自动。
主要缺点是它有一个学习曲线。用户界面不是很直观，需要花费时间去习惯。再你使用这个工具一段时间之后，将会更加容易。
HammerDB也不是运行每一个基准测试。它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。但是，它是免费的、快速的、易用的。
基准测试使用案例
基准测试负载不能精确模拟你的应用程序的特点。每个负载是唯一的，在不同的系统有不同的瓶颈。对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：
多个环境（例如：旧的物理服务器，新的虚拟环境）
使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）
在配置改变前后的点
当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。
对于自学和研究来说，有预配置的负载非常棒。
开始使用基准测试
你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。

贴一篇我们内部的文章：
随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？
性能测试一般会围绕以下这些问题而进行：
1 什么情况下需要做性能测试？
2 什么时候做性能测试？
3 做性能测试需要准备哪些内容？
4 什么样的性能指标是符合要求的？
5 性能测试需要收集的数据有哪些？
6 怎样收集这些数据？
7 如何分析收集到的数据？
8 如何给出性能测试报告？
性能测试的执行过程及要做的事儿主要包含以下内容：
1 测试评估阶段
在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。
首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。
测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等
2 测试准备阶段
在这个阶段，我们要了解以下内容：
a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；
b 服务端功能的内部逻辑实现；
c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样 *** 作数据库的？
d 服务端与客户端之间是如何进行交互的，即接口定义；
通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。
e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；
f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。
g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等
h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。
i 沟通上线的指标
通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。
3 测试设计阶段
根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。
用例编写的步骤大致分为：
a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。
b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的 *** 作。
c 验证参数化后脚本功能的正确性。
d 添加检查点
e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等
4 测试执行阶段
根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。
在测试执行过程中，还要不断的关注以下内容：
a web服务的连接速度如何？
b 每秒的点击数如何？
c Web服务能允许多少个用户同时在线？
d 如果超过了这个数量，会出现什么现象？
e Web服务能否处理大量用户对同一个页面的请求？
f 如果web服务崩溃，是否会自动恢复？
g 系统能否同一时间响应大量用户的请求？
h 打压机的系统负载状态。
5 测试分析阶段
将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。
6 测试验证阶段
在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。
想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~

################### cpu性能查看 ############################################################
1、查看物理cpu个数：
cat /proc/cpuinfo |grep "physical id"|sort|uniq|wc -l
2、查看每个物理cpu中的core个数：
cat /proc/cpuinfo |grep "cpu cores"|wc -l
3、逻辑cpu的个数：
cat /proc/cpuinfo |grep "processor"|wc -l
物理cpu个数核数=逻辑cpu个数（不支持超线程技术的情况下）
########################### 内存查看 ################################################################
1、查看内存使用情况：
free -m
total used free shared buffers cached
Mem: 3949 2519 1430 0 189 1619
-/+ buffers/cache: 710 3239
Swap: 3576 0 3576
total：内存总数
used：已经使用的内存数
free：空闲内存数
shared：多个进程共享的内存总额
- buffers/cache：(已用)的内存数，即used-buffers-cached
+ buffers/cache：(可用)的内存数，即free+buffers+cached
Buffer Cache用于针对磁盘块的读写；Page Cache用于针对文件inode的读写，这些Cache能有效地缩短I/O系统调用的时间。
对于 *** 作系统来说free/used是系统可用/占用的内存；而对于应用程序来说-/+ buffers/cache是可用/占用内存,因为buffers/cache很快就会被使用。我们工作时候应该从应用角度来看。
################# 硬盘查看 ##########################################################################
1、查看硬盘及分区信息：
fdisk -l
2、查看文件系统的磁盘空间占用情况：
df -h
3、查看硬盘的I/O性能（每隔一秒显示一次，显示5次）：
iostat -x 1 5
iostat是含在套装systat中的,可以用yum -y install systat来安装。
常关注的参数：
如果%util接近100%,说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
如果idle小于70%，I/O的压力就比较大了，说明读取进程中有较多的wait。
4、查看linux系统中某目录的大小：
du -sh /root
如发现某个分区空间接近用完，可以进入该分区的挂载点，用以下命令找出占用空间最多的文件或目录，然后按照从大到小的顺序，找出系统中占用最多空间的前10个文件或目录：
du -cksh |sort -rn|head -n 10
############################################ 查看平均负载 ####################################
有时候系统响应很慢，但又找不到原因，这时就要查看平均负载了，看它是否有大量的进程在排队等待。
最简单的命令：
uptime
查看过去的1分钟、5分钟和15分钟内进程队列中的平均进程数量。
还有动态命令：
top
我们只关心以下部分：
top - 21:33:09 up 1:00, 1 user, load average: 000, 001, 005
如果每个逻辑cpu当前的活动进程不大于3，则系统性能良好；
如果每个逻辑cpu当前的活动进程不大于4，表示可以接受；
如果每个逻辑cpu当前的活动进程大于5，则系统性能问题严重。
一般计算方法：负载值/逻辑cpu个数
还可以结合vmstat命令来判断系统是否繁忙，其中：
procs
r：等待运行的进程数。
b：处在非中断睡眠状态的进程数。
w：被交换出去的可运行的进程数。
memeory
swpd：虚拟内存使用情况，单位为KB。
free：空闲的内存，单位为KB。
buff：被用来作为缓存的内存数，单位为KB。
swap
si：从磁盘交换到内存的交换页数量，单位为KB。
so：从内存交换到磁盘的交换页数量，单位为KB。
io
bi：发送到块设备的块数，单位为KB。
bo：从块设备接受的块数，单位为KB。
system
in：每秒的中断数，包括时钟中断。
cs：每秒的环境切换次数。
cpu
按cpu的总使用百分比来显示。
us：cpu使用时间。
sy：cpu系统使用时间。
id：闲置时间。
标准情况下r和b的值应该为：
r<5,b=0
假设输出的信息中：
如果r经常大于3或4，且id经常少于50，表示cpu的负荷过重。
pi、po长期不等于0，表示内存不足。
bi经常不等于0，且在b中的队列大于2或3，表示io的性能不好。
################################# 其他参数 #####################################
查看内核版本号：
uname -a
简化命令：
uname -r
查看系统是32位还是64位的：
file /sbin/init
查看发行版：
cat /etc/issue
或lsb_release -a
查看系统已载入的相关模块：
lsmod
查看pci设置：
lspci

---