New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High wall time on apc_* functions #106
Comments
Not sure if this helps, but we recently discovered that if I share this because you have (Of course, your issue may be entirely unrelated!) |
Thanks for the information. I looked at the cache after the load test completed and we have 2512 cached variables using 185MB. However, if I look at the detailed memory usage it says Fragmentation: 44.32% (371.6 MBytes out of 838.4 MBytes in 2676 fragments). I tried to set the memory allocation lower, but then I kept hitting cache full and the site got even worse. Here is the current cache information: Cached Variables 2512 (185.5 MBytes) Any other ideas? Thanks! |
I have what seems to be the same issue. How is it possible that there's been no response (from the devs) in almost a year on such a hugely critical issue?? |
And by the way, @itarchmerc did you ever find any workaround? |
2 people came along and mentioned they were having problems on one day in January. They didn't provide me nearly enough information to do anything about it, no reproducing code at all. I can't guess why something behaves the way it does, when you report a bug anywhere, you need to include enough information to reproduce the problem. Very rarely is providing configuration, or statistics, enough to determine the cause of a problem. A good description of what is required to actually help with a problem is here: http://stackoverflow.com/help/mcve APCu is not my favourite thing, so shoot me ... given enough information, I always look, when schedule allows ... |
What is "enough information"? Finding a reproducing scenario in this case is almost equivalent to finding the root cause of the bug. So, given you show little interest in the issue, it's clear it's going to stay unfixed for ages. P.S. if there is some information that I can provide, such as any log or the like, that I can extract from the live system while the issue is happening, or better after it has happened, I'll be happy to provide it. |
Yeah right. That's the dream of every developer. That is just not always (often even remotely) possible. |
Every piece of information you discover, or becomes obvious during your effort to create a MCVE is valuable information. I'm not saying you will always succeed, but try you must ... |
Meanwhile: I strongly suspect this is some kind of race condition, since I observe this in a scenario where a PHP script does a lot of reads and a few writes; so I guess, when there are many concurrent requests, somebody may shoehow get stuck wating to be able to read what somebody else is writing, who in turn for some reason is also stuck waiting (of course this doesn't make sense unless there's a bug) |
Is there at least a way I can enable some sort of logging so that I can attach a log of what's going on? |
Thinking about it, this might be intrinsically inevitable as long as #142 isn't fixed. |
Try with the latest release on pecl and report back ? |
Bump, can you try with 4.0.10 or 5.1.2 ? |
Me? Sorry, we switched to Memcached, and since I only observed the issue on a production server, it's unlikely that I'll have the opportunity to test any time soon. |
No feedback, closing ... |
I am troubleshooting an issue where our PHP site starts to slow down after about an hour of running a load test. In looking at the xhprof profiles, the calls taking the time are the apc_* functions. We are running the following:
ubuntu 14.04
apache 2.4.7
php 5.5.9
apcu 4.0.7
Our apcu settings are:
apc.coredump_unmap 0
apc.enable_cli 0
apc.enabled 1
apc.entries_hint 4096
apc.gc_ttl 3600
apc.mmap_file_mask /apc.shm.8C5Mjz
apc.preload_path
apc.rfc1867 0
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.rfc1867_ttl 3600
apc.serializer php
apc.shm_segments 1
apc.shm_size 1024M
apc.slam_defense 0
apc.smart 0
apc.ttl 0
apc.use_request_time 1
apc.writable /tmp
Beyond seeing that these functions are taking most of the wall time, I'm unable to figure out what might be misconfigured. Any ideas on the possible cause, or what other information I could gather to help diagnose this issue? Thanks.
The text was updated successfully, but these errors were encountered: