当前位置： 文江博客话题详情

是什么原因导致“无法为池分配内存”？在 PHP 中？

发布于 2024-09-19 07:59:26 字数 172 浏览 8 评论 0原文

我偶尔会遇到服务器的内存分配限制，特别是对于像 Wordpress 这样臃肿的应用程序，但从未遇到过“无法为池分配内存”并且无法跟踪任何信息。

有谁知道这意味着什么？我尝试增加 memory_limit 但没有成功。我也没有对应用程序进行任何重大更改。有一天没问题，第二天就出现这个错误。

原文

I've occasionally run up against a server's memory allocation limit, particularly with a bloated application like Wordpress, but never encountered "Unable to allocate memory for pool" and having trouble tracking down any information.

Does anyone know what this means? I've tried increasing the memory_limit without success. I also haven't made any significant changes to the application. One day there was no problem, the next day I hit this error.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（12）

一袭水袖舞倾城 2024-09-26 07:59:26

使用 TTL 为 0 意味着 APC 在内存不足时将刷新所有缓存。该错误不再出现，但它使 APC 的效率大大降低。这是一个没有风险、没有麻烦、“我不想做我的工作”的决定。 APC 不应该这样使用。您应该选择足够高的 TTL，以便最常访问的页面不会过期。最好是提供足够的内存，这样 APC 就不需要刷新缓存。

只需阅读手册即可了解如何使用 ttl ： http: //www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

解决方案是增加分配给APC的内存。
通过增加 apc.shm_size 来实现这一点。

如果 APC 被编译为使用共享段内存，您将受到操作系统的限制。键入此命令以查看每个段的系统限制：

sysctl -a | grep -E "shmall|shmmax"

要分配更多内存，您必须使用参数 apc.shm_segments 增加段数。

如果 APC 使用 mmap 内存，则没有限制。内存量仍然由相同的选项 apc.shm_size 定义。

如果服务器上没有足够的内存，则使用过滤器选项来防止缓存不常访问的 php 文件。

但切勿使用 TTL 0。

正如 c33s 所说，使用 apc.php 来检查您的配置。将文件从 apc 包复制到 web 文件夹并将浏览器指向它。您将看到实际分配的内容以及如何使用它。图表必须在数小时后保持稳定，如果它们在每次刷新时完全改变，则意味着您的设置是错误的（APC 正在刷新所有内容）。分配比 APC 实际使用的内存多 20% 作为安全余量，并定期检查。

默认只允许 32MB，这个值低得离谱。 PHP 是在服务器大小为 64MB 并且大多数脚本每页使用一个 php 文件时设计的。如今，像 Magento 这样的解决方案需要超过 10k 个文件（在 APC 中约为 60Mb）。您应该允许足够的内存，以便大多数 php 文件始终被缓存。这不是浪费，将操作码保存在 RAM 中比将相应的原始 php 保存在文件缓存中更有效。
如今，我们可以以低至每月 80 美元的价格找到具有 24Gb 内存的专用服务器，因此请毫不犹豫地为 APC 提供几 GB 内存。我将 24GB 中的 2GB 放在托管 5Magento 商店和约 40 个 WordPress 网站的服务器上，APC 使用 1.2GB。 Magento 安装需要 64MB，带一些插件的 Wordpress 安装需要 40MB。

另外，如果您在同一服务器上有开发网站。将它们从缓存中排除。

Using a TTL of 0 means that APC will flush all the cache when it runs out of memory. The error don't appear anymore but it makes APC far less efficient. It's a no risk, no trouble, "I don't want to do my job" decision. APC is not meant to be used that way. You should choose a TTL high enough so the most accessed pages won't expire. The best is to give enough memory so APC doesn't need to flush cache.

Just read the manual to understand how ttl is used : http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

The solution is to increase memory allocated to APC.
Do this by increasing apc.shm_size.

If APC is compiled to use Shared Segment Memory you will be limited by your operating system. Type this command to see your system limit for each segment :

sysctl -a | grep -E "shmall|shmmax"

To alocate more memory you'll have to increase the number of segments with the parameter apc.shm_segments.

If APC is using mmap memory then you have no limit. The amount of memory is still defined by the same option apc.shm_size.

If there's not enough memory on the server, then use filters option to prevent less frequently accessed php files from being cached.

But never use a TTL of 0.

As c33s said, use apc.php to check your config. Copy the file from apc package to a webfolder and point browser to it. You'll see what is really allocated and how it is used. The graphs must remain stable after hours, if they are completly changing at each refresh, then it means that your setup is wrong (APC is flushing everything). Allocate 20% more ram than what APC really use as a security margin, and check it on a regular basis.

