Itanium databases don’t require rocket science

Test drive of PostgreSQL on Itanium hardware shows equivalent functionality

By Duane Percox

Second of two parts

We were excited to get the opportunity this year to install one of HP’s rx2600 systems with dual Itanium 900Mhz (McKinley) CPUs to test out HP-UX and Linux, operating environments which our company QSS is targeting as a migration platform for our MPE application. Last month I talked about the Itanium system hardware and COBOL compiler comparisons. This month our field report examines database test results and how the application’s CM code fared.

Feeling good about our basic COBOL CM code executing without errors, and having reasonable performance, we went on to tackle the database. PostgreSQL (pg) was installed and running as version 7.1.3, but with default settings. We took advantage of our 4GB of memory and set up pg as you would for a 4GB database server. Our development IA-32 system has both pg 7.1.3 and 7.2.4 running with identical databases. We used the pg backup utilities to unload the 7.1.3 versions of the databases and moved the data to the IA-64 system and set up the same databases for testing.

Using the command line utility psql we drove around the databases and found the access to be fast and some functions to be significantly faster than our IA-32 development system. I need to stress that there was no rocket science associated with moving the data from the IA-32 system to the IA-64 system. The built-in utilities and functions of PostgreSQL allow you to easily move data from one system to another.

We have some DB test programs in NetCOBOL that we have used on our IA-32 system for load testing and verification of PostgreSQL. We ran those same programs on the IA-32 system, but using different env variables to point to the database running on IA-64. No code changes, just point to the other system and we could access the database.

We found equivalent functionality with the database, proving to us that it didn’t matter where the data was hosted. On a 64-bit PostgreSQL server with Itanium, or on the IA-32 server with a PIII chip, the results to the application were the same. Of course, we expected this, but it is always nice to have it confirmed.

We did some basic timings in this configuration and found we were being limited by the configuration of our IA-32 box. So, we moved these programs over to IA-64 to see how well they ran as CM code accessing the data using the NM database engine on the same system.

We discovered the code wouldn’t run because of some missing CM libraries that weren’t installed. For our testing we just copied the libraries from the IA-32 system and then everything ran correctly. We weren’t sure how to get the CM libraries installed from the supplied Red Hat CDs so this was the most expedient solution. This also confirmed to us that dealing with CM code wouldn’t be a big deal.

We spent considerable time beating up the IA-64 box running many simultaneous processes accessing 33Mb of data from a PostgreSQL database at the same time as if you were running lots of parallel batch jobs producing a large report. We got results which were very linear plotting wall time vs. number of users (200-plus) indicating the system was capable of handling a good database load. These tests were not very scientific, but were meant to give us a relative feel of the system. Overall we were very impressed with how well the system handled the load. We will be doing some more tests which should provide a better sense of how PostgreSQL/64 runs under varying and changing loads.

Our final PostgreSQL test for this report was to test bulk loading of tables with multiple indexes. We converted 1,238,000 records from an TurboIMAGE database into a tab delimited file that could be bulk loaded into the corresponding PostgreSQL table with 14 columns and 2 indexes. It took approximately 7 minutes, 15 seconds to bulk load this data into PostgreSQL. This represents over 17,330,000 fields of data.

Summary

We have found the system to be well-built, and it has run fine with no hiccups since we turned it on. CM code doesn’t run as fast as we would like, but running CM on the newest Madison boxes at 1.5GHz would be a definite improvement. The system seems to be well designed to serve as a database server; loaded up with lots of memory you would have a pretty nice database engine. If you have CM code, you might want to consider using a native IA-32 system — say with a XEON processor — as your application server, connected with 1000bt LAN to an IA-64 server configured as a database server.

Duane Percox is a founder of MPE application provider QSS and a member of the SIG-Itanium executive committee.