Page 2 of 2   « previous page

The limitation for this particular client is that they were running 32-bit Linux, which is limited to being able to address only 4GB of RAM per process. This means that your database server can only address about 3GB of RAM, seeing that the upper limit of that memory is used by the O/S. And moving to Linux won't solve that. There are some clever things you can do with memory (especially on Linux), but these are mainly workarounds.

A 64-bit processing architecture would solve this. There is no practical limit of addressable memory per process, and any application that relies heavily on data processing could benefit from more processing cycles.

There are other ways to ensure that your production system stays manageable. Archiving is probably the best strategy. You can keep your production system flying by ensuring that you store only "current" data in the production environment, and archive the data to a secondary, larger and slower system. With current regulations, data needs to be kept online for longer periods, and doing a tape or disk backup and putting it in a safe is not good enough. I'll do another post on archiving at a later stage. This client decided that they would throw hardware at the problem. This can (and probably will eventually) backfire: a faster, bigger system allows you to collect and store more data in a shorter space of time. Already, statistics say that data is doubling every two years.

Back to the Migration
After lots of investigation, testing, and sitting in labs with hardware vendors, providers, and partners, we decided to go for the IBM OpenPower 720E, RHEL 4, and an IBM blade solution (all Intel servers). The client decided to move the complete architecture to one vendor (IBM), so the SAN, domain controllers, and everything was moved to IBM hardware to get answers from as few vendors as possible in the case of a failure.

The OpenPower would run all three production database servers (Sybase ASE). This meant we were consolidating three separate machines (all 3.2 GHZ 4-way HP Proliant, 6GB RAM each) into one machine - 4 CPUs, 24GB of RAM. (I pushed for 32, the maximum the box could take, but no luck).

I'm not going to go into too much of the installation and configuration details, but it was fairly painless. There were some issues that were fixed pretty easily, and after some extra Linux tuning, here are some of the most important statistics:

• The customer runs a "payment-run" every week, per country. The payment-run for the largest country took more than six hours on the older system. New system: 45 minutes.
• Another daily process to summarize account details normally took 17 minutes. New system: 3 minutes.
• An application that does B2B style transaction processing took 8 seconds per transaction previously. Currently: 1 transaction per second.
• CPU usage is down from 80% to 35% on average. And remember, three database servers were consolidated into one.

Page 2 of 2   « previous page