A Case Study:
Enhancing SAP Performance
with Solid State Disk
Author:
Firooz Khodadady, Senior Analyst
Information
Systems Associates (ISA)
43 Plymouth Court - San Ramon, CA 94583
Creation Date: August 7, 1998
Executive
Summary
Running
SAP can provide many advantages for an organization. It provides a
unified framework that permits all departments to get the
information required by that group and allows upper management to
review the entire operation of the organization without having to
interface with many different systems to collect data.
The
advantages SAP brings to an organization may, however, be reduced
because SAP is an application that is extremely demanding on system
resources, particularly those of the disk storage subsystem. One
method of improving SAP performance is adding a solid state disk to
house the most frequently accessed files. This approach has the
advantages of being easy and quick to install, provides immediate
improvements in the range of 30%, is portable so it can be installed
on any computer system without regard to the manufacturer and
without requiring any changes to the operating system or the
installation of special drivers.
Background
& System Configuration
A
major semiconductor equipment manufacturer located in Silicon Valley
had installed SAP R/3 version 2.2 in 1995 and later upgraded SAP to
R/3 3.1H. The system consisted of an HP 9000 model T520 Database
Server with 8 CPUs, 2 GBytes of RAM and an EMC Symmetrix that had 2
GBytes of cache. Also on the system were 6 HP K460 Application
Servers, each of which had 2 CPUs and 1 GByte of RAM. This system
was running 24 hours a day, 7 days a week, 365 days a year
supporting multiple global locations in the Middle East, Europe and
the USA. There were over 2900 authorized users, with over 300 of
these users on the system at any one time.
This
SAP R/3 system was running on Oracle version 7.3.3 with SQL*NET
version 2.1 and also using Oracle backup. [The SAP modules used
included FI and MM.]
Performance
was an issue from the beginning and the company had invested a great
deal of effort to tune the system for their particular production
environment. During that two-year interval the database had grown
from 25GBytes to 175GBytes and 83 JFS file systems were in use. A
storage growth of 2.5 GBytes per month was expected to continue and
the load on the system during the peak times, at month, quarter, and
year end was as high as 7X the normal rate. A major load was
generated at these times by the running of GLX and financial reports
to close the books. This had to be completed in less than 3 days.
Based
on recommendations from those projects, the company installed the
most powerful UNIX server that HP could deliver (at that time), and
installed an EMC Symmetrix with 2GBytes of cache to reduce I/O wait
times.
SAP
and Oracle technical specialists assisted in tuning the database,
its table layout and the SAP configuration. The hardware and
software environment was well tuned and there were no further
recommendations from the vendors for additional improvement.
By
the spring of 1997, performance problems hit a new high:
-
Batch
jobs were taking 18 to 24 hours to complete;
-
On-line
transactions, which used to take only a few seconds to
complete, were taking in excess of 5 to 7 minutes during
financial closing periods;
-
The
system users began voicing concerns and IT management began
looking for solutions to solve the growing performance
problem.
A
decision was made to call in an outside consultant. The consultant
would be tasked with the job of improving the system stability and
improving performance. The company hired Information Systems
Associates, San Ramon, California, an independent consulting firm
specializing in providing implementation and management of SAP and
Oracle applications.
System
Analysis
Because
batch run times were a significant problem for the client, Information
Systems Associates began the analysis by collecting batch run time
related data. Detailed information from batch run times can provide a
clear picture on where most of the time is spent. In this instance it
also showed that the network and the time spent passing the messages
from the Application Server to the Database Server were not problem
areas. The analysis separated the batch run time information into:
-
Time
spent in the Application Server.
-
Time
spent in performing communication between the Application Server
and
Database
Server.
-
Time
spent in the Database Server to complete and respond to the
application server request.
To
collect batch run time information, HP's Performance data collector,
Glance, as well as SAR
and
TOP were used. Data was gathered relating to:
This
data collection was done for both the Database Server and the
Application Server. From an analysis of the UNIX level performance
characteristics and the SAP batch job performance data, the following
facts became clear:
-
The
Application Server was not loaded. It was running at less than
40% of its capacity and there was no load/process queuing.
-
The
Database Server was heavily loaded. The CPU was 100% busy all
the time and was performing high disk I/O rates of over 2,500
I/Os per second with an average wait time in excess of 40
milliseconds based upon the SAR report. In addition, processes
were queued at a load factor of 6 to 7.
During
the batch runs, performance data from Oracle at the table and index
level was also collected. The Oracle performance report "Bstat&Estat"
enabled identification of the tables which were being read and updated
most frequently. About 25 tables were identified as being used during
98% of the I/O requests. Over 80% of the total I/Os were read
requests. This information was double-checked and confirmed with the
SAP I/O level report on.
The
problem was clear: The Database Server could not perform and complete
the I/O requests from the Application Server fast enough. The disk
subsystem, an EMC Symmetrix, had 2GBytes of cache memory; however, the
product does not allow allocation of all or a portion of cache to
specific "hot" I/O tables.
Table
1 displays the data collected during this analysis of the batch run
times. The Total I/Os column lists the total number of I/Os collected
for the named table during the time the report was being generated.
The three columns, "Sequential Reads," "Direct
Reads," and "Changes" are a breakdown of the total I/Os
during the report period. Direct Reads are randomly accessed read
operations. Changes are the write operations that had to be performed.
There
was additional data collected during the analysis to determine the
growth rate of the files, information on how many reads were done to
prepare for a delete, the number of fetches, etc. . . .
|
Table
Name
|
Total
I/Os
During Report
|
Sequential
Reads
|
Direct
Reads
|
Changes
(write operations)
|
Number
of Rows in the Table
|
|
MARC
|
20,115,011
|
17,264,108
|
2,805,944
|
44,959
|
20,076,003
|
|
VBAK
|
15,293,217
|
14,308,419
|
978,818
|
5,980
|
15,561,800
|
|
MARD
|
11,872,664
|
11,606,256
|
174,425
|
91,983
|
363,381
|
|
LIKP
|
7,846,202
|
6,927,956
|
898,637
|
19,609
|
7,832,994
|
|
MSEG
|
4,609,763
|
4,601,549
|
6,592
|
1,622
|
519,175
|
|
BKPF
|
4,433,926
|
3,470,858
|
806,926
|
156,142
|
4,309,185
|
|
MARA
|
4,326,925
|
517,157
|
3,801,698
|
8,070
|
4,271,437
|
|
LTAP
|
3,820,125
|
3,761,149
|
0
|
58,976
|
2,930,726
|
|
VBAP
|
3,752,163
|
3,728,105
|
23,964
|
94
|
716,189
|
|
MAKT
|
3,486,281
|
204,144
|
3,266,624
|
15,513
|
3,354,538
|
|
MBEW
|
3,419,595
|
2,924,054
|
396,182
|
99,359
|
843,869
|
|
MKPF
|
3,094,909
|
2,628,869
|
464,418
|
1,622
|
3,085,502
|
|
EKBE
|
3,011,530
|
2,981,262
|
216
|
30,052
|
441,059
|
|
MDBS
|
2,982,544
|
2,982,464
|
80
|
0
|
564,116
|
|
EKPO
|
2,804,329
|
2,744,371
|
55,743
|
4,215
|
1,019,985
|
|
VBBE
|
2,779,238
|
2,678,819
|
0
|
100,419
|
1,768,807
|
|
VBEP
|
2,437,538
|
2,420,700
|
7,970
|
8,868
|
740,521
|
|
VBPA
|
2,142,559
|
523,631
|
1,607,817
|
11,111
|
1,607,818
|
|
VBUP
|
2,123,267
|
1,584,282
|
502,448
|
36,537
|
597,136
|
|
LAGP
|
1,978,024
|
1,550,298
|
256,006
|
171,720
|
1,885,736
|
|
EKET
|
1,927,665
|
1,842,213
|
42,696
|
42,756
|
587,321
|
|
LIPS
|
1,819,356
|
1,690,163
|
122,670
|
6,523
|
1,188,219
|
|
LFA1
|
1,392,548
|
464,580
|
927,534
|
434
|
1,323,875
|
Table
1: Files and Tables Analyzed for Tuning
The
Recommended Solution
The
technology that directly addresses I/O rates and allows specific files
and I/O tables to be at a fixed location is solid state disk. It
provides the I/O speed of main memory, can be addressed exactly like a
disk and the data is never flushed out as occurs with a cache memory.
IT management, after reviewing the above analysis in detail, approved
a plan to install solid state disk in the company's production system.
The
data in Table 1 was analyzed along with the growth rate of each table
to determine which files were the best candidates for solid state
disk. A solid state disk was first installed in a development
environment to confirm the results of the paper analysis. Table 2
lists the files selected for mounting on the solid state disk.
|
Object
|
Description
|
File
Size
in MB
|
Growth
Rate/Month
|
|
EKET
|
Delivery
Schedule
|
190
|
0.00%
|
|
EKKO
|
Purchasing
Document Header
|
160
|
3.76%
|
|
KNA1
|
Customer
Master
|
3
|
0.00%
|
|
LFA1
|
Vendor
Master
|
20
|
0.00%
|
|
MAKT
|
Material
Descriptions
|
16
|
2.38%
|
|
MARA
|
Material
Master
|
37
|
0.00%
|
|
MARC
|
Material
Master: C Segment
|
211
|
1.33%
|
|
MARD
|
Material
Master: Storage Location/Bbatch Seg.
|
58
|
1.89%
|
|
MBEW
|
Material
Valuation
|
181
|
1.47%
|
|
MDVM
|
Entry
in MRP
|
17
|
1.04%
|
|
MLAN
|
Table:
Tax Classification Material
|
31
|
1.79%
|
|
MLGN
|
Table:
Material data from each Warehouse Number
|
14
|
0.00%
|
|
VBAK
|
Sales
Document Header
|
100
|
4.07%
|
|
VBPA
|
Sales
Document Partner
|
357
|
4.83%
|
|
ZZGLC
|
Legacy account/Div/Reg SAP Account Biz
Area/Pla
|
1
|
0.00%
|
|
ZZGLT
|
AMAT
GLX Summary Table
|
324
|
3.10%
|
|
TOTAL
OF ALL FILES AND TABLES
|
1,719
|
Table
2: Files and Tables Moved to Solid State Disk
Based
upon this data a 2GB solid state disk was selected. Tests were
conducted running the system with and without the solid state disk.
The improvement to batch performance ranged from an average 17.92% to
30.64% and the highest single level of improvement seen was over
92.31% on a particular batch job that was taking almost 24 hours to
complete.
The
net result was that the run time on 12 long running batch jobs that
had been taking as long as 8 to 24 hours were now running in only 1 to
2-1/4 hours, and the performance improvement of the GLX reports ranged
from 5% to 28%.
While
the performance improvement for the GLX reports may not seem
significant, it must be realized that experts from Oracle, SAP and
EMC, as well as the in-house technical staff, had made a continuing
long term effort to improve performance. Gaining an additional 30% by
conducting a careful analysis of the system and the addition of a
storage device that is simple and quick to install was a great
advantage to the organization. Had the solid state disk been installed
before the two-year performance tuning effort had begun it would have
shown a greater percentage improvement in system performance and,
perhaps, the two-year tuning effort might not have been necessary.
Because
of the critical nature of the system and because all other storage on
the system is mirrored, a mirrored pair of 2GB solid state disks was
installed. This technology permits field expansion, so the capacity of
these products can be increased if future growth of the system causes
performance to degrade and to accommodate the anticipated growth of
the most active files.
Conclusion
There
are a number of elements to consider when analyzing an SAP R/3
installation. These are:
The
basic components of the system including:
- R/3
Version
- Database
Version
- OS
Version
- Hardware
- Number
of users
- Amount
of reporting/batch jobs
- Customization
A
review of the hardware elements that have been shown to have the
greatest impact on performance must be made, being careful to study
the performance of these elements at peak load periods. The Database
Server and its disk sub-system are often areas where the performance
limiting hardware can be found.
To
conduct a meaningful analysis of the system it is important to
understand the relative system loading of the different SAP R/3
modules. The SAP R/3 modules and the relative loading of each are
listed below:
- FI
(9%)
- WM
(22%)
- MM
(25%)
- SD
(38%)
- PP
(55%)
Separating
the software and firmware of the installation into: The Application,
The Database together with SAP Basis, and the Operating System can be
helpful in determining where the focus of the tuning effort should be
directed. In this instance the expected gains were:
-
Application and customizing (60%)
-
Database + SAP Basis (30%)
-
Operating System (10%)
The
appropriate technique used to tune an SAP R/3 system will be different
for each installation. The particular hardware, the operating system,
the database used, the R/3 modules that are active as well as the
performance requirements of the customer are all factors that must be
considered. The specific installation described in this case study
achieved a significant and immediate benefit from solid state disk,
even after a major effort to tune the system for better performance
had been completed.
While
solid state disk may not be the appropriate solution for all SAP
installations, this technology has the advantage of installing easily
and quickly without requiring any special drivers or modification to
the operating system or the database. With a knowledgeable staff or
the advice of a consultant the sizing of the solid state disk and the
selection of files to install can be determined in a relatively short
period of time.
Information
Systems Associates is an independent consulting firm specializing in
providing implementation and management of SAP and Oracle
applications. Firooz Khodadady made the system analysis and
recommendations. Mr. Khodadady can be reached at Information Systems
Associates, 43 Plymouth Court, San Ramon, CA 94583, by calling (925)
833-1184 or by e-mail at isafirooz@aol.com.
Get
PDF File
|
