Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #15659 > unrolled thread

APC Questions Regarding "Unable to allocate memory for pool."

Back to article view | Back to comp.lang.php

Contents

  APC Questions Regarding "Unable to allocate memory for pool." mojorising00@gmail.com - 2015-09-10 12:45 -0700
    Re: APC Questions Regarding "Unable to allocate memory for pool." Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-10 16:17 -0400
      Re: APC Questions Regarding "Unable to allocate memory for pool." Mike <mojorising00@gmail.com> - 2015-09-10 13:32 -0700
        Re: APC Questions Regarding "Unable to allocate memory for pool." Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-10 20:21 -0400
          Re: APC Questions Regarding "Unable to allocate memory for pool." Mike <mojorising00@gmail.com> - 2015-09-10 23:39 -0700

#15659 — APC Questions Regarding "Unable to allocate memory for pool."

Hello!

On two different environments (one Drupal, one Wordpress) on different server environments, I have been seeing the same PHP warning -- "Unable to allocate memory for pool.".

The message appears intermittently (for an estimated 10 - 20 minutes at a time) and first started popping up less than a week ago. No PHP or APC changes have been made around that time.

I have searched the web fairly extensively and in cases where this message appears, the usual advice has been to verify all the APC parameters. That's good advice and seems to have worked for others. The problem is that everything has been working fine for years in these environments until the last week and a review of the APC settings tells me they look appropriate.

We saw it again this morning and at that time, noticed that memory in the APC cache was just short of the shm_size limit. This made us think we were hitting that limit and the next operation to insert an object into that cache pool failed, triggering the warning message.

So I adjusted apc.shm_size from 512MB to 768MB and the message has yet to appear again, though only a few hours have passed since then.

This brings me to a few questions I have for you:

* In a situation where an application attempts to insert an object into an APC cache and the item to be inserted can not be, due to a constraint set in the APC configuration (e.g. there is no more room for it based on apc.shm_size, object exceeds 'apc.max_file_size', etc), shouldn't operations continue without error? My thinking is that the item can't be cached in such a situation but it can still be processed by PHP.

* Is there any way to see exactly what objects are not being cached due to this condition?

* Is there anything else I might be missing that can be adjusted here. Bringing apc.shm_size up does appear to have resolved the issue, though I feel that shouldn't be absolutely necessary. In a situation where that option is not available, system memory is limited, it seems I should still be able to use APC without this warning appearing.

* Could this problem be a result of a bug in APC or PHP?


Thanks so much for any insught you may be able to provide! My apologies if this has already been addressed somewhere or is not the best place to pose this question.

Here are the APC parameters for reference:

apc.enabled=1
apc.shm_segments=1
apc.shm_size=768M (was 512MB at time of warnings)
apc.num_files_hint=7000
apc.user_entries_hint=4096
apc.ttl=7200
apc.use_request_time=1
apc.user_ttl=7200
apc.gc_ttl=3600
apc.cache_by_default=1
apc.filters
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.file_update_protection=2
apc.enable_cli=0
apc.max_file_size=4M
apc.stat=1
apc.stat_ctime=0
apc.canonicalize=0
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0


Best,
Mike

[toc] | [next] | [standalone]

#15660

