使用Microsoft Exchange Jetstress 2013对Exchange 2013进行压力测试案例

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了使用Microsoft Exchange Jetstress 2013对Exchange 2013进行压力测试案例相关的知识,希望对你有一定的参考价值。

1 测试工具

使用微软官网提供的工具Microsoft Exchange Jetstress 2013对Exchange server 2013服务器进行压力测试。

2 测试方法

通过在服务器上安装Microsoft Exchange Jetstress 2013工具,指定测试范围,测试完成后通过该工具生成的性能监视报告进行分析服务器性能。

由于服务器MDB01和MDB02的服务器配置一致,因此只在服务器MDB01上运行测试工具即可评估两台服务器的最大承载能力。

首先,安装Jetstress工具,选择“安装”。如图

技术分享

选择Next。

技术分享

选择“I Accept The Terms。。。。。。”,如图

技术分享

将该工具安装在E盘下面,如图。

技术分享

选择Next。如图

技术分享

安装成功后,关闭安装窗口。

技术分享

将Exchange 2013安装目录下面的BIN目录下ese.dll、eseperf.dll、eseperf.hxx、eseperf.ini四个文件拷贝到Jetstress工具安装目录下面。如图。

技术分享

打开Jetstress 2013测试工具,如图。

技术分享

技术分享

设置创建一个新的测试配置,如图。

技术分享

选择Test Disk Subsystem Throughput,如图。

技术分享

设置测试过程中磁盘的占用磁盘空间为80%,如图。

技术分享

保持默认选择,单击Next

技术分享

选择测试结果保持位置。如图。

技术分享

设置测试过程中使用7个邮箱数据库进行性能测试。如图。

技术分享

选择Create New Database,如图。

技术分享

选择Run Test。如图。

技术分享

测试完成,如图

技术分享

3 测试结果分析

3.1 物理磁盘性能

技术分享

3.2 服务器内存性能

技术分享

计数器

描述

阈值

疑难解答

Memory\Available Mbytes

显示物理内存量 (MB),可立即分配给进程或供系统使用。它等于分配给备用(已缓存)、可用和零分页列表的内存总和。有关内存管理器的完整解释,请参阅 Microsoft Developer Network (MSDN) 或 Windows Server 2003 资源工具包中的“系统性能和疑难解答指南”。

应该始终保持在 100 MB 以上。

 

Memory\%Committed Bytes in Use

显示 Memory\Committed Bytes 与 Memory\Commit Limit 的比率。已提交内存是指在需要写入磁盘时已在分页文件中保留空间的使用中的物理内存。提交限制由分页文件的大小确定。如果扩大分页文件,则提交限制会增加,并且该比率会减小。此计数器仅显示当前的百分比值;它不是平均值。

不适用。

如果此值较大(大于 90%),您可能会开始看到提交失败。这清楚表明了系统内存很紧张。

Memory->Transition Pages Repurposed/sec

表明系统缓存紧张。

平均应小于 100。峰值应该小于 1,000。

 

Memory\Page Reads/sec

表示必须从磁盘而不是内存读取数据。表示内存不足并且分页即将开始。如果该值每秒大于 30,则表示服务器无法处理负荷。

平均应小于 100。

 

Memory\Pages/Sec

显示从磁盘中读取页面或向磁盘写入页面以解决硬页面错误的速率。此计数器是导致系统范围延迟的错误类型的主指示器。它是 Memory\Pages Input/sec 和 Memory\Pages Output/sec 的总和。它是用页数计算的,以便在不用进行转换的情况下就可以同其他页计数(如 Memory\Page Faults/sec)做比较。它包含为了解决错误而在文件系统缓存(通常由应用程序请求)和非缓存映射内存文件中检索的页面。

平均起来应该低于 1,000。

此计数器返回的值可能大于预期值。这些值可能与分页文件活动或缓存活动都不相关。这些值可能是由按序列读取内存映射文件的应用程序导致的。

使用 Memory\Pages Input/sec 和 Memory\Pages Output/sec 来确定页面文件 I/O。

Memory\Pages Input/sec

显示从磁盘中读取页面以解决硬页面错误的速率。在进程引用不是位于其工作集的虚拟内存中的页面或物理内存其他位置的页面时,会发生硬页面错误,必须从磁盘检索硬页面错误。当页面出现错误时,系统会尝试将多个连续页面读入内存,以使读操作的效用最大化。将 Memory\Pages Input/sec 的值与 Memory\Page Reads/sec 的值进行比较以确定每个读操作期间读入内存的平均页面数。

平均起来应该低于 1,000。

 

Memory\Pages Output/sec

显示将页面写入磁盘以释放物理内存中空间的速率。仅当在物理内存中更改页面时,才会将其写回至磁盘,因此页面可能保留数据而不是代码。页面输出速率很高可能表示内存不足。当物理内存不足时,Microsoft Windows 会将更多页面写回至磁盘以释放空间。此计数器显示了页面数,并且无需转换即可与其他页面计数进行比较。

平均起来应该低于 1,000。

 

压力测试期间:

Memory\Available Mbytes的数值为114MB>100MB,说明符合建议值。

Memory\%Committed Bytes in Use的数值为34.021%<90%,说明服务器的内存不存在资源紧张。

Memory->Transition Pages Repurposed/sec 的数据为0.000,说明服务器内存资源充足。

Memory\Page Reads/sec的数值为9.671<30,说明服务器能够处理负荷。

3.3 Exchange 数据库

3.3.1 结果分析参考标准

erformance counter instance

Guidelines for performance test

Guidelines for stress test (>6h)

I/O   Database Reads Average Latency (msec)

The average value should be less than 20 milliseconds (msec) (.20) and the maximum   values should be less than 100 msec.

The maximum value should be less than 200 msec.