The default of allowing only 32MB is ridiculously low. PHP was designed when servers were 64MB and most scripts were using one php file per page. Nowadays solutions like Magento require more than 10k files (~60Mb in APC). You should allow enough memory so most of php files are always cached. It's not a waste, it's more efficient to keep opcode in ram rather than having the corresponding raw php in file cache.
Nowadays we can find dedicated servers with 24Gb of memory for as low as $80/month, so don't hesitate to allow several GB to APC. I put 2GB out of 24GB on a server hosting 5Magento stores and ~40 wordpress website, APC uses 1.2GB. Count 64MB for Magento installation, 40MB for a Wordpress with some plugins.

Also, if you have developpment websites on the same server. Exclude them from cache.

回复 原文
一片旧的回忆 2024-09-26 07:59:26

可能与 APC 相关。

对于有此问题的人问题，请指定您的 .ini 设置。特别是你的 apc.mmap_file_mask 设置。

对于文件支持的 mmap，应设置为类似以下内容： 要

apc.mmap_file_mask=/tmp/apc.XXXXXX

直接从 /dev/zero 进行 mmap，请使用：

apc.mmap_file_mask=/dev/zero

对于 POSIX 兼容的共享内存支持的 mmap，请使用：

apc.mmap_file_mask=/apc.shm.XXXXXX

Probably is APC related.

For the people having this problem, please specify you .ini settings. Specifically your apc.mmap_file_mask setting.

For file-backed mmap, it should be set to something like:

apc.mmap_file_mask=/tmp/apc.XXXXXX

To mmap directly from /dev/zero, use:

apc.mmap_file_mask=/dev/zero

For POSIX-compliant shared-memory-backed mmap, use:

apc.mmap_file_mask=/apc.shm.XXXXXX
回复 原文
回眸一笑 2024-09-26 07:59:26

我的解决方案：

  • apc.ttl=0
  • apc.shm_size=任何你想要的

编辑开始

警告！

@bokan 指示我应该在此处添加警告。

如果 ttl 为 0，这意味着可以立即清除每个缓存的项目。因此，如果您的缓存大小很小，例如 2mb 且 ttl 为 0，这将使 apc 毫无用处，因为缓存中的数据总是会被覆盖。

降低 ttl 仅意味着缓存不能变满，只能包含无法替换的项目。

所以你必须在 ttl 和缓存大小之间选择一个良好的平衡。

就我而言，我的缓存大小为 1GB，所以对我来说绰绰有余。

编辑结束

在 centos 5 和 php 5.2.17 上有同样的问题，并注意到如果
缓存大小较小且 ttl 参数为“高”（如 7200），而
有很多 php 文件需要缓存，那么缓存很快就会被填满
并且 apc 找不到任何可以删除的内容，因为所有文件都在
缓存仍然适合 ttl。

增加内存大小只是解决方案的一部分，您仍然会遇到
如果缓存已满并且所有文件都在 ttl 内，则会出现此错误。

所以我的解决方案是将 ttl 设置为 0，这样 apc 就会填满缓存
apc 总是有可能清除一些内存以用于新的
数据。

希望有助于

编辑：
另请参阅：http://pecl.php.net/bugs/bug.php? id=16966

下载 http://pecl.php.net/get/APC提取并运行 apc.php，你会看到一个很好的图表，说明你的缓存使用情况如何

solution for me:

  • apc.ttl=0
  • apc.shm_size=anything you want

edit start

warning!

@bokan indicated me that i should add a warning here.

if you have a ttl of 0 this means the every cached item can be purged immediately. so if you have a small cache size like 2mb and a ttl of 0 this would render the apc useless, because the data in the cache gets always overwritten.

lowering the ttl means only that the cache cannot become full, only with items which can't be replaced.

so you have to choose a good balance between ttl and cache size.

in my case i had a cache size of 1gb, so it was more than enough for me.

edit end

had the same issue on centos 5 with php 5.2.17 and noticed that if the
cache size is small and the ttl parameter is "high" (like 7200) while
having a lot of php files to cache, then the cache fills up quite fast
and apc doesn't find anything which it can remove because all files in
the cache still fit in the ttl.

increasing the memory size is only a part solution, you still run in
this error if you cache fills up and all files are within the ttl.

so my solution was to set the ttl to 0, so apc fills up the cache an
there is allways the possibility for apc to clear some memory for new
data.

hope that helps

edit:
see also: http://pecl.php.net/bugs/bug.php?id=16966