On 9/10/2015 3:45 PM, mojorising00@gmail.com wrote:
> Hello!
> 
> On two different environments (one Drupal, one Wordpress) on different server environments, I have been seeing the same PHP warning -- "Unable to allocate memory for pool.".
> 
> The message appears intermittently (for an estimated 10 - 20 minutes at a time) and first started popping up less than a week ago. No PHP or APC changes have been made around that time.
> 
> I have searched the web fairly extensively and in cases where this message appears, the usual advice has been to verify all the APC parameters. That's good advice and seems to have worked for others. The problem is that everything has been working fine for years in these environments until the last week and a review of the APC settings tells me they look appropriate.
> 
> We saw it again this morning and at that time, noticed that memory in the APC cache was just short of the shm_size limit. This made us think we were hitting that limit and the next operation to insert an object into that cache pool failed, triggering the warning message.
> 
> So I adjusted apc.shm_size from 512MB to 768MB and the message has yet to appear again, though only a few hours have passed since then.
> 
> This brings me to a few questions I have for you:
> 
> * In a situation where an application attempts to insert an object into an APC cache and the item to be inserted can not be, due to a constraint set in the APC configuration (e.g. there is no more room for it based on apc.shm_size, object exceeds 'apc.max_file_size', etc), shouldn't operations continue without error? My thinking is that the item can't be cached in such a situation but it can still be processed by PHP.
> 
> * Is there any way to see exactly what objects are not being cached due to this condition?
> 
> * Is there anything else I might be missing that can be adjusted here. Bringing apc.shm_size up does appear to have resolved the issue, though I feel that shouldn't be absolutely necessary. In a situation where that option is not available, system memory is limited, it seems I should still be able to use APC without this warning appearing.
> 
> * Could this problem be a result of a bug in APC or PHP?
> 
> 
> Thanks so much for any insught you may be able to provide! My apologies if this has already been addressed somewhere or is not the best place to pose this question.
> 
> Here are the APC parameters for reference:
> 
> apc.enabled=1
> apc.shm_segments=1
> apc.shm_size=768M (was 512MB at time of warnings)
> apc.num_files_hint=7000
> apc.user_entries_hint=4096
> apc.ttl=7200
> apc.use_request_time=1
> apc.user_ttl=7200
> apc.gc_ttl=3600
> apc.cache_by_default=1
> apc.filters
> apc.mmap_file_mask=/tmp/apc.XXXXXX
> apc.file_update_protection=2
> apc.enable_cli=0
> apc.max_file_size=4M
> apc.stat=1
> apc.stat_ctime=0
> apc.canonicalize=0
> apc.write_lock=1
> apc.report_autofilter=0
> apc.rfc1867=0
> 
> 
> Best,
> Mike
> 

It's not an error - it's a warning.  A big difference.  An error
terminates processing; a warning does not.  PHP is continuing to run,
however at a reduced efficiency due to the inability to cache the object.

I don't know of a way to tell what objects are not cached, but then I
haven't looked into it.  However, IMHO the warning is valid, and I think
it should be issued because it is affecting the processing on your web site.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15661

On Thursday, September 10, 2015 at 1:17:54 PM UTC-7, Jerry Stuckle wrote:
> On 9/10/2015 3:45 PM, Mike wrote:
> > Hello!
> > 
> > On two different environments (one Drupal, one Wordpress) on different server environments, I have been seeing the same PHP warning -- "Unable to allocate memory for pool.".
> > 
> > The message appears intermittently (for an estimated 10 - 20 minutes at a time) and first started popping up less than a week ago. No PHP or APC changes have been made around that time.
> > 
> > I have searched the web fairly extensively and in cases where this message appears, the usual advice has been to verify all the APC parameters. That's good advice and seems to have worked for others. The problem is that everything has been working fine for years in these environments until the last week and a review of the APC settings tells me they look appropriate.
> > 
> > We saw it again this morning and at that time, noticed that memory in the APC cache was just short of the shm_size limit. This made us think we were hitting that limit and the next operation to insert an object into that cache pool failed, triggering the warning message.
> > 
> > So I adjusted apc.shm_size from 512MB to 768MB and the message has yet to appear again, though only a few hours have passed since then.
> > 
> > This brings me to a few questions I have for you:
> > 
> > * In a situation where an application attempts to insert an object into an APC cache and the item to be inserted can not be, due to a constraint set in the APC configuration (e.g. there is no more room for it based on apc.shm_size, object exceeds 'apc.max_file_size', etc), shouldn't operations continue without error? My thinking is that the item can't be cached in such a situation but it can still be processed by PHP.
> > 
> > * Is there any way to see exactly what objects are not being cached due to this condition?
> > 
> > * Is there anything else I might be missing that can be adjusted here. Bringing apc.shm_size up does appear to have resolved the issue, though I feel that shouldn't be absolutely necessary. In a situation where that option is not available, system memory is limited, it seems I should still be able to use APC without this warning appearing.
> > 
> > * Could this problem be a result of a bug in APC or PHP?
> > 
> > 
> > Thanks so much for any insught you may be able to provide! My apologies if this has already been addressed somewhere or is not the best place to pose this question.
> > 
> > Here are the APC parameters for reference:
> > 
> > apc.enabled=1
> > apc.shm_segments=1
> > apc.shm_size=768M (was 512MB at time of warnings)
> > apc.num_files_hint=7000
> > apc.user_entries_hint=4096
> > apc.ttl=7200
> > apc.use_request_time=1
> > apc.user_ttl=7200
> > apc.gc_ttl=3600
> > apc.cache_by_default=1
> > apc.filters
> > apc.mmap_file_mask=/tmp/apc.XXXXXX
> > apc.file_update_protection=2
> > apc.enable_cli=0
> > apc.max_file_size=4M
> > apc.stat=1
> > apc.stat_ctime=0
> > apc.canonicalize=0
> > apc.write_lock=1
> > apc.report_autofilter=0
> > apc.rfc1867=0
> > 
> > 
> > Best,
> > Mike
> > 
> 
> It's not an error - it's a warning.  A big difference.  An error
> terminates processing; a warning does not.  PHP is continuing to run,
> however at a reduced efficiency due to the inability to cache the object.
> 
> I don't know of a way to tell what objects are not cached, but then I
> haven't looked into it.  However, IMHO the warning is valid, and I think
> it should be issued because it is affecting the processing on your web site.
> 
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle

