APC用户缓存适合高负载环境？ [英] APC User-Cache suitable for high load environments?

问题描述

我们尝试在高负载环境中部署APC用户缓存作为每个服务器上的本地二级缓存，用于集中式缓存服务（redis），用于缓存具有很少更改结果和配置的数据库查询。我们基本上看看Facebook做了什么（几年前）：

We try to deploy APC user-cache in a high load environment as local 2nd-tier cache on each server for our central caching service (redis), for caching database queries with rarely changing results, and configuration. We basically looked at what Facebook did (years ago):

http://www.slideshare.net/guoqing75/4069180-caching-performance-lessons-from-facebook
http://www.slideshare.net/shire/php-tek-2007-apc-facebook

它在一段时间内工作得很好，但在高负载下几个小时后，APC运行出现问题，因此整个mod_php不再执行任何PHP。
即使是一个简单的PHP脚本，只有不再回答，而静态资源仍然由Apache提供。它没有真正崩溃，没有segfault。我们尝试了APC的最新稳定和最新测试版，我们尝试pthreads，自旋锁，每次都有同样的问题。我们提供APC有更多的内存，它可以消耗，1分钟前崩溃我们有2％的碎片和约90％的内存是免费的。当它崩溃，我们在错误日志中找不到任何东西，只重新启动Apache有帮助。只有使用自旋锁，我们得到一个php错误，这是：

It works pretty well for some time, but after some hours under high load, APC runs into problems, so the whole mod_php does not execute any PHP anymore. Even a simple PHP script with only does not answer anymore, while static resources are still delivered by Apache. It does not really crash, there is no segfault. We tried the latest stable and latest beta of APC, we tried pthreads, spin locks, every time the same problem. We provided APC with far more memory it can ever consume, 1 minute before a crash we have 2% fragmentation and about 90% of the memory is free. When it „crashes" we don’t find nothing in error logs, only restarting Apache helps. Only with spin locks we get an php error which is:

PHP致命错误：未知：在$ b $中检测到自旋锁（0x7fcbae9fe068） b未知的行0

PHP Fatal error: Unknown: Stuck spinlock (0x7fcbae9fe068) detected in Unknown on line 0

这似乎是一种超时，pthreads不会发生，因为那些不使用超时。

This seems to be a kind of timeout, which does not occur with pthreads, because those don’t use timeouts.

发生的事情可能是这样的：
http://notmysock.org/blog/php/user-cache-timebomb.html

What’s happening is probably something like that: http://notmysock.org/blog/php/user-cache-timebomb.html

一些数字：A服务器每秒大约有400个APC用户高速缓存命中，每秒大约有30个插入（我认为这很多），一个请求有大约20-100个用户高速缓存请求。在用户高速缓存中有大约300.000个变量，所有都有ttl（我们存储没有ttl只在我们的中心redis）。

Some numbers: A server has about 400 APC user-cache hits per second and about 30 inserts per second (which is a lot I think), one request has about 20-100 user-cache requests. There are about 300.000 variables in the user-cache, all with ttl (we store without ttl only in our central redis).

我们的APC设置包括：

Our APC-settings are:

apc.shm_segments=1 
apc.shm_size=4096M
apc.num_files_hint=1000
apc.user_entries_hint=500000
apc.max_file_size=2M
apc.stat=0

目前我们使用版本3.1.13-beta编译自旋锁，与旧的PHP 5.2.6（它是一个

Currently we are using version 3.1.13-beta compiled with spin locks, used with an old PHP 5.2.6 (it’s a legacy app, I’ve heard that this PHP version could be a problem too?), Linux 64bit.

这真的很难调试，我们编写了监控脚本，收集尽可能多的数据，我们可以得到每分钟从apc，系统等，但我们看不到任何不寻常的 - 即使是在崩溃之前1分钟。

It's really hard to debug, we have written monitoring scripts which collect as much data as we could get every minute from apc, system etc., but we cannot see anything uncommon - even 1 minute before a crash.

很多类似的问题在这里，但现在我们找不到解决我们的问题的解决方案。当我读到这样的东西：

I’ve seen a lot of similar problems here, but by now we couldn’t find a solution which solves our problem yet. And when I read something like that:

http://webadvent.org/2010/share-and-enjoy-by-gopal-vijayaraghavan

我不是确保如果使用APC进行本地用户高速缓存是高负载环境中的最佳做法。我们已经在这里使用memcached了，但APC是更快。但是如何让它稳定？

