APC User-Cache是​​否适合高负载环境？

Question

我们尝试在高负载环境中将APC用户缓存部署为每台服务器上用于中央缓存服务（redis）的本地第二层缓存，以缓存结果很少更改的数据库查询和配置。 我们基本上看了一下Facebook（几年前）的情况：

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提供。 它并没有真正崩溃，没有段错误。 我们尝试了最新的APC稳定版和最新Beta版，我们尝试了pthreads，自旋锁，每次都遇到相同的问题。 我们为APC提供了更多的可用内存，在崩溃前1分钟，我们有2％的碎片，大约90％的内存可用。 当它“崩溃”时，我们在错误日志中什么也找不到，只有重新启动Apache才有帮助。 仅使用自旋锁，我们会得到一个PHP错误，它是：

PHP致命错误：未知：在第0行的“未知”中检测到卡住自旋锁（0x7fcbae9fe068）

这似乎是一种超时，pthread不会发生这种情况，因为这些线程不使用超时。

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

一些数字：一台服务器每秒约有400个APC用户缓存命中，每秒约有30个插入（我认为这很多），一个请求约有20-100个用户缓存请求。 用户缓存中大约有300.000个变量，所有变量都带有ttl（我们仅在中央Redis中存储ttl）。

我们的APC设置是：

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（它是旧版应用程序一起使用，我听说过此PHP版本也可能是一个问题？），Linux 64位。

调试真的很困难，我们编写了监视脚本，这些脚本收集了每分钟从apc，系统等中获得的尽可能多的数据，但是我们看不到任何不寻常的东西-即使在崩溃前一分钟也是如此。

我在这里看到了很多类似的问题，但是到目前为止，我们还没有找到可以解决我们问题的解决方案。 当我读到类似的内容时：

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

我不确定在高负载环境中将APC用于本地用户缓存是否是最好的主意。 我们已经在这里使用过memcached，但是APC快得多。 但是如何使其稳定呢？

最好的问候，安德烈亚斯

Answer 1

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

上面的单个自旋锁原语绝不是唯一的。 它们是最安全的，并且在所有情况下都可以工作，但是部分是因为它们很安全，所以它们也相当慢。 它们比所需的速度慢，因为它们必须禁用中断（这在x86上只是一条指令，但是这是一条昂贵的指令-在其他体系结构上可能更糟）。

那是莱纳斯写的...

自旋锁很慢； 该断言并非基于我在Facebook上在线阅读的某些文章，而是基于此事的实际情况。

偶然的事实是，由于您提到的很多问题，自旋锁的部署级别高于内核。 由于执行不正确而导致无法跟踪的死锁。

它们被内核有效地使用， 因为它们被设计为使用的地方 ，锁定了微小的微小部分，而不是坐在那里等待您将亚马逊肥皂响应复制到apc中，并且每秒回滚十亿次。

APC中最合适的锁定类型（对于Web，而不是内核） 肯定是rwlocks，您必须在旧版APC中使用configure选项启用rwlocks，这是APCu中的默认设置。

我已经给出的最好的建议是不要使用自旋锁，如果互斥锁导致堆栈死锁，请尝试使用rwlocks。

在继续之前，您的主要问题是您正在使用上古的PHP版本，甚至没人记得如何支持它 ，通常您应该升级，我知道OP上的限制，但这是不负责任的不用说这是一个真正的问题，您就不想在不受支持的软件上进行部署。 另外，APC几乎没有维护，注定要死。 O +和APCu是它在现代版本的PHP中的替代品。

无论如何，我离题了...

当您在内核级别使用自旋锁进行编程时，同步是一件令人头疼的事情。 当您从内核中删除了几层时，当您依赖于其下的6或7位复杂软件时，正确同步才能使代码正确同步，这不仅使程序员感到头疼，而且使执行者感到头疼。 即使实现中没有错误，它也很容易成为闪亮的Web应用程序的瓶颈。

幸运的是，今年是2013年，Yahoo并不是唯一能够在PHP中实现用户缓存的人：)

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

这是用于userland PHP的一个非常聪明的无锁缓存 ，它被标记为实验性的，但是一旦完成，就可以使用它，也许再过7年，我们就不会考虑同步问题了：）

希望您能深入浅出:)

Answer 2

除非您使用的是Freebsd派生的操作系统，否则使用自旋锁不是一个好主意，因为它们是地球上最糟糕的同步方式。 必须在freebsd中使用它们的唯一原因是因为实现者否定了对互斥锁和rwlocks的PTHREAD_PROCESS_SHARED支持，因此您别无选择，只能在这种情况下使用pg-sql启发式自旋锁。