☰

php 崩溃，没有核心文件，并显示以下消息：apc_mmap failed

tag-icon • tag-icon linux php alternative-php-cache
php 崩溃，没有核心文件，并显示以下消息：apc_mmap failed

问题描述

通常情况下，我们的生产服务器上的 cron php 进程会崩溃，从而导致邮件正文如下：

PHP 致命错误：PHP 启动：apc_mmap：mmap 失败：第 0 行未知分段错误（核心转储）

我认为应该Segmentation fault (core dumped)导致核心文件由 apport 处理然后写入/var/crashes，但我可以看到从昨天开始就存在了，尽管最后一次崩溃发生在今天：

-rw-r----- 1 root        whoopsie  1138528 mai   22 04:09 _usr_bin_php5.0.crash
-rw-r----- 1 frontoffice whoopsie  1166373 mai   20 18:00 _usr_bin_php5.1005.crash
-rw-r----- 1 frontoffice whoopsie 81622658 mai   22 00:05 _usr_sbin_php5-fpm.1005.crash

无论如何，我尝试下载最后一个并运行gdb /usr/sbin/php5-fpm /tmp/_usr_sbin_php5-fpm.1005.crash，却被告知该文件不是核心文件（无法识别其格式）。

这是服务器的 apc 配置：

cat /etc/php5/cli/conf.d/20-apc.ini 
extension=apc.so
apc.shm_size=512M
apc.ttl=3600                   
apc.user_ttl=3600                
apc.enable_cli=1

我最担心的是apc.shm_size…是不是太高或太低了？我知道这与内存段的大小有关。

问题）

  1. 可能是什么问题呢 ？
  2. 我该如何排除故障（如何获取有效的核心文件？）？

系统信息

free
             total       used       free     shared    buffers     cached
Mem:       5081296    4354684     726612          0     374744     959968
-/+ buffers/cache:    3019972    2061324
Swap:       522236     516888       5348

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"

php -v
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

php -i摘录：

Configuration

apc

APC Support => enabled
Version => 3.1.13
APC Debugging => Disabled
MMAP Support => Enabled
MMAP File Mask =>  
Locking type => pthread mutex Locks
Serialization Support => php
Revision => $Revision: 327136 $
Build Date => Nov 20 2012 18:41:36

Directive => Local Value => Master Value
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => On => On
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
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 => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 512M => 512M
apc.shm_strings_buffer => 4M => 4M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 3600 => 3600
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 3600 => 3600
apc.write_lock => On => On



 php -m
[PHP Modules]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
intl
json
ldap
libxml
mbstring
memcache
memcached
mhash
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
wddx
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 39531
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 39531
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

答案1

需要在至少与发生崩溃的系统非常相似的系统上读取核心文件。特别是，您需要具有相同版本的二进制文件和所有相关库，以便指针对齐。通常，在发生崩溃的机器上运行 gdb 最容易。您还需要安装二进制文件和库的版本，其中包含您需要的符号数据，以便识别源文件中发生事件的位置。这可能意味着各种库的开发版本，但这取决于您运行的 Linux 发行版。

你确定你安装了正确版本的 APC 吗？例如，它解决了这个人的问题： https://stackoverflow.com/questions/14756385/php-fatal-error-php-startup-apc-mmap-mmap-failed-in-unknown-on-line-0

APC 是否对 Web 进程和命令行进程都失败？如果只对其中一个进程失败，则检查两个 php 包是否都是与您的 APC 版本兼容的正确版本。

您列出的前两个转储文件在我看来非常小。刚好超过 1 MB。在运行任何代码之前，PHP 通常会变得比这更大。不过，这可能与在加载代码之前失败一致，并且考虑到涉及 APC，这很可能是可能的。fpm 是一个 Web 进程，而不是 cron 作业（除非您的 cron 通过 Web 界面调用 php？）

将 apc.shm_size 设置为 512MB 可能对效率有好处，也可能没好处，但我不认为这会造成段错误。不过，APC 缓存中的损坏数据可能是问题所在，因此我建议您清除缓存。正常流程是使用 apc.php 文件，该文件可能随 apc 一起发布。供应商的发行版对此有所不同，但它包含在上游源代码中，因此您应该能够轻松获得副本。它为您提供了一个 Web 界面，用于查看缓存状态并清除缓存。如果 APC 失败到无法工作的地步，我不确定流程是什么。可能找到缓存，删除它，然后重新安装 APC 以重建它。（有点肮脏的方法，但如果您可以承受短暂的中断，则省力）。

答案2

这确实应该是一条评论，但是有点长

是不是太高或者太低了？

如果你不知道怎么做，那我们又该怎么做呢？你没有告诉我们有多少 RAM 和交换空间，有多少用于其他东西。你没有告诉我们APC 内存有多少在系统崩溃之前使用。

文件不是核心文件（无法识别其格式）。

您检查过 ulimit 吗？很可能文件已被截断。无论如何，分段错误表明 PHP 本身（或 APC 或扩展）存在问题。您打算自己修复它吗？别误会我的意思 - 编写这些内容的人会欢迎经过充分研究和记录的错误报告 - 但您应该首先查看（并包括在此处的问题中）的是 PHP 的版本、安装的扩展和 APC 的版本。

相关内容