【问题标题】:APC is corrupting outputAPC 正在破坏输出
【发布时间】:2013-01-27 20:05:21
【问题描述】:

我最近将我的网络服务器切换到 Centos 6.3,使用 apache 2.2.15、PHP 5.4.11 和 APC 3.1.14。

我开始不时收到客户的投诉,即页面无法正常工作或出现奇怪的错误。我看到受影响的页面在输出的随机位置有问号和其他奇怪的符号,即使来源是好的。当我更改源文件中的一个字母时,页面开始正常工作。

我怀疑 APC,但我找不到任何线索何时以及为什么会发生这种情况。

我使用 mercurial 将更改推送到生产环境,但多年来我一直使用这种方法没有任何问题。也许配置中的某些内容现在是新的,但遗憾的是我没有保留旧配置。

以下是上次损坏的屏幕截图。

编辑:这是我在源中更改了单个字符、保存并撤消文件后的响应(如果我只是重新启动 Web 服务器或清除 APC 操作码缓存):

请注意行号不匹配,但它是 100% 相同的请求,因此响应也应该相同。第一个屏幕截图中的第 111 行根本不应该存在。好像是来自另一个源文件...

【问题讨论】:

  • 页面是什么字符集? (元标头和服务器标头?)数据库是什么排序规则(如果有的话)-一切都匹配吗?
  • 一切都是 UTF-8。如果是字符集问题,那不是永久问题吗?
  • 绝对是。想知道这是否通常是可以的,几乎是巧合,但 APC 出现了一个潜在的问题。当它被损坏时,它总是在同一个地方? (即,如果您刷新了该页面,它会不会是一样的?)如果您清除 APC 缓存,而不更改任何其他内容,它是否仍然损坏,如果是,它又是在同一个地方吗?
  • 页面上的文字“TotalBytesReceived”是正常的,还是神奇地出现了?
  • 如果刷新,有问题的输出在同一行。它不受刷新的影响。 TotalBytesReceived 是源文件中的数组键,但它绝不会在任何地方打印或回显...

标签: php apc output corruption


【解决方案1】:

我已将 apc.stat_ctime 更改为 1

使用 ctime 进行验证将通过确保自上次统计以来 inode 没有更改,从而避免由 svn 或 rsync 等程序引起的问题。 APC 通常只会检查 mtime。

我会密切关注这个问题,因为它每周发生一到两次,如果解决了问题,我会在此处发布。

【讨论】:

  • 在我看来问题已经解决了!
猜你喜欢
  • 2021-08-07
  • 2018-01-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-02
  • 2012-06-26
  • 1970-01-01
  • 2016-02-06
相关资源
最近更新 更多