krakjoe / apcu Goto Github PK
View Code? Open in Web Editor NEWAPCu - APC User Cache
License: Other
APCu - APC User Cache
License: Other
see the gist for further information:
https://gist.github.com/peterwang/7588979
Two instances of the same object (i.e. $obj1 === $obj2
) if stored and then fetched from cache should be the same instance again.
class A {}
$obj1 = new A();
$obj2 = $obj1;
var_dump($obj1 === $obj2); // true
apcu_store('obj1', $obj1);
apcu_store('obj2', $obj2);
var_dump(apcu_fetch('obj1') === apcu_fetch('obj2')); // false, but should be true
Semi-real use case:
class User {}
class Post {
public $createdBy;
public $editedBy;
}
$user = new User();
$post = new Post();
$post->createdBy = $user;
$post->editedBy = $user;
// persist $post to DB
// ...
// hydrate $post from DB and cache it
apcu_store('post', $post);
// ...
// fetch $post from cache
$post = apcu_fetch('post');
// now $post->createdBy and $post->editedBy are two different instances of class User, but they should be the same instance as the original
Testcase:
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 756
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 757
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 758
Warning: Division by zero in /home/cj/public_html/apcu-simplify/apc.php on line 759
The following commit removed compatability with APC:
4762c0d#L0L303
Example of code that ran under APC and will not work with APCu.
$apcIterator = new APCIterator(
'user',
('/^'.preg_quote($cachePrefix, '/').'/'),
APC_ITER_KEY
);
Worryingly, it didn't raise a significant error and was only found after investigating strange behaviour in our application. At the very least this should cause some kind of error - but the behaviour I would like to see is it accepting the first parameter and asserting it to be "user".
http://www.php.net/manual/en/apciterator.construct.php
This is a similar issue to the one raised here:
#18 apc_clear_cache does not accept $cache_type parameter
Building APCu v4.0.1 and running the tests on Darwin 12 shows that most of the tests are failing. The bracktrace from running tests/apc_001.php
:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001038531f5 in make_slot [inlined] () at /Users/kabel/Documents/Installers/apcu/apc_cache.c:109
109 p->key = key[0];
(gdb) bt
#0 0x00000001038531f5 in make_slot [inlined] () at /Users/kabel/Documents/Installers/apcu/apc_cache.c:109
#1 0x00000001038531f5 in apc_cache_insert (cache=0x103abe730, key={str = 0x103b09338 "9eb_DB_PDO_MYSQL_DDL_catalog_product_entity_1", len = 46, h = 7252266301910437370, mtime = 1369433004, owner = 0}, value=0x103b08330, ctxt=0x7fff5fbfe8f0, t=1369433004, exclusive=0 '\0') at apc_cache.c:888
#2 0x0000000103852d4b in apc_cache_store (cache=0x103abe730, strkey=<value temporarily unavailable, due to optimizations>, keylen=<value temporarily unavailable, due to optimizations>, val=0x102bed5a8, ttl=2400, exclusive=0 '\0') at apc_cache.c:443
#3 0x00000001038506ca in apc_store_helper () at php_apc.c:568
#4 0x000000010041dde2 in zend_do_fcall_common_helper_SPEC (execute_data=0x102bb8050) at zend_vm_execute.h:643
#5 0x00000001003d8f98 in execute (op_array=<value temporarily unavailable, due to optimizations>) at zend_vm_execute.h:410
#6 0x00000001003b57c3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:1315
#7 0x000000010035e262 in php_execute_script (primary_file=0x7fff5fbff4b8) at main.c:2492
#8 0x000000010043d7d2 in do_cli (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at php_cli.c:988
#9 0x000000010043c67a in main (argc=3, argv=0x7fff5fbffb90) at php_cli.c:1364
The tests all passed on v4.0.0
I'm actually not sure if this is an issue for the apcu project or somewhere else.
I got the the error:
APCIterator::__construct() expects at most 4 parameters, 5 given
When passing, as usual with the old APC user cache, the 5 params defined here: http://php.net/manual/en/apciterator.construct.php
ARG_ENABLE('apc-bc', 'Wether APCu should provide APC full compatibility support', 'yes')
should be
ARG_ENABLE('apc-bc', 'Wether APCu should provide APC full compatibility support', 'yes');
4.0.3
and this output
[0] => Array
(
[key] => WCF_409f75bc6a_wbb_BoardModeratorPermission-fb64df1fae01656a495d95af9e4181e5f100104f
[ttl] => 259200
[nhits] => 0
[mtime] => 1390835810
[ctime] => 1390835810
[dtime] => 0
[atime] => 1390835810
[ref_count] => 0
[mem_size] => 584
)
its not compatible with the old apc api
I don't understand why APCu's GC is whining, does the PHP dev can fix it ? If not, why displaying the message ?
apc_cache.c:210 :
/* good ol' whining */
if (dead->value->ref_count > 0) {
apc_warning(
"GC cache entry '%s' was on gc-list for %d seconds" TSRMLS_CC,
dead->key.str, gc_sec
);
}
Serialization Support => php, eval
igbinary not found ..
https://github.com/phadej/igbinary/blob/master/apc_serializer.h
We are getting segfaults with APCU 4.0.2 on PHP 5.5 on Apache HTTPD 2.2.3. They appear to relate to calls to apc_cache_find failing to find contents of memory at a location that has seemingly not been allocated.
This is a serious bug that makes the host unusable until after HTTPD is restarted
We are experiencing this error in production code but we do not have a test script at this time. The general scenario is that we start up HTTPD and the code runs fine on a host for several hours, with no segfaults. After a few hours, a request segfaults and after that point, all requests segfault until HTTPD is restarted. It appears to happen under times of relatively higher (but still absolutely low) levels of load - host averages are 0.2-1.0, CPU is 90+% idle, low number of requests overall.
while comparing perfomance with eaccelerator got such results:
index.php:
<?php
const WAIT_STEP = 3;
const DURATION = 10;
apcu_store('test', 1);
$start_time = apcu_fetch('start');
if ($start_time <= microtime(true)) {
apcu_delete('start');
apcu_delete('end');
$start_time = null;
}
if (!$start_time) {
$start_time = microtime(true) + WAIT_STEP;
$end_time = microtime(true) + WAIT_STEP + DURATION;
apcu_store('start', $start_time);
apcu_store('end', $end_time);
}
sleep(1);
$start_time = apcu_fetch('start');
$end_time = apcu_fetch('end');
usleep(($start_time - microtime(true)) * 1000000);
$count = 0;
while (microtime(true) < $end_time) {
for ($i = 0; $i < 100; $i++) {
//$x = apcu_delete('test');
$x = apcu_store('test', 1);
$x = apcu_fetch('test');
$x = apcu_delete('test');
}
$count++;
}
echo $count. "\n";die;
bash command:
while true; do (echo "" > out; for i in {1..6}; do curl -s http://localhost/ & >> out; done) | awk '{s+=$1} END {print s}' >> input && tail -n 1 input && sleep 2; done
3256
1873
1562
1319
1130
1081
990
871
740
564
657
562
625
537
498
527
553
559
531
422
452
440
462
424
430
442
441
413
421
420
414
398
404
392
385
377
378
334
295
311
347
331
311
329
320
327
299
251
256
269
266
243
239
247
272
273
272
Here an example of zf2 code
https://github.com/zendframework/zf2/blob/master/library/Zend/Cache/Storage/Adapter/Apc.php#L331
$format = APC_ITER_ALL ^ APC_ITER_VALUE ^ APC_ITER_TYPE ^ APC_ITER_REFCOUNT;
$regexp = '/^' . preg_quote($internalKey, '/') . '$/';
$it = new ApcIterator('user', $regexp, $format, 100, APC_LIST_ACTIVE);
$metadata = $it->current();
With apc extension metadata variable has this array
array (
'key' => '777297316:843726ae1898521dafdfde945d71b59d',
'num_hits' => 17,
'mtime' => 1384856788,
'creation_time' => 1384856788,
'deletion_time' => 0,
'access_time' => 1384857278,
'mem_size' => 9816,
'ttl' => 0,
)
Array keys differ with apcu.
array (
'key' => '777297316:843726ae1898521dafdfde945d71b59d',
'nhits' => 4,
'mtime' => 1384856539,
'ctime' => 1384856539,
'dtime' => 0,
'atime' => 1384857619,
'mem_size' => 9816,
'ttl' => 0,
)
hi,
replace apc_ by apcu_
see :
// clear cache
if ($AUTHENTICATED && isset($MYREQUEST['CC']) && $MYREQUEST['CC']) {
apcu_clear_cache();
}
if ($AUTHENTICATED && !empty($MYREQUEST['DU'])) {
apcu_delete($MYREQUEST['DU']);
}
if(!function_exists('apcu_cache_info')) {
echo "No cache info available. APC does not appear to be running.";
exit;
}
$cache = apcu_cache_info();
$mem=apcu_sma_info();
Hi!
Try this:
error_reporting(E_ALL);
ini_set('display_errors' ,1);
$dumpFilePath = "/path/to/apc.dump";
apcu_store("test", array(
"t1" => array(
"t11" => 11,
"t12" => 12,
"t13" => 13
),
"t2" => array(
"t21" => 21,
"t22" => 22,
"t23" => 23
),
"t3" => array(
"t31" => 31,
"t32" => 32,
"t33" => 33
)
), 1000000);
$res = apcu_bin_dumpfile(null, $dumpFilePath);
echo $res;
$res = apcu_bin_loadfile($dumpFilePath);
echo $res;
My server returns 502 Bad Gateway. Message in log file: "kernel: pid 26326 (php-fpm), uid 80: exited on signal 11"
I use nginx, php 5.5.5
Thanks!
/usr/libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/ld: ext/apcu/.libs/apc_lock.o: undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'
/usr/libexec/gcc/x86_64-redhat-linux-gnu/4.8.1/ld: note: 'pthread_rwlock_wrlock@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line
Notes: The 'glibc' library in Fedora 20 is Version 2.18.11
While preparing the migration from PHP 5.4 to PHP 5.5, I tried to switch from pecl-APC to pec-APCu.
Under high load, my httpd starts to dump core while using APCu which is not the case when using APC.
I'm using the 4.0.1 release of apcu.
My Test Script: http://pastebin.com/ZMgR0LGg
How to reproduce:
ab -H "Connection:close" -c 20 -n 500 http://www/test_apc.php
with pecl-APC no errors occur at all, with pecl-APCu, httpd processed will start to dump core.
[Tue Aug 13 14:46:15 2013] [notice] Apache/2.2.25 (FreeBSD) mod_scgi/1.12 PHP/5.4.17 mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 configured -- resuming normal operations
[Tue Aug 13 14:46:36 2013] [notice] child pid 90307 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90438 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90311 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90310 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90309 exit signal Bus error (10)
[Tue Aug 13 14:46:37 2013] [notice] child pid 90308 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90440 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90439 exit signal Bus error (10)
[Tue Aug 13 14:46:38 2013] [notice] child pid 90441 exit signal Bus error (10)
[Tue Aug 13 14:46:39 2013] [notice] child pid 90448 exit signal Bus error (10)
Verified with APCu 4.0.1 on:
I was not able to reproduce this in a out-of-the-box Ubuntu 11 with Apache 2.2.22 and PHP 5.3.10 with Suhosin Patch (default Ubuntu packages). The answer time just went dramatically low and the whole ab ended with
apr_poll: The timeout specified has expired (70007)
Total of 70 requests completed
But this might be a problem of my Ubuntu setup - maybe some DDoS protection... who knows.
Hi
We've have stumbled across a performance issue using Doctrine and APCu. I have no idea if the problem actually is with Doctrine, APCu, or something else, but I'm opening this ticket because maybe it will ring a bell to you.
I've also opened a ticket on the Doctrine side, it contains a lot more information: http://www.doctrine-project.org/jira/browse/DDC-2832
The thing is we tried using Memcached and everything worked perfectly (no performance issue).
Doctrine ticket:
We have New Relic, so we have a bit of profiling, and here is what it shows:
... skipping to interesting bit 88s Doctrine\ORM\PersistentCollection::matching 88s Doctrine\ORM\Persisters\BasicEntityPersister::loadCriteria 43ms Orga_Cell - SELECT (MySQL query) 88s Doctrine\ORM\Internal\Hydration\AbstractHydrator::hydrateAll 88s Doctrine\...\SimpleObjectHydrator::hydrateAllData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 47ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 59ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 52ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 50ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 51ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 45ms Doctrine\...\SimpleObjectHydrator::hydrateRowData 58ms Doctrine\...\SimpleObjectHydrator::hydrateRowData
(the stack trace is the one provided by New Relic, maybe their tool shows an incomplete stack trace? However judging by the content of the method and the numbers of rows, it seems correct)
As you can see, the numbers don't add up at all! A dozen of sub-calls takin 50ms each doesn't add up to a 80 seconds method call.
Keep in mind that when I disable the MetadataCache, then 80s turns into ~300ms and everything works as expected. That's a lot of difference.
So this is very weird.
Few more information:
- the operation runs in a worker, not a HTTP request
- we see the same behavior in every other operation, not just this one
- the PHP process uses 100% CPU of one core
- the RAM is not full (~ 50% used)
- APCu is not full
- APCu is at last version
If I make Doctrine use Memcached, then everything works great.
Latest .git of 'apcu' shows this report in phpinfo() @ php 5.5.4
apcu
APCu Support disabled
Version 4.0.2
APCu Debugging Disabled
MMAP Support Disabled
Serialization Support broken
Revision
Build Date Oct 16 2013 11:39:07
Directive Local Value Master Value
apc.coredump_unmap Off Off
apc.enable_cli Off Off
apc.enabled Off Off
apc.entries_hint 4096 4096
apc.gc_ttl 3600 3600
apc.preload_path no value no value
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 igbinary igbinary
apc.shm_segments 1 1
apc.shm_size 1024M 1024M
apc.slam_defense Off Off
apc.smart 0 0
apc.ttl 28800 28800
apc.use_request_time On On
The only part of the report that concerns me is this "Serialization Support broken"
In every installed PHP applications I have, the function apc_cache_info is called with 'user' as mentionned in the doc of APC. Applications expect to find the cache_list key in the returned array. It seems that this array doesn't contains this key. However, calling apc_cache_info without parameter returns the expected array.
Is it deliberated? Shouldn't APCu be compatible with APC?
While storing an item, we get a "GC cache entry 'key' was on gc-list for 3746 seconds. warning." for an different key.
Why is this warning generated? Is this is special case? Corrupted cache state? Can it be converted to a apc_debug call?
We convert all PHP warnings/errors to exceptions with a custom error_handler(), so this seemingly innocent warning generates an exception.
We seem to be getting hung apaches w/PHP 5.5.0 RC3 w/APCu.
0x00007f1a9572853d in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0 0x00007f1a9572853d in pthread_rwlock_wrlock () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f1a90debd49 in apc_lock_wlock (lock=) at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_lock.c:129
#2 0x00007f1a90df05b9 in apc_cache_insert (cache=0x7f1a970d2960, key=..., value=0x7f1a83591880, ctxt=0x7fff1c983920, t=1371246459, exclusive=0 '\000') at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_cache.c:837
#3 0x00007f1a90df0b85 in apc_cache_store (cache=0x7f1a970d2960, strkey=0x7f1a9778ccc0 "AutoLoad::prefix::6::xxxxxxxxxxxxxxxxxxx::xxxxxxxxxxxxxxxxxx", keylen=52, val=0x7f1a977b5238, ttl=600, exclusive=0 '\000')
at /home/phpbuild/buildphp-5.5.0RC3/apcu/apc_cache.c:443
#4 0x00007f1a90dedb5b in apc_store_helper (ht=, return_value=0x7f1a977b5208, exclusive=0 '\000', return_value_ptr=, this_ptr=, return_value_used=)
at /home/phpbuild/buildphp-5.5.0RC3/apcu/php_apc.c:568
#5 0x00007f1a93f80de6 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f1a96df65b8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:543
#6 0x00007f1a93f450d8 in execute_ex (execute_data=0x7f1a96df65b8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:356
#7 0x00007f1a93ec8b70 in zend_call_function (fci=0x7fff1c983cb0, fci_cache=) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:939
#8 0x00007f1a93eee3d7 in zend_call_method (object_pp=0x0, obj_ce=, fn_proxy=0x7f1a977137e0, function_name=0x7f1a977136a8 "autoload::loadone", function_name_len=,
retval_ptr_ptr=0x7fff1c983de0, param_count=1, arg1=0x7f1a97772900, arg2=0x0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_interfaces.c:97
#9 0x00007f1a93dd8507 in zif_spl_autoload_call (ht=, return_value=, return_value_ptr=, this_ptr=, return_value_used=)
at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/ext/spl/php_spl.c:436
#10 0x00007f1a93ec8b14 in zend_call_function (fci=0x7fff1c983fc0, fci_cache=0x7fff1c984010) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:957
#11 0x00007f1a93ec93fb in zend_lookup_class_ex (name=0x7f1a96f7d988 "xxxxxxxxx", name_length=9, key=0x7f1a977b52b0, use_autoload=1, ce=0x7fff1c9840d8)
at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:1107
#12 0x00007f1a93ec9b22 in zend_fetch_class_by_name (class_name=0x7f1a96f7d988 "xxxxxxxxx", class_name_len=, key=, fetch_type=4)
at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_execute_API.c:1587
#13 0x00007f1a93f12c1a in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER (execute_data=0x7f1a96df4ed8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:1188
#14 0x00007f1a93f450d8 in execute_ex (execute_data=0x7f1a96df4ed8) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend_vm_execute.h:356
#15 0x00007f1a93ed83b3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/Zend/zend.c:1316
#16 0x00007f1a93e7661c in php_execute_script (primary_file=0x7fff1c9865b0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/main/main.c:2481
#17 0x00007f1a93f8408d in php_handler (r=0x7f1a960f70a0) at /home/phpbuild/buildphp-5.5.0RC3/php-src-php-5.5.0RC3/sapi/apache2handler/sapi_apache2.c:667
#18 0x00007f1a96239508 in ap_run_handler ()
#19 0x00007f1a9623997e in ap_invoke_handler ()
#20 0x00007f1a96249570 in ap_process_request ()
#21 0x00007f1a96246398 in ?? ()
#22 0x00007f1a9623ffa8 in ap_run_process_connection ()
#23 0x00007f1a9624e1d0 in ?? ()
#24 0x00007f1a9624e93a in ?? ()
#25 0x00007f1a9624f4e7 in ap_mpm_run ()
#26 0x00007f1a962244a4 in main ()
How to detect if APCu is enabled? I have a factory method which takes care of providing the best cache instance available. Weather I run it from Apache or CLI, I need to detect if ACPu is enabled. With the former APC I could check it with function_exists('apc_fetch')
or class_exists('APCIterator')
but now they return true
even if apc.enabled
and/or apc.enable_cli
are set to false
.
What happens depending on if you answer yes/no.
Notice: Undefined variable: cache_mode in /home/cj/public_html/apcu-simplify/apc.php on line 732
Notice: Undefined index: locking_type in /home/cj/public_html/apcu-simplify/apc.php on line 779
I just updated to version 4.0.1 and it seems like all functions are renamed to apcu__() instead of apc__(). I thought this should be a drop in replacement? Am I doing something wrong?
The output of the apc_cache_info() function differs slightly from that of the original function. We are using the cache_list subarray to gather information about the cache behavior, which is currently broken.
APCu:
php > $t = apc_cache_info('user');
php > print_r($t);
Array
(
[cache_list] => Array
(
[0] => Array
(
[key] => abc
[ttl] => 0
[nhits] => 0
[mtime] => 1382608917
[ctime] => 1382608917
[dtime] => 0
[atime] => 1382608917
[ref_count] => 0
[mem_size] => 656
)
)
)
APC:
php > $t_apc = apc_cache_info('user');
php > print_r($t_apc);
Array
(
[cache_list] => Array
(
[0] => Array
(
[info] => abc
[ttl] => 0
[type] => user
[num_hits] => 0
[mtime] => 1382608983
[creation_time] => 1382608983
[deletion_time] => 0
[access_time] => 1382608983
[ref_count] => 0
[mem_size] => 656
)
)
)
Fixing #11 removed the configure errors I got in Windows. But now compiling does not work. Error message:
ext\apcu\apc_sma.c(657) : warning C4113: 'zend_ulong (__cdecl *)()' differs in parameter lists from 'apc_sma_get_avail_mem_f'
ext\apcu\apc_sma.c(657) : warning C4113: 'void (__cdecl *)()' differs in parameter lists from 'apc_sma_check_integrity_f'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0
VC\BIN\cl.exe"' : return code '0x2'
Stop.
I got the same error message while building PHP 5.3.23, PHP 5.4.13 and PHP 5.5.0 beta 1. It was a snapshot build:
snapshot: forcing apcu on
snapshot: forcing apcu-debug on
snapshot: forcing --disable-apc-bc shared
Am I missing something? Should I configure otherwise?
In the following example:
<?php
$key="testkey";
$i=PHP_INT_MAX;
apc_store($key, $i);
var_dump($j=apc_fetch($key));
var_dump($i);
var_dump($i==$j);
apc_inc($key, 1);
$i++;
var_dump($j=apc_fetch($key));
var_dump($i);
var_dump($i==$j);
We get:
int(9223372036854775807)
int(9223372036854775807)
bool(true)
int(-9223372036854775808)
double(9.2233720368548E+18)
bool(false)
Don't you think we should have consistent behavior between interger overflow in cache and in PHP var ?
P.S. I haven't test, but I think APC is also affected.
Getting error that APC_ITER_TYPE constant is not defined
upgrading to a current apcu build
git reflog
1 2c1f11c HEAD@{0}: clone: from https://github.com/krakjoe/apcu.git
on linux/64 with
php -v
PHP 5.5.9-dev (cli) (built: Jan 17 2014 21:28:20)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2014, by Zend Technologies
after configure success
phpize
./configure \
--prefix=/usr/local/apcu \
--libdir=/usr/local/apcu/lib64 \
--enable-apcu --enable-apc-bc --disable-apcu-debug \
--enable-shared --disable-static \
--with-php-config=/usr/local/php5/bin/php-config \
--disable-apcu-mmap \
--enable-apcu-rwlocks \
--disable-apcu-spinlocks \
--enable-apcu-clear-signal \
--with-gnu-ld \
--enable-libtool-lock
make fails
make -j1
...
/bin/sh /usr/local/src/apcu/libtool --mode=compile /usr/bin/gcc-4.8 -D_GNU_SOURCE -I. -I/usr/local/src/apcu -DPHP_ATOM_INC -I/usr/local/src/apcu/include -I/usr/local/src/apcu/main -I/usr/local/src/apcu -I/usr/local/php5/include/php -I/usr/local/php5/include/php/main -I/usr/local/php5/include/php/TSRM -I/usr/local/php5/include/php/Zend -I/usr/local/php5/include/php/ext -I/usr/local/php5/include/php/ext/date/lib -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -DHAVE_CONFIG_H -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -c /usr/local/src/apcu/apc_cache.c -o apc_cache.lo
/usr/bin/gcc-4.8 -D_GNU_SOURCE -I. -I/usr/local/src/apcu -DPHP_ATOM_INC -I/usr/local/src/apcu/include -I/usr/local/src/apcu/main -I/usr/local/src/apcu -I/usr/local/php5/include/php -I/usr/local/php5/include/php/main -I/usr/local/php5/include/php/TSRM -I/usr/local/php5/include/php/Zend -I/usr/local/php5/include/php/ext -I/usr/local/php5/include/php/ext/date/lib -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -DHAVE_CONFIG_H -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=native -mtune=native -c /usr/local/src/apcu/apc_cache.c -fPIC -DPIC -o .libs/apc_cache.o
In file included from /usr/local/php5/include/php/main/php.h:38:0,
from /usr/local/src/apcu/apc.h:68,
from /usr/local/src/apcu/apc_cache.h:34,
from /usr/local/src/apcu/apc_cache.c:33:
/usr/local/src/apcu/apc_cache.c: In function ‘apc_cache_stat’:
/usr/local/src/apcu/apc_cache.c:1625:50: error: ‘apc_cache_slot_t’ has no member named ‘mtime’
add_assoc_long(stat, "mtime", (*slot)->mtime);
^
/usr/local/php5/include/php/Zend/zend_API.h:385:92: note: in definition of macro ‘add_assoc_long’
#define add_assoc_long(__arg, __key, __n) add_assoc_long_ex(__arg, __key, strlen(__key)+1, __n)
^
make: *** [apc_cache.lo] Error 1
Hi. Recently I've switched to php 5.5 with apcu extension and started to get weird fatal errors. After some investigations I found out that some of my User Cache Entries became broken.
At start I see this cached var
Array
(
[strategy] => nested
[activate_locking] =>
[locking_timeout] => 3
[left] => lft
[level] => lvl
[right] => rgt
[root] => root
[parent] => parent
[useObjectClass] => AsPages\Entity\Page
)
And after several hours it becomes to
Array
(
[└ьTоerro] => nested
[░8`о�9`о] =>
[=E■i�╕:`ом:`] => 3
[ф<`о] => lft
[uYо(] => lvl
[Remov] => rgt
[�] => root
[└╢N║�] => parent
[,|\о╠{\о<ю] => AsPages\Entity\Page
)
There were no such problems with php 5.4 and apc extension
The similar problem is described here http://stackoverflow.com/questions/18309583/doctrine-extension-bug-with-apcu-orm-treelistener-does-not-support-tree-type
I am using latest version of php 5.5.3 and dev version of apcu.
I face the problem both in Debian 7 and Ubuntu 12
PHP Warning: apc_clear_cache() expects exactly 0 parameters, 1 given
If the API is changing, shouldn't it emit PHP Deprecated instead?
When storing array some keys are scrambled to some random value same length as previous key.
$apc_data = array(
'test'=>'123',
'data'=>'test123456');
$apc_key = 'abc';
apc_store($apc_key, $apc_data);
Array
(
[@��b] => 123
[`��b] => test123456
)
PHP 5.5.1
APCu 4.0.2
Apache 2.2.15
CentOS release 6.4 x86_64
--- /home/tatsh/dev/apcu/config.m4 2013-07-04 04:03:33.067676349 -0700
+++ config.m4 2013-07-09 22:59:08.014319936 -0700
@@ -5,17 +5,17 @@
PHP_ARG_ENABLE(apcu, whether to enable APCu support,
[ --enable-apcu Enable APCu support])
-PHP_APC_BC=yes
AC_MSG_CHECKING(if APCu should provide APC full compatibility support)
AC_ARG_ENABLE(apc-bc,
-[ --enable-apc-bc Enable APC full compatibility support],
-[ if test "x$enableval" = "xno"; then
- PHP_APC_BC=no
- else
- PHP_APC_BC=yes
- fi
+[ --disable-apc-bc Disable APC full compatibility support],
+[
+ PHP_APC_BC=no
+ AC_MSG_RESULT(no)
+],
+[
+ PHP_APC_BC=yes
+ AC_MSG_RESULT(yes)
])
-AC_MSG_RESULT($PHP_APC_BC)
AC_MSG_CHECKING(if APCu should be allowed to use rwlocks)
AC_ARG_ENABLE(apcu-rwlocks,
With the current version of 4.0.1 in PECL, the assertion for testing whether or not PHP_APC_BC
should be yes
is incorrect (any value always makes it change to no
). This is the difference between the version on site and the one here.
The original APC serialization support was a bit different than APCu one.
The apc_register_serializer function was part of the apc_serializer.h header.
Which means this header need to be present at build time, but that apc.so could be missing at runtime.
With current implementation, as this function is in apcu.so, a extension, as igbinary which want to implement its serializer must requires apcu which is probably not a good idea.
With igbinary build against apc:
$ php -n -d extension=igbinary.so -m
...
igbinary
With igbinary build against apcu:
$ php -n -d extension=modules/igbinary.so -m
PHP Warning: PHP Startup: Unable to load dynamic library 'modules/igbinary.so' - modules/igbinary.so: undefined symbol: apc_register_serializer in Unknown on line 0
...
I propose to revert to the original APC behavior
When I try to create a package from current git, I get an error:
pecl package package.xml
pecl install -f apcu-4.0.2.tgz
...
In file included from /var/tmp/apcu/apc.c:34:
/var/tmp/apcu/apc.h:127:28: error: apc_serializer.h: No such file or directory
In file included from /var/tmp/apcu/apc.c:34:
...
I think, the problem is simply, that apc_serializer is not included in package.xml.
Got a "apc_clear_cache() expects exactly 0 parameters, 1 given" warning.
Calling apc_clear_cache('user') should flushes the user cache. apcu does not accept a parameter, so it's not fully BC. See http://php.net/manual/en/function.apc-clear-cache.php
Expected behaviour: apc_clear_cache should accept a parameter.
Hey,
I have a weird problem with apcu_delete: It returns false for me all the time, although a apcu_fetch with the appropriate parameters fetches the content from the key I want to delete correctly.
Can someone have a look at it please?
Thanks.
apc.shm_size => 1000M
0byte memory usage APC
I've been looking into upgrading our systems from 5.3.19 to 5.5.5, and APC 3.1.15 seems to be trampling memory, so I'm giving APCu a shot as a drop-in replacement. Dropped it in and... found two missing functions that we rely on. :)
Short of compiling hidef and figuring out how to implement it, are there any plans for having APCu provide these two functions?
Using PHP 5.5.5 and APCu 4.0.2 on CentOS 6.
Thanks!
When calling apc_cache_info('user')
, the array keys seems to differ from apc's ones.
With apcu I got:
[nslots] => 4099
[ttl] => 0
[nhits] => 24
[nmisses] => 42
[ninserts] => 52
[nentries] => 28
[nexpunges] => 0
[stime] => 1379344890
[mem_size] => 58000
[file_upload_progress] => 1
[memory_type] => IPC shared
[cache_list] => Array
(
[0] => Array
(
[key] => Myapp__cake_core_cake_deu
[ttl] => 86313600
[nhits] => 0
[mtime] => 1379378443
[ctime] => 1379378443
[dtime] => 0
[atime] => 1379378443
[ref_count] => 0
[mem_size] => 584
)
...
As far as I know, APC uses num_entries
instead of nentries
and start_time
instead of stime
. Also in the cache list entries, APC uses info
instead of key
. I think there are also more of these keys, but I currently have no apc installation to check them out.
Is it possible to get apcu's apc_cache_info() full compatible with apc's one?
Hi,
As a drop in replacement for apc, with fully compatible PHP api, this extension should probably be named "apc" and not "apcu" as a lot of library / framework will rely on this name (load test, version test, ...)
Ex : with ZF, see zendframework/zendframework#4101
Let me know if I can provide more info but upgrading to PHP 5.5 with APCU has caused some issues with APCIterator. I upgraded to 4.0.2 and realize it's still in beta, but since doing so have seen considerable memory issues that were never a problem with APC. Notably listing keys with APCIterator:
function list_keys($root,$key)
{
$keys = array();
$cache = new APCIterator('user', '/^'.$root.','.$key.'/', APC_ITER_VALUE);
foreach ( $cache as $key => $value ):
array_push($keys,$key);
endforeach;
sort($keys);
return $keys;
}
Returns:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 7812535048 bytes)
Any reason why it would be trying to allocate such a massive amount of memory just to list a few dozen keys?
IIS version: 7.5.7600.16385
APC version: 4.0.3 5.5 Non Thread Safe (NTS) x86 http://pecl.php.net/package/APCu/4.0.3/windows
PHP version: 5.5.9
Error:
Faulting application name: php-cgi.exe, version: 5.5.9.0, time stamp: 0x52f2a88e
Faulting module name: php_apcu.dll, version: 5.5.4.0, time stamp: 0x52eb73db
Exception code: 0xc0000005
Fault offset: 0x000030fa
Faulting process id: 0x1aa0
Faulting application start time: 0x01cf32225008c0f4
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\PHP\ext\php_apcu.dll
Report Id: 8e489ac4-9e15-11e3-8480-8c89a5711264
INI
[APCu]
extension=php_apcu.dll
apc.enabled=1
(no additional settings to APCu were set)
Opcache settings (might be related ??)
[opcache]
zend_extension = C:\PHP\ext\php_opcache.dll
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=16000
opcache.enable_file_override=1
opcache.error_log = C:\inetpub\php_logs\php_opcache_prod.log
opcache.log_verbosity_level=2
The PHP api will retain compatibility with APC, as will common configuration options, providing a drop in replacement.
Introduced in 47d68f9, apc_clear_cache and apc_cache_info now no-longer take parameters.
Ideally these functions should only accept the "user" parameter, and error if called in the way that would have operated on the file cache.
Hi,
We are experiencing a lock down on apache processes related to APCu (actually we had the very same problem with APC 3.0.1 with PHP 5.2.10). Our current versions are:
We have a somehow loaded server whose apc panel shows as follow:
There you can see the configuration and number of requests it had till it locked. The time it takes to lock varies a lot. Sometimes it just takes 5 minutes and some others it resists 20, 30 minutes or even almost 2 hours, with the same load.
The behavior is such that once some critical condition we can't identify occurs, any new apache process gets hung in the futex_wait call (as seen witch strace), as if it was never to be released because the first parameter in the futex_wait call is the same for all of them. We can kill those processes, but it isn't till we restart the whole apache that the problem disappear because any new request is stuck the same way as long as it uses APC cache.
As an additional information, almost all the entries we cache with APC have a 0 ttl as we want them to stay there forever as they don't change. We are also using OpCache for the opcodes.
After reading about similar problems we got to some ideas like the one stated in http://notmysock.org/blog/php/user-cache-timebomb.html so we changed all apc_store calls for apc_add ones with no success.
We know this isn't too much information to track the bug. If there are any other tests you want us to do, just tell us.
Thank you very much for your help.
This commit somehow prevents php_apcu.dll to load under PHP 5.5.1 VC11 X64:
286f70d
I did not yet find out where exactly it goes wrong. The Windows event log is not very descriptive...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.