Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.misc -> Re: Multi-threaded OCI Application Does Not Scale
What clues do you get from checking the
v$session_event view ? When you run
multiple threads, do they show waits for
message from client,. or do they show waits
for database events ?
-- Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) ____England______January 21/23 ____USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html Cary Lapoint wrote in message <6b0e1783.0301221537.5849e673_at_posting.google.com>...Received on Thu Jan 23 2003 - 14:42:30 CST
>Hello,
>
>I have written a multi-threaded (pthreads) OCI program that INSERT's
>large quantities of data into an Oracle database. It works very
>reliably but does not scale well at all. To be specific, as the
>number of threads increases, the total import rate decreases
slightly!
> However, as the number of separate concurrent program instances
>(processes) increases, the total import rate increases almost
linearly
>until maxing out available system resources. The issue is currently
>under review by Oracle Support, but since it is a severity 4 problem,
>it might never be resolved. These are the facts. Identical behavior
>has been observed on a Solaris system running Oracle 8.1.7.0.0 and a
>Linux box running Oracle 8.1.7.0.1. Each loader thread has its own
>dedicated environment handle created using OCIEnvCreate() with
>OCI_THREADED | OCI_ENV_NO_MUTEX | OCI_OBJECT and a single session.
>Timing code embedded in the program shows that all examined
>sub-operations except one actually do scale reasonably well.
>Unfortunately, the one that does not, the OCIStmtExecute() call that
>performs the array INSERT's, dominates the overall program
>performance. Has anyone observed this behavior before? Can anyone
>cite/describe a database-intensive multi-threaded OCI application
that
>does scale well? Any advice? Should it even be necessary to use
>OCI_THREADED since I use completely separate environment handles
>(still a little unclear on this point)? Thanks in advance.
>
>
>Cary
![]() |
![]() |