I/O   Log Writes Average Latency (msec)

Log disk writes are sequential, so average write latencies should be less than 10 msec, with a maximum of no more than 100 msec.

The maximum value should not exceed 200 msec.

%Processor   Time

Average should be less than 80% and the maximum should be less than 90%.

Same as for performance test.

3.3.2 Database Sizing and Throughput

技术分享

3.3.3 Jetstress System Parameters

技术分享

3.3.4 Database Configuration

技术分享

3.3.5 Transactional I/O Performance

I/O Database Reads Average Latency (msec)微软建议该值平均应该小于20,最大值应小于100,此次测试报告中该值高于平均低于最大值,说明磁盘E较符合数据库I/O要求,建议有条件时更换为I/O更高的磁盘。

I/O Log Writes Average Latency (msec)该值微软建议平均值应小于10毫秒,最大值应小于100毫秒,此次测试中的数据为4.193和3.705均小于10,符合日志F磁盘的I/O需求。

技术分享

3.3.6 Background Database Maintenance I/O Performance

技术分享

3.3.7 Log Replication I/O Performance

技术分享

3.3.8 Total I/O Performance

技术分享

3.3.9 Host System Performance

%Processor Time值表示服务器Cpu利用率,微软建议Cpu的利用率平均值应小于80%,最大利用率应小于90%,此测试报告中服务器的Cpu平均利用率为3.879%,最大利用率为19.302%,测试结果符合服务器Cpu要求。

技术分享

技术分享

3.4 CPU性能

平均Cpu使用率在25%,测试过程中符合Exchange服务器Cpu要求。

技术分享

技术分享

参考数值表:

计数器

描述

阈值

疑难解答

Processor(_Total)\% Processor Time

显示处理器执行应用程序或操作系统进程的时间的百分比。这是处理器未处于空闲状态时的情况。

平均应该少于 75%。

 

Processor(_Total)\% User Time

显示花在用户模式上的处理器时间的百分比。用户模式是受限制的处理模式,旨在用于应用程序、环境子系统和完整子系统。

应该保持在 75% 以下。

 

Processor(_Total)\% Privileged Time

显示花在特权模式上的处理器时间的百分比。特权模式是一种处理模式,旨在用于操作系统组件和硬件处理驱动程序。它允许直接访问硬件和所有内存。

应该保持在 75% 以下。

如果总的处理器时间较长,请使用此计数器确定导致 CPU 利用率很高的进程。

Process(*)\% Processor Time

显示所有进程线程用于执行指令的已用处理器时间的百分比。指令是计算机中的基本执行单位。线程是执行指令的对象,而进程是运行程序时创建的对象。此计数中包含了处理某些硬件中断和陷阱条件时执行的代码。

 

如果总的处理器时间较长,请使用此计数器确定导致 CPU 利用率很高的进程。

System\Processor Queue Length(所有实例)

表示每个处理器所服务的线程数。处理器队列长度可用于确定处理器争用或 CPU 使用率很高是否由处理器处理所分配的工作负荷时容量不足所致。处理器队列长度显示了处理器就绪队列中延迟的线程数以及等待计划执行的线程数。列出的值是进行测量时最后一次观察到的值。

每个处理器的队列长度不应大于 5。

在具有单个处理器的计算机上,如果观察到队列长度大于 5,则是警告要执行的作业经常多于处理器可以迅速处理的作业。如果此数大于 10,则是明显表示处理器已达到其容量限制,在 CPU 使用率很高时尤其如此。

在具有多处理器的系统上,可以按物理处理器数划分队列长度。使用硬处理器关联(进程分配给特定的 CPU 核心)配置的多处理器系统的队列长度值很大,可以指示配置不平衡。

尽管处理器队列长度通常未用于容量规划,但还是可以用于确定环境内的系统是否能够运行负载,或者是否应该购买其他处理器或速度更快的处理器以用于将来的服务器。

根据压力测试报告来看,服务器的Cpu性能符合要求。

4 测试结果总结

磁盘I/O

1、I/O Database Reads Average Latency (msec)微软建议该值平均应该小于20,最大值应小于100,此次测试报告中该值高于平均低于最大值,说明磁盘E基本符合数据库I/O要求,建议有条件时更换为I/O更高的磁盘。

2、I/O Log Writes Average Latency (msec)该值微软建议平均值应小于10毫秒,最大值应小于100毫秒,此次测试中的数据为4.193和3.705均小于10,说明日志F磁盘的I/O值符合Exchange服务器日志磁盘需求。

Cpu

1、%Processor Time值表示服务器Cpu利用率,微软建议Cpu的利用率平均值应小于80%,最大利用率应小于90%,此测试报告中服务器的Cpu平均利用率为3.879%,最大利用率为19.302%,测试结果符合服务器Cpu要求。

内存:

1、Memory\Available Mbytes的数值为114MB>100MB,说明符合建议值。

2、Memory\%Committed Bytes in Use的数值为34.021%<90%,说明服务器的内存不存在资源紧张。

3、Memory->Transition Pages Repurposed/sec 的数据为0.000,说明服务器内存资源充足。

4、Memory\Page Reads/sec的数值为9.671<30,说明服务器能够处理负荷。

以上是关于使用Microsoft Exchange Jetstress 2013对Exchange 2013进行压力测试案例的主要内容,如果未能解决你的问题,请参考以下文章

如何重建Microsoft Exchange Server Auth Certificate证书

使用 Python 获取 Microsoft Exchange / Outlook 个人资料照片

Microsoft Exchange 2016 邮箱角色部署文档

[daily] 使用thunderbird通过davmail代理访问Microsoft Exchange Service(OWA)

迁移到Microsoft Exchange和Exchange Online的真相

如何使用 EWS 托管 API 从 Microsoft Exchange 检索所有联系人?