|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2015-11-12 18:55 UTC] nhojohl at gmail dot com
Description:
------------
We have a few extremely long running PHP command line scripts that experience continual memory usage growth until eventually running out of memory altogether. It took awhile to narrow down the cause, but I believe there's a memory leak in the PDO connection creation process for the MySQL driver.
If you create a connection, any attempt to destroy it will still leave you with a memory usage growth of ~900 bytes.
php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
json
libxml
mbstring
memcached
mhash
mysql
mysqli
mysqlnd
newrelic
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
pthreads
readline
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xdebug
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib
[Zend Modules]
Xdebug
Zend OPcache
Test script:
---------------
<?php
$attributes = array(
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_TIMEOUT => 30,
PDO::MYSQL_ATTR_SSL_CA => '/etc/pki/tls/certs/mysql-ssl-ca-cert.pem',
PDO::MYSQL_ATTR_COMPRESS => true
);
for ($i = 0; $i < 100000; ++$i) {
$db = null;
try {
$db = new PDO('mysql:host=localhost;port=3306;dbname=test;charset=utf8', 'test', 'abc123', $attributes);
} catch (PDOException $e) {
echo $e->getMessage();
}
$db = null;
echo memory_get_usage().'/'.memory_get_usage(true)."\n";
}
Expected result:
----------------
Semi-consistent memory usage
Actual result:
--------------
Memory usage continually grows
229016/262144
229912/262144
230808/262144
231704/262144
232664/262144
233560/262144
234456/262144
235352/262144
236248/262144
237144/262144
238064/262144
238960/262144
239984/262144
240880/262144
241800/262144
242696/262144
243592/262144
244512/262144
245408/262144
246304/262144
247224/262144
248120/262144
249016/262144
249920/262144
250816/262144
251712/524288
252632/524288
253528/524288
254680/524288
255576/524288
256472/524288
257368/524288
258288/524288
259184/524288
260080/524288
....
PatchesPull Requests
Pull requests:
HistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Tue Apr 23 07:01:29 2024 UTC |
After further testing it appears the PDO's destructor isn't always called - occurs with every PDO driver, including SQLite. Another simple example: 1. Create a directory named "test.sqlite" 2. Run the following test script in the directory that contains the test.sqlite directory ---- <?php for ($i = 0; $i < 100000; ++$i) { $db = null; try { $db = new PDO('sqlite:test.sqlite'); } catch (PDOException $e) { echo $e->getMessage(); } $db = null; echo memory_get_usage().'/'.memory_get_usage(true)."\n"; } ---- 3. You should get an exception for "SQLSTATE[HY000] [14] unable to open database file" and continually increasing memory usage - `dbh_free` in `php-src/ext/pdo/pdo_dbh.c` will not be called until the script exits. It should be called when the exception occurs and `new PDO` returns null. I've submitted a pull request that resolves the issue.