To begin analyzing performance or to design a system a "quick start" checklist can be a useful tool. This checklist is a good place to start and is a helpful reminder for those already familiar with GPFS. It contains a list of "areas to consider" when determining the performance of a GPFS solution. Tuning these parameters, in many cases, can greatly improve application performance.

This page is intended to remain a list for easy reference. Further details on these or other parameters or tuning tips should be provided on separate pages and linked to from here.

• How to get started

Checklist topics

• GPFS Configuration Parameters
• File System Configuration
• Storage Configuration
• Interconnect Tuning
• Application Design

The biggest challenge in tuning performance is developing a clear understanding of your goals. Before embarking on a performance tuning exercise it is a good idea to clearly define a performance target.

Developing a performance target

Developing a clear performance target allows you to keep your tuning effort focused. Since tuning is often a game of give and take a focused approach can help you make those value decisions as they arise. A performance target can take many forms:

• A throughput target - " I need to achieve 200 MB/sec using myapp"
• An IOP target - " I need to be able to create 1000 files/second using filecreate.bash"
• An Application Transaction - " I need to complete 100 cube requests a minute"
• A backup or recovery target - " I need to be able to perform a differential backup on 10 million files in 2 hours with 1 10% daily change rate and an average file size of 1MB"

Whatever your target there are certain characteristics the goal should have.

• Measureable - the target should be a metric like "files create per second" that can be easily determined.
• Tools - The tools used to execute and measure the test should be clearly defined. You should research you application requirement and find or develop a relevant tool to generate a workload. For best results the results of a test execution should be readily apparent and not require extensive post processing before they can be interpreted.
• Relevant - The test workload should be as relevant to the production application as possible. This is the #1 issue with most performance tuning exercises. Most failed performance tuning engagements fail because the workload is chosen because it is handy, and not necessarily relevant. For example, IOR is a create test of throughput but will not help if you are tuning a file system to provide SMTP email service.