I’m not sure if going with APC for a local user-cache is the best idea in high load environments. We already worked with memcached here, but APC is a lot faster. But how to get it stable?

最好的问候，
Andreas

best regards, Andreas

推荐答案

第1课： https://www.kernel.org/doc/Documentation/spinlocks.txt

上面的单个自旋锁原语绝不是唯一的。他们
是最安全的，并且在所有情况下工作的那些，
但部分因为他们是安全的，他们也是相当缓慢。他们的
比他们需要的慢，因为他们必须禁用
（这只是一个x86上的单个指令，但它是一个昂贵的 -
和其他

The single spin-lock primitives above are by no means the only ones. They are the most safe ones, and the ones that work under all circumstances, but partly because they are safe they are also fairly slow. They are slower than they'd need to be, because they do have to disable interrupts (which is just a single instruction on a x86, but it's an expensive one - and on other architectures it can be worse).

这是由Linus写的

自旋锁很慢;该断言不是基于我在Facebook上在线阅读的一些文章，而是基于事实的实际事实。

Spin locks are slow; that assertion is not based on some article I read online by facebook, but upon the actual facts of the matter.

这也是一个偶然的事实，自旋锁被部署在比内核高的级别，因为你说的很麻烦;不可追踪的死锁，因为一个坏的实现。

It's also, an incidental fact, that spinlocks are deployed at levels higher than the kernel because of the very problems you speak of; untraceable deadlocks because of a bad implementation.

它们被内核高效使用，因为这是他们设计使用的地方，锁定了微小的微小部分，等待您将亚马逊肥皂反应复制到apc中，并每秒回收十亿次。

They are used by the kernel efficiently, because that's where they were designed to be used, locking tiny tiny tiny sections, not sitting around and waiting for you to copy your amazon soap responses into apc and back out a billion times a second.

最适合的锁定类型（适用于网络，而不是内核）在APC中可用的是绝对 rwlocks，您必须在旧版APC中使用configure选项启用rwlocks，并且它是APCu中的默认值。

The most suitable kind of locking (for the web, not the kernel) available in APC is definitely rwlocks, you have to enable rwlocks with a configure option in legacy APC and it is the default in APCu.

最好的建议，可以提供，我已经给它，是不使用自旋锁，如果互斥引起你的堆栈死锁然后尝试rwlocks。

The best advice that can be given, and I already gave it, is don't use spinlocks, if mutex are causing your stack to deadlock then try rwlocks.

，你的主要问题是你使用的是一个来自古代的PHP版本，甚至没有人记住如何支持，一般你应该看看升级，我知道OP的约束，但是，否定提及这是一个真正的问题，你不想部署在不支持的软件上是不负责任的。另外，APC是无法维护的，它注定要死。

Before I continue, your main problem is you are using a version of PHP from antiquity, which nobody even remembers how to support, in general you should look to upgrade, I'm aware of the constraints on the OP, but it would be irresponsible to negate to mention that this is a real problem, you do not want to deploy on unsupported software. Additionally APC is all but unmaintained, it is destined to die. O+ and APCu are it's replacement in modern versions of PHP.

无论如何，我离线...

Anyway, I digress ...

同步是一个头痛，当你编程在内核的水平，用spinlocks或任何。当你从内核中删除几个层时，当你依赖于6或7位复杂的软件下面正确同步，以便你的代码可以正确同步同步成为，不仅是程序员的头痛，而是执行者;即使

Synchronization is a headache when you are programming at the level of the kernel, with spinlocks, or whatever. When you are several layers removed from the kernel, when you rely on 6 or 7 bits of complicated software underneath you synchronizing properly in order that your code can synchronize properly synchronization becomes, not only a headache for the programmer, but for the executor too; it can easily become the bottleneck of your shiny web application even if there are no bugs in your implementation.

很高兴，这是2013年，和雅虎不是唯一能够在PHP中实现用户缓存的人：）

Happily, this is the year 2013, and Yahoo aren't the only people able to implement user caches in PHP :)

http://pecl.php.net/package/yac

这是一个非常聪明的无锁缓存的用户级PHP，它被标记为实验，但一旦你完成，有一个玩，也许在另一个7年，我们不会考虑同步问题：）

This is an, extremely clever, lockless cache for userland PHP, it's marked as experimental, but once you are finished, have a play with it, maybe in another 7 years we won't be thinking about synchronization issues :)

我希望你到达底部：）

这篇关于APC用户缓存适合高负载环境？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！