Progress 9.1D on Solild State Disks

[TomBascom]

I can say with 99.44% certainty that it is definitely not at it's highest performance now.

This configuration is not "designed" with anything in mind -- it's just a default splatter of stuff.

But it is not clear if the current bottleneck is disk IO or not. It might be but you have not provided any measurements that backup that idea.

I cannot say if your tests are valid or not. I haven't seen any details and don't know enough about how they were run or what the results were. But such things can be tricky.

 

[drewser001]

Tom (and others), I appreciate your time in responding, and I know the challenge I have taken on is a bit on the extreme. I am willing to provide what data and test results I can if you are interested in seeing the outcome of this endeavor.

I attached the IOMeter test results two posts above which show the IOPS and data throughput for the different RAID configurations. I can attach the IOMeter file with the test parameters as well if you'd like, so you can see what tests were performed on all of the drive configurations listed. The Fujitsu test results mirror what is in the production server now (two 15K Ultra320 SCSI disks, RAID 1).

 

[LarryD]

In the FWIW category

We have a customer that has a 50GB database on Intel enterprise SSD's where the performance is extremely fast. We converted to this system in Jan, and we saw improvements in our large batch jobs anywhere from 20% to 40%+. (It also didn't hurt adding another 8GB of memory, going from 4CPU's to 12CPU's, and tuning to take advantage of the bigger/better/faster HW)

Granted, our configurations are different as we are on Linux OE102B using Type II storage and the system tuned amongst other things, not Windows with V9 and all the data/indexes in the schema area.

It really sounds like you need some serious DBA help... the person (initials are TB) that is giving you the help here would fit the bill. And no doubt there are others on this forum and elsewhere who can provide that service.

 

[TomBascom]

Is the test server identical hardware to production? (Other than the obvious SSD difference.)

Was your test run against a "hot" database? (One that had been running realistically so that needed data would be reasonably likely to be cached?)

That last point is important -- I once had a customer almost reject a million dollar hardware upgrade because they were testing against a cold database and saw a similar "but my super-duper new hardware is slower" moments. It took a week of very intense testing to convince them it was their imagination. Once they did finally go live everything was fine. I'm not saying that that is definitely your situation. But it could be.

 

[TomBascom]

The test results that I am most interested in are tests of your Progress application.

It would be very interesting know what the comparative key DB and OS performance metrics were showing during those test runs. For example:

MRP run #1, production

Parameters
Start time
Finish Time
PROMON, R&D Activity, Summary snapshot at beginning
PROMON, R&D Activity, Summary snapshot at end
PerfMon data, especially regarding disk IO operations, network traffic and CPU utilization
​

MRP run #1, test

Parameters
Start time
Finish Time
PROMON, R&D Activity, Summary snapshot at beginning
PROMON, R&D Activity, Summary snapshot at end
PerfMon data, especially regarding disk IO operations, network traffic and CPU utilization
​

The PROMON "Summary" screen looks like this:

04/15/11        Activity: Summary
18:07:04        01/29/11 12:46 to 04/15/11 18:03 (1828 hrs 16 min)

Event                  Total  Per Sec |Event                  Total  Per Sec

Commits            73637616      11.2 |DB Reads            3774282K    587.2
Undos                     0       0.0 |DB Writes           1416067       0.2
Record Reads       34946876K   5437.1 |BI Reads             628831       0.1
Record Updates       494745       0.1 |BI Writes           3532748       0.5
Record Creates     48469096       7.4 |AI Writes                 0       0.0
Record Deletes            0       0.0 |Checkpoints            1670       0.0
Record Locks         230211K     35.8 |Flushed at chkpt        163       0.0
Record Waits             19       0.0 |Active trans              0

Rec Lock Waits     0 %    BI Buf Waits      0 %    AI Buf Waits      0 %
Writes by APW     70 %    Writes by BIW    96 %    Writes by AIW     0 %
DB Size:          41 GB   BI Size:         64 MB   AI Size:          0 K
Empty blocks:  10346      Free blocks:    609      RM chain:        19
Buffer Hits       94 %    Primary Hits     94 %    Alternate Hits    0 %

0 Servers, 5 Users (5 Local, 0 Remote, 5 Batch), 2 Apws

(Usually I tell people that I want "samples" during problem periods -- but in this case you are doing a controlled test so the math is easy enough.)

So if, for instance, the production run shows similar record activity but a very different number of "DB Reads" or "DB Writes" then it might be that the cache is busy being loaded (or it is configured with much less RAM on one server compared to the other). There are, of course, lots of other conclusions that can be drawn from other relationships -- that was just one example.

 

[Choopewap]

Progress 9 1D on Solild State Disks

Congrats on the progress Mind if I ask, are you being vegan just for this weight-loss test, or did the vegan change happen to occur during this process?

 

[TomBascom]

Re: Progress 9 1D on Solild State Disks

Veggies aren't food. Veggies are what food eats.