Thanks, Jerry! That's very helpful.

Right. It is a warning. I agree and after thinking about it a bit more was actually just about to suggest the same -- this is something we should know. So I suppose it's no issue and definitely not a bug.

It must just be a weird coincidence that this problem suddenly started at the same time with two very different set-ups. 

The problem is that in both cases, the warning message was actually appearing on these web sites. So it looks broken and, of course, we get e-mails like "site down" from people, even though it's not down. On the Wordpress site, the developer adjusted things so those errors are not presented to web users. I'll ask the Drupal developer to do the same on their stuff.

In the end, the solution then is to make sure PHP warnings are not presented to end users, and to increase apc-shm_size, if memory is available for that. No problem there. 

If anyone else out there can point me to some way to see exactly what objects are failing to be inserted into APC cache pools, that would be appreciated. 

Best,
Mike

[toc] | [prev] | [next] | [standalone]

#15662

On 9/10/2015 4:32 PM, Mike wrote:
> On Thursday, September 10, 2015 at 1:17:54 PM UTC-7, Jerry Stuckle wrote:
>> On 9/10/2015 3:45 PM, Mike wrote:
>>> Hello!
>>>
>>> On two different environments (one Drupal, one Wordpress) on different server environments, I have been seeing the same PHP warning -- "Unable to allocate memory for pool.".
>>>
>>> The message appears intermittently (for an estimated 10 - 20 minutes at a time) and first started popping up less than a week ago. No PHP or APC changes have been made around that time.
>>>
>>> I have searched the web fairly extensively and in cases where this message appears, the usual advice has been to verify all the APC parameters. That's good advice and seems to have worked for others. The problem is that everything has been working fine for years in these environments until the last week and a review of the APC settings tells me they look appropriate.
>>>
>>> We saw it again this morning and at that time, noticed that memory in the APC cache was just short of the shm_size limit. This made us think we were hitting that limit and the next operation to insert an object into that cache pool failed, triggering the warning message.
>>>
>>> So I adjusted apc.shm_size from 512MB to 768MB and the message has yet to appear again, though only a few hours have passed since then.
>>>
>>> This brings me to a few questions I have for you:
>>>
>>> * In a situation where an application attempts to insert an object into an APC cache and the item to be inserted can not be, due to a constraint set in the APC configuration (e.g. there is no more room for it based on apc.shm_size, object exceeds 'apc.max_file_size', etc), shouldn't operations continue without error? My thinking is that the item can't be cached in such a situation but it can still be processed by PHP.
>>>
>>> * Is there any way to see exactly what objects are not being cached due to this condition?
>>>
>>> * Is there anything else I might be missing that can be adjusted here. Bringing apc.shm_size up does appear to have resolved the issue, though I feel that shouldn't be absolutely necessary. In a situation where that option is not available, system memory is limited, it seems I should still be able to use APC without this warning appearing.
>>>
>>> * Could this problem be a result of a bug in APC or PHP?
>>>
>>>
>>> Thanks so much for any insught you may be able to provide! My apologies if this has already been addressed somewhere or is not the best place to pose this question.
>>>
>>> Here are the APC parameters for reference:
>>>
>>> apc.enabled=1
>>> apc.shm_segments=1
>>> apc.shm_size=768M (was 512MB at time of warnings)
>>> apc.num_files_hint=7000
>>> apc.user_entries_hint=4096
>>> apc.ttl=7200
>>> apc.use_request_time=1
>>> apc.user_ttl=7200
>>> apc.gc_ttl=3600
>>> apc.cache_by_default=1
>>> apc.filters
>>> apc.mmap_file_mask=/tmp/apc.XXXXXX
>>> apc.file_update_protection=2
>>> apc.enable_cli=0
>>> apc.max_file_size=4M
>>> apc.stat=1
>>> apc.stat_ctime=0
>>> apc.canonicalize=0
>>> apc.write_lock=1
>>> apc.report_autofilter=0
>>> apc.rfc1867=0
>>>
>>>
>>> Best,
>>> Mike
>>>
>>
>> It's not an error - it's a warning.  A big difference.  An error
>> terminates processing; a warning does not.  PHP is continuing to run,
>> however at a reduced efficiency due to the inability to cache the object.
>>
>> I don't know of a way to tell what objects are not cached, but then I
>> haven't looked into it.  However, IMHO the warning is valid, and I think
>> it should be issued because it is affecting the processing on your web site.
>>
>>
>> -- 
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
> 
> Thanks, Jerry! That's very helpful.
> 
> Right. It is a warning. I agree and after thinking about it a bit more was actually just about to suggest the same -- this is something we should know. So I suppose it's no issue and definitely not a bug.
> 
> It must just be a weird coincidence that this problem suddenly started at the same time with two very different set-ups. 
> 
> The problem is that in both cases, the warning message was actually appearing on these web sites. So it looks broken and, of course, we get e-mails like "site down" from people, even though it's not down. On the Wordpress site, the developer adjusted things so those errors are not presented to web users. I'll ask the Drupal developer to do the same on their stuff.
> 
> In the end, the solution then is to make sure PHP warnings are not presented to end users, and to increase apc-shm_size, if memory is available for that. No problem there. 
> 
> If anyone else out there can point me to some way to see exactly what objects are failing to be inserted into APC cache pools, that would be appreciated. 
> 
> Best,
> Mike
> 

