Butsch Informatik, 2010, Exchange 2003/2007/2010/2013/2016 Performance Analyse

Häufig kommt die Aussage, dass der Exchange Server zu langsam ist. Hier einige Eckdaten wie man misst ob ein Exchange 2003/2007/2010 schnell oder langsam ist und eventuelle Fehler in der Hardware/Auslegung aufdeckt.

Storage/SAN IBM DS 4700

IOPS (Input/Output Operations Per Second) ist ein Wert/Faktor, welcher Auskunft über die Performance eines Datenträgers gibt.

Durchschnittswerte von HP/DELL, IOPS Platten

2,5“ 5.400 rpm SATA 71 IOPS
3,5“ 7.200 rpm SATA 65 IOPS
3,5“ 10.000 rpm U320 104 IOPS
3,5“ 15.000 rpm U320 141 IOPS
3,5“ 10.000 rpm FC 125 IOPS
3,5“ 15.000 rpm FC 150 IOPS

Aktuelle Werte auf dem DS 4700 gemessen

IOPS = 15 x 150 = 2250 (Höchstwert auf SAN angezeigt 4162 > Cache)

http://www.seagate.com/docs/pdf/marketing/ds_1566_004_cheetah_15k_4.pdf

Dienstag 31.07.10 Peak max. 2073 Monitor von 14:28 bis 18:30 Uhr	Mittwoch 01.04.09 Peak. max. 4162 Monitor über Nacht inkl. Backup Zugriff!
Der höchste IOPS Zugriff welcher vom Dienstag auf den Mittwoch statt gefunden hatte waren 4163 IOPS. Dies war das Backup, welches über Nacht sicherte. Im Verlaufe des regulären business Betriebes aber IOPS Werte von bis zu 2000 (95% der Leistung der 15 Platten ohne Caching). IOPS 15 Platten = 2250 IOPS, Cache Hit ca. 56.4% Daher max. Peak 4000 IOPS beim Backup. Cache während des Tages aber bis zu 80%.

Auszug IBM white Paper:

	Firma:   500 User 200MB Mail 15 Disk Geteiltes SAN   IBM Test:   2000 User 200MB Mail 26 Disk Dediziertes SAN
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101314

Wie viele IOPS braucht der Firma Exchange 2003 Server?

Firma durchschnittlich ca. 200 MB pro Mailbox (Average-Heavy) 518 Mailboxen x 0.75 = 388 IOPS Daten E:, 38 IOPS Logs F: 518 Mailboxes x 1.00 = 518 IOPS Daten E:, 51 IOPS Logs F:

Firma Cluster IOPS, Werte 16:40 Uhr, Dienstag, 31.04.210

2      Was ist bei der Exchange Storage Optimierung zu beachten?

Analyse mit Microsoft Capacity Planer Tool

Mit diesem Tool kann man heraus finden wie viel Last (Zusätzliche Benutzer) der Exchange an sich noch vertragen würde. 

IBM Sagt zu Storage und Exchange 2003:

After you have optimized your hardware, you should organize the storage subsystem to optimize performance. The following are recommendations about how to place your data files:

Database files

Place all database files on a single volume that is only used for these files. To increase performance, the disks where the database files are stored should have fast random access speeds. (RAID-10)

Content Indexing Files

The default location for the indexing files is on the same disk as the page file. Moving the indexing files to a separate volume increases performance. If your disk subsystem performs well enough, you can place these files on the database file volume, because the indexing file is also a random access file. (RAID-10)

Single Instance Storage

Mailboxes that belong to the same workgroups and distribution lists should be stored in the same database. (RAID-10)

Transaction Log Files

The most important performance factor for Transaction Log Files is the latency. So, they should be placed in a single storage group. (RAID-10)

SMTP queue

The SMTP queue should be placed in a own volume that is distributed over multiple disk spindles. The used spindles should not handle other volumes. (RAID-10)

Page file

The default location for the page file is on the operating system volume. Move the page file to a own volume that is distributed over multiple spindles improves performance. (RAID-1)

MTA queue

The MTA queue (Message Transfer Agent) should never reside on a log or database volume. The best way is to provide a separate set of spindles for the SMTP and MTA queue together. (RAID-10)

To improve performance, it is recommended to connect your system volume and your page file through Direct Attached Storage (DAS). The other volumes should be placed on a Storage Area Network (SAN).

The attached storage to an Exchange server is very important because disk subsystem bottlenecks can cause very grave performance issues. The most common problem is that people tend to plan storage designs for capacity and not for performance. When you plan an Exchange server, you should calculate the

following volumes at a minimum:

RAID-1 for the operating system

RAID-1 for the transaction log files

RAID-10 for the database store

However, this basic configuration is not enough. The most important factor that can affect disk subsystem issues is the throughput and the latency of your read and write operations. An simple and effective rule is that it is better to have more disks with a smaller capacity than having fewer disks with a larger capacity, because if you stripe the arrays over more disks, you have a greater number of spindles which increases performance. This is one of the most important investments you can make in your disk.

3      Externe Dokumente von IBM und Exchange 2003Storage Optimierung IBM SAN und Exchange 2003:

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/338220348035601f862574ba00762bb9/$FILE/32730-00_RevB_Storage_Optimization.pdf

IBM High Availability DS4000 Solutions for Microsoft Exchange:

http://www-03.ibm.com/systems/hu/resources/systems_hu_pdf_IBM_Exchange_Solution_Final.pdf

Peformance Exchange 2007/2010 Servers, key values

http://technet.microsoft.com/en-us/library/bb201689(EXCHG.80).aspx

How to tell if an Exchange is slow or fast?

TRANSACTION_LOG_DISK: LogicalDisk(*)\Avg. Disk sec/Read < 20ms
TRANSACTION_LOG_DISK: LogicalDisk(*)\Avg. Disk sec/Write < 10ms

TEMP_DISK: LogicalDisk(*)\Avg. Disk sec/Read < 10ms
TEMP_DISK: LogicalDisk(*)\Avg. Disk sec/Write < 10ms

MSExchangeIS\RPC Requests < 70
MSExchangeIS\RPC Averaged Latency < 25

MSExchangeIS\RPC Operations/sec

MSExchangeIS\RPC Num. of Slow Packets < 1
MSExchangeIS Client (*)\RPC Average Latency < 50ms

MSExchangeIS\Client: RPCs Failed:Server Too Busy/sec < 0 all times
MSExchangeIS\Client: RPCs Failed:Server Too Busy < 0 all times

MSExchangeIS Mailbox(_Total)\Messages Queued for Submission < 50
MSExchangeIS Public(_Total)\Messages Queued for Submission < 20

MSExchange Database ==> Instances(*)\Log Generation Checkpoint Depth < 500 (20-30 for each SG)
MSExchange Database(Information Store)\Database Page Fault Stalls/sec < 0
MSExchange Database(Information Store)\Log Threads Waiting < 10
MSExchange Database Instances(*)\I/O Database Reads Average Latency < 20ms (50ms Spikes)

MSExchange Database(Information Store)\Database Cache Size (MB)