php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49560 OCI_RETURN_LOBS causes php_shutdown to take very long
Submitted: 2009-09-15 12:20 UTC Modified: 2010-02-03 20:32 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: j dot henge-ernst at interexa dot de Assigned: sixd (profile)
Status: Closed Package: OCI8 related
PHP Version: 5.2.10 OS: linux
Private report: No CVE-ID: None
 [2009-09-15 12:20 UTC] j dot henge-ernst at interexa dot de
Description:
------------
If you read a lot of clobs/blob via oci_fetch_array($stmt, OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS) it causes php_shutdown to take a very long time.

Depending on the rows you read via oci_fetch_array the php_shutdown takes longer and longer. Examples:

10.000  rows read with one lob column  0.1 seconds
20.000  rows read with one lob column    2 seconds
30.000  rows read with one lob column    8 seconds
40.000  rows read with one lob column   28 seconds
50.000  rows read with one lob column   60 seconds
100.000 rows read with one lob column 1800 seconds

This also happens if you skip the OCI_RETURN_LOBS and you don't use ->free on the returned lob-object.

Tested with oci8 extension form php 5.2.10 and php 5.3.0

Reproduce code:
---------------
$conn       = oci_connect($user, $user, $db);
$tcst = oci_parse($conn, 'CREATE TABLE TESTTABLE ( PK NUMBER NOT NULL, TB BLOB , CONSTRAINT TABLE1_PK PRIMARY KEY ( PK) ENABLE)');
oci_execute($tcst);
oci_free_statement($tcst);
for ($i = 1; $i <= 10000; ++$i) {
     $stmt = oci_parse($conn, "insert into testtable (PK, TB) values(:PK, :TB)");
     oci_bind_by_name($stmt, ':PK', $i, -1);
     $lob  = oci_new_descriptor($conn, OCI_DTYPE_LOB);
     oci_bind_by_name($stmt, ':TB', $lob, -1, OCI_B_BLOB);
     $lob->writeTemporary('aaaaaaaaaaaaaaaaaaaa', OCI_TEMP_BLOB);
     oci_execute($stmt, OCI_DEFAULT);
     $lob->close();
     $lob->free();
     oci_free_statement($stmt);
}
oci_commit($conn);
for ($i = 0; $i <= 10; ++$i) {
    $stmt = oci_parse($conn, 'Select PK, TB FROM TESTTABLE');
    oci_execute($stmt, OCI_DEFAULT);
    OCISetPrefetch($stmt, 100);
    while (($row = oci_fetch_array($stmt, OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS )) !== false);
    oci_free_statement($stmt);
}



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-09-15 15:17 UTC] sixd@php.net
What version Oracle client and database?

By shutdown do you mean end-of-web-request, or shutdown of the PHP process?

It might be a symptom of a LOB ref count issue we've recently uncovered, or it might just be Oracle having to clean up.


 [2009-09-15 15:37 UTC] j dot henge-ernst at interexa dot de
Using oracle 11 instant client with Oracle 11.0.7 database

yes end of the php process. After the php script on the command line has finished the gdb shows something like the following in the backtrace:
0x00007f5e231da5b0 in php_oci_descriptor_delete_from_hash (data=0x7f35610, id=0xbb8ebe8)
    at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
1497            if (descriptor && desc_id && descriptor->id == *desc_id) {
(gdb) where
#0  0x00007f5e231da5b0 in php_oci_descriptor_delete_from_hash (data=0x7f35610, id=0xbb8ebe8)
    at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
#1  0x00000000007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
    apply_func=0x7f5e231da57d <php_oci_descriptor_delete_from_hash>, argument=0xbb8ebe8)
    at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
#2  0x00007f5e231e5c9c in php_oci_lob_free (descriptor=0xbb8ebe8) at /home/hernst/src/php-5.3.0/ext/oci8/oci8_lob.c:672
#3  0x00007f5e231da3c4 in php_oci_descriptor_list_dtor (entry=0xbb8e5d8) at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1386
#4  0x000000000075276a in list_entry_destructor (ptr=0xbb8e5d8) at /home/hernst/src/php-5.3.0/Zend/zend_list.c:184
#5  0x0000000000750163 in zend_hash_apply_deleter (ht=0xd680f0, p=0xbb8ec30) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:611
#6  0x0000000000750255 in zend_hash_graceful_reverse_destroy (ht=0xd680f0) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:646
#7  0x00000000007528ba in zend_destroy_rsrc_list (ht=0xd680f0) at /home/hernst/src/php-5.3.0/Zend/zend_list.c:240
#8  0x0000000000740e21 in zend_deactivate () at /home/hernst/src/php-5.3.0/Zend/zend.c:896
#9  0x00000000006d812d in php_request_shutdown (dummy=0x0) at /home/hernst/src/php-5.3.0/main/main.c:1576
#10 0x000000000081e11e in main (argc=3, argv=0x7fff9852fb98) at /home/hernst/src/php-5.3.0/sapi/cli/php_cli.c:1369

(gdb) up
#1  0x00000000007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
    apply_func=0x7f5e231da57d <php_oci_descriptor_delete_from_hash>, argument=0xbb8ebe8)
    at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
(gdb) print ht->nTableSize
$1 = 262144


I run the script from commandline with
time php script.php 10
When the php script has outputed the last thing the php process takes very long till it finaly returns to the command line.
Guess it's more like a oci_free_lob-count issue you mentoined. Is there a newer version to try?
 [2010-01-06 18:58 UTC] svn@php.net
Automatic comment from SVN on behalf of sixd
Revision: http://svn.php.net/viewvc/?view=revision&revision=293180
Log: Fixed bug #49560 (oci8: using LOBs causes slow PHP shutdown)
 - Improved descriptor refcounting to remove unneeded items sooner
 - Replaced n^2 list traversal during descriptor list destruction
 [2010-01-06 19:02 UTC] sixd@php.net
---------

A fix has been merged to PHP 5.3.3 and a request for it to be merged to 
5.3.2 has been made to the Release Manager.

The fix will be in PECL OCI8 1.4.1+
 [2010-02-03 19:37 UTC] svn@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=294441
Log: - Fixed bug #49560 (oci8: using LOBs causes slow PHP shutdown)
 [2010-02-03 20:32 UTC] sixd@php.net
This fix has been merged to PHP 5.3.2
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 14:01:32 2024 UTC