download http://pecl.php.net/get/APC extract and run the apc.php, there you have a nice diagram how your cache usage look like

回复 原文
半窗疏影 2024-09-26 07:59:26

IMO，运行 apc.php 脚本是了解问题所在的关键。这帮助我们正确调整缓存大小，目前似乎已经解决了问题。

Running the apc.php script is key to understanding what your problem is, IMO. This helped us size our cache properly and for the moment, seems to have resolved the problem.

回复 原文
也只是曾经 2024-09-26 07:59:26

对于像我这样的新手，这些资源有帮助：

找到 apc.ini 文件以进行上面 c33s 建议的更改，并设置建议的数量：
http://www.untwistedvortex.com/optimizing-tuning-apc- alter-php-cache/

了解 apc.ttl 是什么：
http://www.php.net/manual/en /apc.configuration.php#ini.apc.ttl

了解 apc.shm_size 是什么：
http://www.php.net/manual /en/apc.configuration.php#ini.apc.shm-size

For newbies like myself, these resources helped:

Finding the apc.ini file to make the changes recommended by c33s above, and setting recommended amounts:
http://www.untwistedvortex.com/optimizing-tuning-apc-alternate-php-cache/

Understanding what apc.ttl is:
http://www.php.net/manual/en/apc.configuration.php#ini.apc.ttl

Understanding what apc.shm_size is:
http://www.php.net/manual/en/apc.configuration.php#ini.apc.shm-size

回复 原文
错々过的事 2024-09-26 07:59:26

正如 Bokan 所提到的，如果可用，您可以增加内存，并且他正确地指出将 TTL 设置为 0 会适得其反。

注意：这就是我针对我的特定问题修复此错误的方法。这是一个常见问题，可能是由很多事情引起的，因此，如果您收到错误并且您认为它是由重复的 PHP 文件加载到 APC 引起的，请仅按照以下步骤操作。

我遇到的问题是当我发布我的 PHP 应用程序的新版本。即用新文件替换我的所有 .php 文件，APC 会将两个版本加载到缓存中。

因为我没有足够的内存来容纳两个版本的 php 文件，APC 会耗尽内存。

有一个名为 apc.stat 的选项，告诉 APC 检查特定文件是否已更改，如果已更改，则替换它，这通常适合开发，因为您不断进行更改，但在生产中，它通常会关闭，就像在我的中一样案例 - http://www.php.net/manual /en/apc.configuration.php#ini.apc.stat

如果您对性能影响感到满意，则打开 apc.stat 将解决此问题。

我针对问题提出的解决方案是检查项目版本是否已更改，如果已更改，则清空缓存并重新加载页面。

define('PROJECT_VERSION', '0.28'); 

if(apc_exists('MY_APP_VERSION') ){

    if(apc_fetch('MY_APP_VERSION') != PROJECT_VERSION){
        apc_clear_cache();
        apc_store ('MY_APP_VERSION', PROJECT_VERSION);
        header('Location: ' . 'http'.(empty($_SERVER['HTTPS'])?'':'s').'://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']);
        exit;  
    }

}else{
    apc_store ('MY_APP_VERSION', PROJECT_VERSION);
}

As Bokan has mentioned, you can up the memory if available, and he is right on how counter productive setting TTL to 0 is.

NotE: This is how I fixed this error for my particular problem. Its a generic issue that can be caused by allot of things so only follow the below if you get the error and you think its caused by duplicate PHP files being loaded into APC.

The issue I was having was when I released a new version of my PHP application. Ie replaced all my .php files with new ones APC would load both versions into cache.

Because I didnt have enough memory for two versions of the php files APC would run out of memory.

There is a option called apc.stat to tell APC to check if a particular file has changed and if so replace it, this is typically ok for development because you are constantly making changes however on production its usually turned off as it was with in my case - http://www.php.net/manual/en/apc.configuration.php#ini.apc.stat

Turning apc.stat on would fix this issue if you are ok with the performance hit.

The solution I came up with for my problem is check if the the project version has changed and if so empty the cache and reload the page.

define('PROJECT_VERSION', '0.28'); 

if(apc_exists('MY_APP_VERSION') ){

    if(apc_fetch('MY_APP_VERSION') != PROJECT_VERSION){
        apc_clear_cache();
        apc_store ('MY_APP_VERSION', PROJECT_VERSION);
        header('Location: ' . 'http'.(empty($_SERVER['HTTPS'])?'':'s').'://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI']);
        exit;  
    }

}else{
    apc_store ('MY_APP_VERSION', PROJECT_VERSION);
}
回复 原文
把梦留给海 2024-09-26 07:59:26

