定期，cron php进程在我们的生产服务器上崩溃，这导致邮件具有以下主体：
PHP致命错误：PHP启动：apc_mmap：mmap失败：在行0上未知分段错误（核心转储）
我认为Segmentation fault (core dumped)应该导致核心文件被apport处理，然后写入/var/crashes ，但是从昨天开始我可以看到的文件存在，尽pipe最近一次崩溃发生在今天：
-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 ，只是被告知该文件不是核心文件（其格式未被识别） 。
这是服务器的apcconfiguration：
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 …不是太高还是太低？ 我知道这与内存段的大小有关。
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
核心文件需要在至less与发生崩溃的系统非常相似的系统上读取。 特别是你需要有相同版本的二进制和所有涉及的库，以便指针排列。 通常在发生崩溃的机器上运行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对于效率来说可能并不是最佳，但我不希望它成为段错误的原因。 您的APCcaching中的数据损坏可能是问题，所以我build议您清除caching。 正常的过程是使用一个apc.php文件，它可能与apc分发。 供应商的分布情况不尽相同，但它包含在上游的源代码中，所以你应该可以很容易地获得一份副本。 这为您提供了一个Web界面，用于查看caching的状态并清除它。 如果APC没有达到这个效果，我不确定这个过程是什么。 可能findcaching，删除它，并重新安装APC，如果需要重build它。 （有点肮脏的方法，但是如果你能够承受短暂的停机，那么这种方法很简单）。
这应该是一个评论，但有点长
不是太高还是太低？
如果你不知道如何，那我们该怎么做？ 你没有告诉我们有多lessRAM和交换，有多less用于其他的东西。 在系统崩溃之前，您还没有告诉我们有多lessAPC内存被使用。
文件不是核心文件（其格式未被识别）。
你有没有检查ulimit？ 该文件很可能已被截断。 无论如何，分段错误提示了PHP本身（或APC或扩展）中的一个问题。 你打算自己修理吗？ 不要误会我的意思 – 编写这些东西的人会欢迎你经过深入研究和logging的错误报告 – 但是你应该首先看的（包括你的问题）是PHP的版本，安装的扩展和APC版本。