Improving performance with solid state disk

Posted on April 01, 1999

RssImageAltText

Improving performance with solid state disk

With analysis, tuning, and SSD, one company improved SAP performance by an average of about 30%.

By Firooz Khodadady

Running SAP has many advantages for an organization. It provides a unified framework that permits all departments to share information and it enables upper management to review an organization`s entire operation without having to interface with different systems to collect data.

However, the potential advantages of SAP may be limited because the application is extremely demanding on disk storage. These demands can result in excessively long computer run times, which can delay critical reports.

One way to improve performance is by adding a solid state disk to house most frequently accessed files. Solid state disks are relatively easy and quick to install, they provide immediate performance benefits of up to 30%; and are portable so they can be installed on any computer system without changing operating systems or installing special drivers.

This case study illustrates the performance benefits one company experienced by adding solid-state disk to its SAP storage configuration.

Applied Material Inc. was running SAP R/3 3.1H. The environment consisted of an HP 9000 model T520 database server with eight CPUs and 2GB of RAM, and an EMC Symmetrix disk array with 2GB of cache. There were also six HP K460 application servers, each with two CPUs and 1GB of RAM. The application was running 24x7x365, supporting multiple global locations in the U.S., Europe, and Middle East. There were over 2,900 authorized users, with more than 300 on the system at any one time.

SAP R/3 was running on Oracle version 7.3.3 with SQL* NET version 2.1, using Oracle backup. The SAP modules included FI and MM.

The company had invested considerable effort to tune the system for their production environment. During a two-year interval, the database had grown from 25GB to 175GB, and 83 JFS file systems were in use. A storage growth of 2.5GB per month was expected to continue, and the load on the system during peak times was as high as 7x the normal load. A major load was generated at these times by the running of GLX and financial reports to close the books, which had to be completed in less than three days.

SAP and Oracle technical specialists assisted in tuning the database, its table layout, and the SAP configuration. The hardware and software environments were well tuned, and there were no further recommendations from the vendors for additional improvements.

However, performance problems continued:

- 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 seven minutes during financial closing periods.

- The system`s users began voicing concerns, and IT management began looking for solutions to solve the growing performance problem.

Applied Material hired Information Systems Associates, in San Ramon, CA, an independent consulting firm specializing in implementing and managing SAP and Oracle applications.

Information Systems Associates analyzed the situation by collecting relevant data from the database server and application servers. To collect batch runtime information, the firm used HP`s Glance performance data collector, as well as SAR and TOP. An analysis of Unix-level performance characteristics and SAP batch job performance data uncovered the following facts:

- The application servers were running at less than 40% of capacity, and there was no load/process queuing.

- The database server was heavily loaded. The CPU was continually 100% busy and was performing high disk I/O rates of more than 2,500 I/Os per second with an average wait time of more than 40 milliseconds, according to the SAR report. In addition, processes were queued at a load factor of six to seven.

During the batch runs, performance data from Oracle at the table and index level was also collected. The Oracle performance report "Bstat&Estat" identified the tables that were being read and updated most frequently. About 25 tables were used during 98% of the I/O requests, and more than 80% of the total I/Os were read requests.

The problem was clear: The database server could not perform and complete the I/O requests fast enough from the application servers. The EMC Symmetrix disk subsystem had 2GB of cache memory; however, Symmetrix could not allocate all or a portion of cache to specific "hot" I/O tables.

Additional data was collected to determine the growth rate of the files, the number of reads that were done to prepare for a delete, the number of fetches, etc.

The recommended solution

To directly address I/O rates and to allow specific files and I/O tables to be at a fixed location, Information Systems Associates suggested adding solid state disk. Solid state disks have the I/O speed of main memory and can be addressed exactly like a standard disk drive. And the data is never flushed out, like it is with cache memory.

After reviewing the above analysis in detail, Applied Material`s IT management approved a plan to install solid state disk in the company`s production system. The company selected Imperial Technology`s 2GB MegaRam (www.imperialtech.com). The data was analyzed, along with the growth rate of each file, to determine the best candidates for solid state disk. A disk was first installed in a development environment to confirm the results of the paper analysis.

Tests were conducted running the system with and without the solid state disk. Batch job performance improvements ranged from 17.9% to 30.6%. The highest single level of improvement was more than 92.3% on a particular batch job that had been taking almost 24 hours to complete.

The net result was that the runtime on 12 batch jobs that had been taking as long as 8 hours to 24 hours was now completed in 1 hour to 2.25 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 that significant, it is important to note that Oracle, SAP, and EMC experts--not to mention in-house technical staff--had tried to improve performance without adding solid state disk. So, a 30% performance boost was indeed considerable. Further, had the solid-state disk been installed before the start of the two-year performance tuning effort, system improvement could have been greater and the two-year tuning effort might not have been necessary.

Because of the critical nature of the system and the fact that all storage on the system is mirrored, a mirrored pair of 2GB solid-state disks was installed. Storage capacity can be increased if performance begins to degrade.

While solid state disk may not be the appropriate solution for all SAP installations, this technology has the advantage of being easy to install. With a knowledgeable staff or the advice of a consultant, sizing the solid state disk and selecting the files to install can be determined relatively quickly. q

Firooz Khodadady is an analyst with Information Systems Associates, in San Ramon, CA, an independent consulting firm specializing in providing implementation and management of SAP and Oracle applications. He can be reached at isafirooz@aol.com.

Click here to enlarge image

Storage summary

Production environment

- SAP R/3 3.1H (FI and MM modules) on Oracle version 7.3.3 with SQL*NET version 2.1 and Oracle backup

- HP 9000 T520 database server with 8 CPUs and 2GB RAM

- Six HP K460 application servers, each with 2 CPUs and 1GB of RAM

- EMC Symmetrix disk array with 2GB cache, 175GB usable capacity; storage growth rate of 2.5GB per month

- 2,900 users; about 300 online simultaneously

Performance problems

- Applications servers at less than 40% capacity; no load/process queuing

- Database server 100% loaded; more than 2,500 I/Os per second; processes queued at a load factor of six to seven

- Database server could not handle I/O requests from application servers fast enough

Solution

- Add mirrored, 2GB solid-state disks

Performance increases

- Batch job performance improvements ranged from 17.9% to 30.6%, with a best-case result of a 92.3% increase on one batch job

- Run time on 12 batch jobs reduced from 8-24 hours to 1-2.25 hours

- Performance increase on GLX reports ranged from 5% to 28%


Comment and Contribute
(Maximum characters: 1200). You have
characters left.