Назад | Перейти на главную страницу

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

Это действительно должен быть комментарий, но он длинноват.

не слишком ли высоко или слишком низко?

Если вы не знаете как, то как нам? Вы не сказали нам, сколько там оперативной памяти и свопа, сколько используется для других вещей. Ты не сказал нам сколько памяти APC используется до сбоя системы.

файл не является файлом ядра (его формат не распознавался).

Вы проверяли ulimit? Скорее всего, файл был усечен. Тем не менее, ошибка сегментации предполагает проблему внутри самого PHP (или APC, или расширения). Вы сами планировали починить? Не поймите меня неправильно - ребята, которые пишут этот материал, будут приветствовать хорошо исследованные и задокументированные отчеты об ошибках, но первое, на что вам следует обратить внимание (и включить в свой вопрос здесь), это версия PHP, установленные расширения и версия APC.

Основной файл необходимо прочитать в системе, которая, по крайней мере, очень похожа на ту, в которой произошел сбой. В частности, вам нужно иметь одинаковые версии двоичного файла и всех задействованных библиотек, чтобы указатели выстроились в линию. Обычно проще всего запустить gdb на машине, на которой произошел сбой. Вам также потребуется установить версии двоичного файла и библиотеки, содержащие символические данные, необходимые для определения местоположений в исходных файлах, где что-то произошло. Это может означать dev-версии различных библиотек, но это зависит от того, какой дистрибутив Linux вы используете.

Вы уверены, что у вас установлена ​​нужная версия APC? Например, он решил проблему этого человека: https://stackoverflow.com/questions/14756385/php-fatal-error-php-startup-apc-mmap-mmap-failed-in-unknown-on-line-0

APC не работает как с веб-процессами, так и с командной строкой? Если это не удается только для одного из них, убедитесь, что оба пакета php являются правильными версиями для работы с вашей версией APC.

Первые два файла дампа, которые вы указали, кажутся мне очень маленькими. Чуть более 1 МБ. PHP обычно становится больше, прежде чем он дойдет до запуска любого вашего кода. Это, вероятно, согласуется с ошибкой перед загрузкой кода, и, учитывая APC, это вероятно. Один fpm - это веб-процесс, а не задание cron (если ваш cron не вызывает php через веб-интерфейс?)

Установка apc.shm_size на 512 МБ может быть оптимальной или неоптимальной для эффективности, но я бы не ожидал, что это будет причиной segfault. Вероятно, проблема может быть в поврежденных данных в кэше APC, поэтому я предлагаю вам очистить кеш. Обычный процесс - использовать файл apc.php, который, вероятно, распространяется вместе с apc. Дистрибутивы поставщиков различаются в зависимости от этого, но они включены в исходный код основной ветки разработки, так что вы сможете легко получить копию. Это дает вам веб-интерфейс для просмотра состояния вашего кеша и его очистки. Если APC не работает до такой степени, что это не работает, я не уверен, что это за процесс. Вероятно, найдите кеш, удалите его и переустановите APC, если необходимо его восстановить. (своего рода грязный подход, но не требующие больших усилий, если вы можете позволить себе кратковременное отключение).