Summary

Edit online

With the availability of Spectrum Scale for Linux on z Systems, the question arises as to what are possible workload candidates to share data and would require a parallel filesystem. Applications that run in a WebSphere® Application Server (WAS) cluster on multiple nodes are good candidates to share data via a parallel filesystem.

The expectation was that in such a scenario requiring a parallel filesystem, Spectrum Scale would show its capabilities and strengths. An ECM system with IBM FileNet P8 (FNP8) and IBM Content Navigator (ICN) in a WAS cluster was considered to be an ideal candidate for this case study. This is because FNP8 supports Spectrum Scale as a cluster solution and can also store content in a file system location (Advanced File Storage Area) as well as a database repository. In the case of a database repository (Database Object Store), the database would control data access from multiple nodes. Such an ECM solution allows any impacts from the underlying filesystem to be shown, and is at the same time a customer-like workload.

This Part 1 single ECM node case study is followed by a Part 2 multiple ECM node cluster scale-out performance study, which shows the advantages of an ECM cluster solution. The objective of this first part of the study was the setup of a system under test (SUT) that establishes an ECM workload with a focus on filesystem disk I/O. The baseline for the performance test is defined with a single ECM node that uses XFS as Advanced File Storage Area. Next, Spectrum Scale is introduced as filesystem for the Advanced File Storage Area to expose any impact or overhead of a parallel filesystem compared to XFS, without using any cluster capabilities from Spectrum Scale for the single ECM node.

  • ECM application specific tuning fitting the workload
    • Workload-dependent sizings for WAS WebContainer, ORB Thread Pool, JDBC Connection Pools, JVM heap sizes for ICN and FNP8.
    • Database backend tuning for FNP8 and an example of a performance-specific database index creation. The index was created for a long-running ICN transaction with a quite high response time. After index creation, the average response time for the transaction was reduced from 7000 milliseconds to 200 milliseconds. The db2top utility, for example, can be used to identify identify long-running transactions or CPU-expensive SQL statements.
    • With the above tunings applied, the transaction throughput improved by more than 30% and the average transaction response time runs low from 1500 milliseconds seconds to 275 milliseconds, compared to the out of the box behavior.
  • Spectrum Scale specific tuning
    • Testing proved that the default blocksize of 256 KiB is a good default value for the workload.
    • For ECM workloads, the number of maximum inodes became an important parameter. Typically, ECM systems store massive amounts of data in a filesystem repository and the system can quickly run out of inodes. This causes No space left on device errors.
    • Other important parameters for cache usage were shown to be the pagepool size and the maxFilesToCache parameter. It is important to understand that both parameters relate to each other. For example, when using a large number of small files then increasing the pagepool size requires that the value of maxFilesToCache should also be increased. The optimal value depended on specific patterns of the files used. For this case study, the Spectrum Scale startIO metrics was used to determine the pagepool cache efficiency. An important point was that the range for the maxFilesToCache value with good caching-hit ratio was relatively large for our workload. But for larger pagepool sizes, the parameter might need to be adapted. Setting a value for maxFilesToCache that was too high could have a negative impact on the pagepool hit ratio.
  • Finally, the number of virtual ICN users is scaled to vary the load level. Due to the relative short think-times between transactions performed by the virtual users, the resulting workload is more powerful than with human users. The load levels vary from low to high. At the high end, 23 IFL processors were utilized which was considered to be the highest load level.
    • The SUT showed very good linear scaling behavior in relation to throughput rates.
    • In regard to response times, Spectrum Scale was comparable to, and partially better than XFS in the range 250 to 750 virtual ICN users. Spectrum Scale only had higher response times than XFS at the highest load level with 1000 virtual users.
    • In regard to CPU load, both filesystems behaved comparably.

It is clear that compared to a standard file system, a parallel filesystem needs more resources to manage multiple independent nodes that share a file system and keep the file system consistent . For a FileNet File Storage Area on a single ECM node, Spectrum Scale handles the additional effort very efficiently. Spectrum Scale can compete with XFS for low to medium load levels, and falls only slightly behind at the highest load level used in this case study.

This Part 1 of the case study showed how well an ECM system with FNP8 and ICN scales in a virtualized environment with Linux on z Systems.