php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #59937 apc_cache_info('user') locks up server with very large user cache
Submitted: 2011-09-05 14:38 UTC Modified: 2016-11-18 21:36 UTC
Votes:8
Avg. Score:4.6 ± 0.7
Reproduced:8 of 8 (100.0%)
Same Version:7 (87.5%)
Same OS:6 (75.0%)
From: joe dot lencioni at gmail dot com Assigned:
Status: Wont fix Package: APC (PECL)
PHP Version: 5.3.6 OS: Linux 2.6.32-131.4.1.el6.x86_64
Private report: No CVE-ID: None
View Developer Edit
 [2011-09-05 14:38 UTC] joe dot lencioni at gmail dot com 
Description:
------------
We are using APC with a very large user cache--52503 (482.9 
MBytes) at this moment. When the cache is very large, calling 
apc_cache_info('user') freezes the entire web server. It may 
or may not be related to the fact that we are caching a lot of 
objects in the cache.

This issue was particularly tricky to diagnose, because the 
only thing we could find in our error log was "[error] server 
reached MaxClients setting, consider raising the MaxClients 
setting".

Thankfully, there is now the APCIterator, so updating our code 
was a breeze, but this problem should probably be addressed, 
particularly because the apc.php page calls 
apc_cache_info('user') when clicking on the "User Cache 
Entries" tab.

Reproduce code:
---------------
$cache = apc_cache_info('user');

Actual result:
--------------
Server locks up until it is restarted.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-02-18 23:39 UTC] gopalv@php.net 
This seems like an odd issue - the APC cache uses a readlock for apc_cache_info() 
if can.

Can you post your apc section from "php -i" ? If you've got pthreadlocks, then it 
should be using read locks & won't lock up the entire cache.

I suspect your cache info is running out of php memory building the structures, 
but it would help to find out if it is a locking issue or not.
 [2013-05-28 08:38 UTC] tomasz at ulanowski dot info 
I have almost the same problem. Calling apc_cache_info() freezes Apache, process 
get terminated because of exhausted memory, but Apache does not resume. In an 
error log I find:
Allowed memory size of 134217728 bytes exhausted (tried to allocate 75 bytes)

My php -i:
----------

APC Support => enabled
Version => 3.1.9
APC Debugging => Disabled
MMAP Support => Enabled
MMAP File Mask => /tmp/apcphp5.wyV0av
Locking type => pthread mutex Locks
Serialization Support => php
Revision => $Revision: 308812 $
Build Date => Mar 25 2012 16:30:18

Directive => Local Value => Master Value
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => On => On
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 10M => 10M
apc.mmap_file_mask => /tmp/apcphp5.wyV0av => /tmp/apcphp5.wyV0av
apc.num_files_hint => 1024 => 1024
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 1024M => 1024M
apc.slam_defense => Off => Off
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 7200 => 7200
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 7200 => 7200
apc.write_lock => On => On
 [2016-11-18 21:36 UTC] kalle@php.net
-Status: Open +Status: Wont fix
 [2016-11-18 21:36 UTC] kalle@php.net 
APC is no longer supported in favor of opcache that comes bundled with PHP, if you wish to use the user cache, then look at PECL/APCu.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 30 14:01:28 2024 UTC