RE: [PHP-DB] OCI8 Memory Leak?

From: Date: Fri, 20 Feb 2004 20:32:25 +0000
Subject: RE: [PHP-DB] OCI8 Memory Leak?
Groups: php.db 
Request: Send a blank email to php-db+get-33049@lists.php.net to get a copy of this message
Thanks a lot for the response, Greg. I poked around quite a bit in the PEAR::DB source, and everything at first glance looks OK. Connections are closed properly, etc. After doing a little more digging on the Web, I noticed a mention to remove any reference to "SERVER=DEDICATED" from Oracle's tnsnames.ora file. I did, and it seems to have helped... though I'm not convinced. Thanks! Shawn -----Original Message----- From: Greg Skouby [mailto:gskouby@sitesnow.com] Sent: Friday, February 20, 2004 3:28 PM To: Shawn Coomey Subject: RE: [PHP-DB] OCI8 Memory Leak? Hi Shawn, We are using almost the exact same setup that you describe without the PEAR abstraction. We host a moderate sized application on this box and it has performed flawlessly. My first indication, though I don't know why it would be happening, is that there is a problem in the PEAR abstraction level. --Greg -----Original Message----- From: Shawn Coomey [mailto:shawn.coomey@cubist.com] Sent: Friday, February 20, 2004 11:38 AM To: php-db@lists.php.net Subject: [PHP-DB] OCI8 Memory Leak? Hi folks- I am building an application which uses OCI8 functions (abstracted with PEAR::DB) to perform queries against an Oracle 9i database. Here's my platform info: Solaris 8 (SunOS 5.2) on a Sun Ultra II workstation Oracle 9i PHP 4.3.5RC2-dev Apache 1.3.29 Here's my problem: Everything works well, but over time the Apache httpd processes start to take huge amounts of memory: for instance: I checked this morning and each of the apache processes running were using over 125MB per instance, and the server had slowed to a standstill. The processes upon restart use between 15-20MB per instance. Is there something in the Oracle client configuration or in php/pear that can lead to this sort of memory problem? Any help is greatly appreciated. Shawn

« previous php.db (#33049) next »