If you check the recommendations, your php.ini file on a production
system should always have

display_errors = off

This will prevent any errors from being displayed on your website.  It's
also a security concern, as some error messages could provide
information on your website's internals.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15665

On Thursday, September 10, 2015 at 5:21:52 PM UTC-7, Jerry Stuckle wrote:
> On 9/10/2015 4:32 PM, Mike wrote:
> > On Thursday, September 10, 2015 at 1:17:54 PM UTC-7, Jerry Stuckle wrote:
> >> On 9/10/2015 3:45 PM, Mike wrote:
> >>> Hello!
> >>>
> >>> On two different environments (one Drupal, one Wordpress) on different server environments, I have been seeing the same PHP warning -- "Unable to allocate memory for pool.".
> >>>
> >>> The message appears intermittently (for an estimated 10 - 20 minutes at a time) and first started popping up less than a week ago. No PHP or APC changes have been made around that time.
> >>>
> >>> I have searched the web fairly extensively and in cases where this message appears, the usual advice has been to verify all the APC parameters. That's good advice and seems to have worked for others. The problem is that everything has been working fine for years in these environments until the last week and a review of the APC settings tells me they look appropriate.
> >>>
> >>> We saw it again this morning and at that time, noticed that memory in the APC cache was just short of the shm_size limit. This made us think we were hitting that limit and the next operation to insert an object into that cache pool failed, triggering the warning message.
> >>>
> >>> So I adjusted apc.shm_size from 512MB to 768MB and the message has yet to appear again, though only a few hours have passed since then.
> >>>
> >>> This brings me to a few questions I have for you:
> >>>
> >>> * In a situation where an application attempts to insert an object into an APC cache and the item to be inserted can not be, due to a constraint set in the APC configuration (e.g. there is no more room for it based on apc.shm_size, object exceeds 'apc.max_file_size', etc), shouldn't operations continue without error? My thinking is that the item can't be cached in such a situation but it can still be processed by PHP.
> >>>
> >>> * Is there any way to see exactly what objects are not being cached due to this condition?
> >>>
> >>> * Is there anything else I might be missing that can be adjusted here. Bringing apc.shm_size up does appear to have resolved the issue, though I feel that shouldn't be absolutely necessary. In a situation where that option is not available, system memory is limited, it seems I should still be able to use APC without this warning appearing.
> >>>
> >>> * Could this problem be a result of a bug in APC or PHP?
> >>>
> >>>
> >>> Thanks so much for any insught you may be able to provide! My apologies if this has already been addressed somewhere or is not the best place to pose this question.
> >>>
> >>> Here are the APC parameters for reference:
> >>>
> >>> apc.enabled=1
> >>> apc.shm_segments=1
> >>> apc.shm_size=768M (was 512MB at time of warnings)
> >>> apc.num_files_hint=7000
> >>> apc.user_entries_hint=4096
> >>> apc.ttl=7200
> >>> apc.use_request_time=1
> >>> apc.user_ttl=7200
> >>> apc.gc_ttl=3600
> >>> apc.cache_by_default=1
> >>> apc.filters
> >>> apc.mmap_file_mask=/tmp/apc.XXXXXX
> >>> apc.file_update_protection=2
> >>> apc.enable_cli=0
> >>> apc.max_file_size=4M
> >>> apc.stat=1
> >>> apc.stat_ctime=0
> >>> apc.canonicalize=0
> >>> apc.write_lock=1
> >>> apc.report_autofilter=0
> >>> apc.rfc1867=0
> >>>
> >>>
> >>> Best,
> >>> Mike
> >>>
> >>
> >> It's not an error - it's a warning.  A big difference.  An error
> >> terminates processing; a warning does not.  PHP is continuing to run,
> >> however at a reduced efficiency due to the inability to cache the object.
> >>
> >> I don't know of a way to tell what objects are not cached, but then I
> >> haven't looked into it.  However, IMHO the warning is valid, and I think
> >> it should be issued because it is affecting the processing on your web site.
> >>
> >>
> >> -- 
> >> ==================
> >> Remove the "x" from my email address
> >> Jerry Stuckle
> > 
> > Thanks, Jerry! That's very helpful.
> > 
> > Right. It is a warning. I agree and after thinking about it a bit more was actually just about to suggest the same -- this is something we should know. So I suppose it's no issue and definitely not a bug.
> > 
> > It must just be a weird coincidence that this problem suddenly started at the same time with two very different set-ups. 
> > 
> > The problem is that in both cases, the warning message was actually appearing on these web sites. So it looks broken and, of course, we get e-mails like "site down" from people, even though it's not down. On the Wordpress site, the developer adjusted things so those errors are not presented to web users. I'll ask the Drupal developer to do the same on their stuff.
> > 
> > In the end, the solution then is to make sure PHP warnings are not presented to end users, and to increase apc-shm_size, if memory is available for that. No problem there. 
> > 
> > If anyone else out there can point me to some way to see exactly what objects are failing to be inserted into APC cache pools, that would be appreciated. 
> > 
> > Best,
> > Mike
> > 
> 
> If you check the recommendations, your php.ini file on a production
> system should always have
> 
> display_errors = off
> 
> This will prevent any errors from being displayed on your website.  It's
> also a security concern, as some error messages could provide
> information on your website's internals.
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> ==================

Very good point. I thought we had that disabled in both environments. 

It actually was set to 'On' on one of them but set to 'Off' on the other, and has since been corrected. Errors were showing in web browsers in both environments regardless. I don't have full access to the system that had display_errors off, so it's entirely possible that parameter is being overridden somewhere and I just haven't seen it.

The environment that I do have full access to has not had any issues at all since I increased apc.shm_size to 768, which is awesome. I've been keeping my eye on the memory and cache utilization of APC since then and it does go all the way up to about 600 MB at times. So by making this change, we likely got rid of warning messages *and* boosted performance! Hooray!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web