这对我们的人来说很有效（在同一台服务器上运行大量 Wordpress 站点）。

更改了 /etc/php.d/apc.ini 文件中的内存设置。它被设置为 64M，所以我们将其加倍至 128M。

apc.shm_size=128M

This worked for our guys (running a slew of Wordpress sites on the same server).

Changed memory settings in the /etc/php.d/apc.ini file. It was set to 64M, so we doubled it to 128M.

apc.shm_size=128M

回复 原文
千纸鹤 2024-09-26 07:59:26

查了一下互联网，可能有多种原因。
就我而言，将所有内容保留为默认值，除了...

apc.shm_size = 64M

...清除了我之前收到的无数警告。

Looking at the internets there can be various of causes.
In my case leaving everything default except...

apc.shm_size = 64M

...cleared the countless warnings that I was getting earlier.

回复 原文
平定天下 2024-09-26 07:59:26

将 OpenCart 安装移动到其他服务器后，我收到错误“无法为池分配内存”。我还尝试提高内存限制。

在我将错误消息中的文件权限更改为具有 apache 运行的用户（apache、www-data 等）的写访问权限后，错误停止了。我没有直接修改 /etc/group （或将文件 chmod-ing 为 0777），而是使用了 usermod：

usermod -a -G vhost-user-group apache-user

然后我必须重新启动 apache 才能使更改生效：

apachectl restart

或者

sudo /etc/init.d/httpd restart

或者您的系统用于重新启动 apache 的任何内容。

如果站点位于共享主机上，也许您必须使用 FTP 程序更改文件权限，或者联系主机提供商？

I received the error "Unable to allocate memory for pool" after moving an OpenCart installation to a different server. I also tried raising the memory_limit.

The error stopped after I changed the permissions of the file in the error message to have write access by the user that apache runs as (apache, www-data, etc.). Instead of modifying /etc/group directly (or chmod-ing the files to 0777), I used usermod:

usermod -a -G vhost-user-group apache-user

Then I had to restart apache for the change to take effect:

apachectl restart

Or

sudo /etc/init.d/httpd restart

Or whatever your system uses to restart apache.

If the site is on shared hosting, maybe you must change the file permissions with an FTP program, or contact the hosting provider?

回复 原文
计㈡愣 2024-09-26 07:59:26

要解决此问题，请将 apc.shm_size 的值设置为整数
找到您的 apc.ini 文件（在我的系统 apc.ini 文件位置 /etc/php5/conf.d/apc.ini 中）并设置：
apc.shm_size = 1000

To resolve this problem set value for apc.shm_size as integer
Locate your apc.ini file (In my system apc.ini file location /etc/php5/conf.d/apc.ini) and set:
apc.shm_size = 1000

回复 原文
莫言歌 2024-09-26 07:59:26

在我的系统上我必须插入
apc.shm_size = 64M
进入/usr/local/etc/php.ini
（FreeBSD 9.1）
然后当我查看 apc.php （我从 /usr/local/share/doc/APC/apc.php 复制到 /usr/local/www/apache24/data ）
我发现缓存大小已从默认的 32M 增加到 64M，并且我不再获得大型缓存完整计数

引用：
https://www.php.net/manual/en/apc.configuration。 php
还阅读了 Bokan 的评论，他们非常有帮助

on my system i had to insert
apc.shm_size = 64M
into /usr/local/etc/php.ini
(FreeBSD 9.1)
then when i looked at apc.php (which i copied from /usr/local/share/doc/APC/apc.php to /usr/local/www/apache24/data)
i found that the cache size had increased from the default of 32M to 64M and i was no longer getting a large cache full count

references:
https://www.php.net/manual/en/apc.configuration.php
also read Bokan's comments, they were very helpful

回复 原文
孤君无依 2024-09-26 07:59:26

监控您的缓存文件大小（您可以使用 apc pecl 包中的 apc.php）并增加
apc.shm_size 根据您的需要。

这解决了问题。

Monitor your Cached Files Size (you can use apc.php from apc pecl package) and increase
apc.shm_size according to your needs.

This solves the problem.

回复 原文
~没有更多了~

关于作者

当梦初醒

暂无简介

0 文章
0 评论
25 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

小瓶盖

文章 0 评论 0

wxsp_Ukbq8xGR

文章 0 评论 0

1638627670

文章 0 评论 0

仅一夜美梦

文章 0 评论 0

夜访吸血鬼

文章 0 评论 0

近卫軍团

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文