我遇到一个PHP脚本的问题，得到以下错误信息：
Fatal error: Out of memory (allocated 359923712) (tried to allocate 72 bytes) in /path/to/piwik/core/DataTable.php on line 969
我正在运行的脚本是： /path/to/piwik/misc/cron/archive.sh
我假设数字是字节，这意味着总数大约是360MB。
对于所有的意图和目的，我已经增加了服务器上的内存限制远远高于360MB，但这是数字（给出或占用一个字节）它始终如一地出错。
请注意 ：这个问题不是关于在脚本中修复内存泄漏问题，也不是为什么脚本本身使用这么多的内存。 该脚本是Piwik存档过程的一部分，所以我不能修正任何内存泄漏等。有关此脚本的更多信息以及为什么增加内存限制，请参阅“如何设置自动归档”
考虑到脚本正试图使用超过360MB的内存，我无法改变，为什么我似乎不可能增加我的服务器上可用的内存量？
6月23日更新 ：请参阅下面的“我试过的”>“增加Linux的每进程内存限制”如果我设置了ulimit -v 1024000 ，那么使用ulimit -v检查它是否正确。 '1024000'。 如果我再次运行这个脚本，它将会进一步发展，但是最终会以相同的内存限制（〜360MB）出错。 如果我立即检查ulimit -v ，它已经重置为原始值'524288'。 这看起来好像可能是问题的根源。
增加PHP的memory_limit
鉴于php.ini文件：
php -i | grep php.ini Configuration File (php.ini) Path => /usr/local/lib Loaded Configuration File => /usr/local/lib/php.ini
我已编辑该文件，所以memory_limit指令读取;
memory_limit = -1
重新启动Apache，并检查新值是否卡住;
$ php -i | grep memory_limit memory_limit => -1 => -1
运行脚本，并得到相同的错误。
我也尝试了1G ， 768M等，都达到了相同的结果（即不变）。
6月22日更新 ：基于Vangel的帮助 ，我试图将post_max_size设置为20M，并设置memory_limit 。 再次，这没有效果。
6月23日更新 ：基于olefebvre的帮助 ，我可以确认运行该脚本的用户具有对包含memory_limit设置的php.ini文件的读/写权限。
删除Apachesubprocess的内存限制
我find并编辑了httpd.conf文件，以确保没有RLimitMEM指令。
然后，我使用WHM的Apacheconfiguration>内存使用限制来产生一个限制，它声称是在1000M（并通过检查httpd.conf确认）。
这两个都导致在360MB脚本错误没有改变。
增加Linux的每进程内存限制
系统上设置的当前限制：
$ ulimit -m 524288 $ ulimit -v 524288
我试图把这两个都设为无限制：
$ ulimit -m unlimited $ ulimit -v unlimited $ ulimit -m unlimited $ ulimit -v unlimited
再次，这导致了我的问题绝对没有改善。
6月23日更新 ：我在这里遇到了一个相关的问题。 如果我设置ulimit -v 1024000 ，那么用ulimit -v检查一下，我得到正确的值“1024000”。 如果我再次运行这个脚本，它将会进一步发展，但是最终会达到相同的内存限制。 如果我立即检查ulimit -v ，它已经重置为原始值'524288'。 这看起来好像可能是问题的根源。
$ cat /etc/redhat-release CentOS release 5.5 (Final) $ uname -a Linux example.com 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux $ php -i | grep "PHP Version" PHP Version => 5.2.9 $ httpd -V Server version: Apache/2.0.63 Server built: Feb 2 2011 01:25:12 Cpanel::Easy::Apache v3.2.0 rev5291 Server's Module Magic Number: 20020903:13 Server loaded: APR 0.9.17, APR-UTIL 0.9.15 Compiled using: APR 0.9.17, APR-UTIL 0.9.15 Architecture: 64-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/local/apache" -D SUEXEC_BIN="/usr/local/apache/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf"
$ php -i输出： http : //pastebin.com/EiRut6Nm
背景：
我刚刚抓住了当前版本的Piwik – 在1.5版本中，969行显示为：
public function addRowsFromSerializedArray( $stringSerialized ) { $serialized = unserialize($stringSerialized); if($serialized === false) { throw new Exception("The unserialization has failed!"); } $this->addRowsFromArray($serialized); }
特别是$serialized = unserialize($stringSerialized); 。 反unserialize的调用可能是令人难以置信的内存密集型。 这里有一个很好的post。
正如你所说， 这显然不是你的脚本中的错误，是一个有效的内存不足 。
build议：在configuration文件中，正如上面在我的评论中指出的那样：
/.../piwik/config/global.ini.php
我想你可能需要增加其中的一个限制：
# during archiving, Piwik will limit the number of results recorded, for performance reasons # maximum number of rows for any of the Referers tables (keywords, search engines, campaigns, etc.) # this limit will also be applied to the Custom Variables names and values reports datatable_archiving_maximum_rows_referers = 1000 # maximum number of rows for any of the Referers subtable (search engines by keyword, keyword by campaign, etc.) datatable_archiving_maximum_rows_subtable_referers = 50 # maximum number of rows for any of the Actions tables (pages, downloads, outlinks) datatable_archiving_maximum_rows_actions = 500 # maximum number of rows for pages in categories (sub pages, when clicking on the + for a page category) # note: should not exceed the display limit in Piwik_Actions_Controller::ACTIONS_REPORT_ROWS_DISPLAY # because each subdirectory doesn't have paging at the bottom, so all data should be displayed if possible. datatable_archiving_maximum_rows_subtable_actions = 100 # maximum number of rows for other tables (Providers, User settings configurations) datatable_archiving_maximum_rows_standard = 500
在那里我把分号改为＃号，只是为了让sf的autocolor可读。
您也可以尝试添加：
CMD_TO_CHECK_SETTINGS="$PHP_BIN -i > /tmp/piwik-php-env.out" $CMD_TO_CHECK_SETTINGS
到archive.sh以确定是否有其他设置正在进行覆盖php.ini文件。
M. Tibbits回答说 ，允许Piwik在归档过程中使用更多的资源。
SQL命令可以执行的大小有一个限制，默认只有1MB。 欲了解更多信息; 包太大了
要增加MySQL的大小限制，编辑/etc/my.cnf并设置max_allowed_packet=32M
通过编辑/usr/local/lib/php.ini确保PHP内存限制设置为每个分支进程足够高，并设置memory_limit = 512M
最后，通过在命令行上执行ulimit -v 1048576
更新
ulimit -v 1048576只会提高软限制。 如果硬限制不够高，系统会自动将软限制重置为限制硬限制。
要设置硬限制，请添加-H开关：
ulimit -vH 1048576
然后将软限制增加到此值：
ulimit -vS 1048576
这绝对是一个脚本错误。 似乎有一个内存泄漏，所以无论你增加多less内存限制在PHP中，它会打。
我在基础层面上使用Piwik，不记得直接使用存档脚本。 Piwik仍然有点bug，但最新的版本是1.4，似乎没有以前那么多。
为了适应错误的脚本，我build议不要使用系统或PHP设置。 打piwik支持论坛可能是一个更好的主意
你有没有尝试使用定义的命令行选项？ php -d memory_limit = 512M test.php
顺便说一句你检查了php.ini是从命令行运行PHP的用户可读？
Linux per proc /用户限制与此无关; 你得到的错误是专门绑定到PHP。
在那个笔记上，我怀疑有一个ini_set指令覆盖了你的极限。 即使您将ini_set放在顶层文件上，底层文件也会覆盖它。
只需运行`grep -r -i“ini_set”/ path / to / piwiki“，看看是否手动覆盖了限制。
你能确认哪个configuration文件修改了内存限制吗？ 请注意，有两个不同的configuration：一个用于通过Web服务器执行PHP，另一个用于通过CLI执行PHP。
~$ ls /etc/php5/ apache2 cli conf.d ~$ ls /etc/php5/apache2/ conf.d php.ini ~$ ls /etc/php5/cli/ conf.d php.ini
另外，如果通过浏览器执行，则在实际脚本所在的目录中创build一个temp.php文件，其中包含以下内容：
<?php phpinfo(); ?>
检查memory_limit显示的内容，当您浏览到该文件。
我上周有这个问题，我在CentOS rehel的solutiosn是
nano /etc/httpd/conf/hpptd.conf
searchRLimitMEM指令删除或禁止使用该指令或者如果使用允许2000000的值