|
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-2026 The PHP GroupAll rights reserved. |
Last updated: Thu Jan 01 19:00:02 2026 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);