With the help of Compaq Engineering support we were able to gradually improve
the performance of the Oracle 8.0.6 C++ application until the run time fell
within acceptable limits. Instead of running seven times as long, we found that
the the application would run from 1.2 to 1.5 times as long compared to the
7.3.4 V4.0E performance. Here is the list of changes:
1) Upgraded to Tru-64 UNIX 4.0F with patch kit 4. Patch kit 4 contains changes
designed to improve the performance of highly contended applications running in
an EV6 SMP environment.
2) Inserted C++ malloc tuning code snippet into program:
#include <limits.h>
#include <sys/types.h>
unsigned long __noshrink = 1;
size_t __minshrink = 65536;
double __minshrinkfactor = 0.001;
size_t __mingrow = 65536;
double __mingrowfactor = 0.1;
unsigned long __madvisor = 0;
unsigned long __small_buff = 0;
int __fast_free_max = INT_MAX;
unsigned long __sbrk_override = 0;
unsigned long __taso_mode = 0;
int __max_cache = 27;
int __first_fit = 2;
int __delayed_free = 1;
This code increased the application performance.
3) Upgraded the Compaq C++ Compiler to version 6.2.1 from version 6.11. The
C++ program performed better after compilation with 6.2.1.
4) Linked the C++ program with -laio_raw which caused the executable to be
threadsafe. This change significantly increased the performance of the program
by not executing the memory management code needed for threaded applications.
Vinod, I am not sure if any of the steps will translate into the HP environment
except possibly step 4). However, I think that the Rogue Wave tools require
multi-threading so linking the program with -laio_raw would fail.
Marc Brandon, Alay Shah
Allegiance Healthcare
----ORIGINAL MESSAGE----
We are looking for some advice in resolving a recent performance
problem with an Oracle C++ application. The app reads Oracle table
data into memory and then uses the data to update records in a flat
file.
Until recently the app ran on an 8400 running Digital UNIX 4.0E, and
connected to a server machine running Oracle 7.3.4. Oracle was
upgraded to 8.0.6 on the server machine. A week later, the 8400 was
upgraded to DU 4.0F.
The application programmers notified us of a sevenfold increase in the
app's elapsed clock time after the Oracle and UNIX upgrades. The
performance degradation was eventually determined to have started after
the upgrade to Oracle 8.0.6 but before the UNIX 4.0F upgrade.
After analysis we determined that the problem was related to linking
the program with Oracle 8.0.6 libs as opposed to Oracle 7.3.4 libs. If
the program was linked with Oracle 7.3.4 libs then the elapsed clock
time was normal. If the program was linked with Oracle 8.0.6 libs then
the elapsed clock time was about 7 times normal.
It appears that the performance degradation occurs because Oracle
8.0.6 client turns on Asynchronous I/O. Asynch I/O links in
'libaio.so' which causes the program to be run as a multi-threaded
program, regardless of whether the multi-threading is coded or not.
This causes a different instruction path to be used for memory
management. Oracle 7.3.4 client does not use Asynch I/O.
The programmers added some Compaq recommended malloc tuning variables
to the C++ application which reduced the elapsed run time by a third.
We still must find a way to reduce the elapsed run time so it equals
the pre-8.0.6 run time. Any ideas are appreciated.
Alay Shah
Allegiance Healthcare
1400 Waukegan Rd.
McGaw Park, IL 60085
Ph: 847.578.2584
Fax:847.578.5586
E:mail:unixadmin_at_allegiance.net
Received on Thu Jan 04 2001 - 17:05:01 NZDT