|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2003-03-25 17:32 UTC] thekid@php.net
[2003-03-27 07:07 UTC] sniper@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 01:00:01 2025 UTC |
Large selection sets using sybase_query use too much memory, since it pulls the entire result set into memory. In my example, the memory of the httpd daemon quickly builds to about 155MB before the 30 second timeout. I had figured that sybase_unbuffered_query would solved that problem. Unfortunately, it also bleeds memory, however not as bad. It raises the memory usage of the httpd daemon to 53MB before the 30 second timeout. I believe this is either a memory leak, or unbuffered query is actually still buffering something. Below is a simplified example that shows the memory leak. I am using Solaris 7, Sybase 11.9.2, and PHP 4.3.0. Chuck --------------------------- sybase_min_server_severity(11); $con = sybase_connect('peach5026d', 'may', '********'); sybase_select_db('db_dev', $con); $fp = fopen('test.csv', "w"); // open the output file $query = sybase_unbuffered_query("SELECT * FROM vial v WHERE v.study_id = 'ACC'", $con); $max = sybase_num_fields($query); while($row = sybase_fetch_row($query)) { $elements = array(); for ($j = 0; $j < $max; $j++) $elements[] = $row[$j]; fwrite($fp, implode(',', $elements) . "\r\n"); } @sybase_free_result($query); fclose($fp); // close the file @sybase_close($con);