php falha sem arquivo principal e esta mensagem: apc_mmap falhou

Question

Descrição do problema

Regularmente, os processos do cron php param em nosso servidor de produção, o que resulta em e-mails com o seguinte corpo:

PHP Fatal error: PHP Startup: apc_mmap: mmap failed: in Unknown on line 0 Segmentation fault (core dumped)

Eu acho que o Segmentation fault (core dumped) deve resultar em arquivos principais sendo manipulados pelo apport e então gravados em /var/crashes , mas os arquivos que eu vejo lá estão lá desde ontem, embora o último travamento tenha ocorrido hoje:

-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

Eu tentei baixar o último mesmo assim, e executei gdb /usr/sbin/php5-fpm /tmp/_usr_sbin_php5-fpm.1005.crash , apenas para saber que o arquivo não é um arquivo principal (seu formato não foi reconhecido).

Aqui está a configuração do servidor:

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

Estou mais preocupado com o apc.shm_size ... não é muito alto ou muito baixo? Eu entendo que tem a ver com o tamanho dos segmentos de memória.

Pergunta (s)

1. Qual poderia ser o problema?
2. Como posso resolver o problema (como posso obter um arquivo principal válido?)?

Informações do sistema

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 excerpt:

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

    

Answer 1

O arquivo principal precisa ser lido em um sistema que seja pelo menos muito semelhante àquele em que o travamento ocorreu. Em particular, você precisa ter as mesmas versões do binário e de todas as bibliotecas envolvidas para que os ponteiros sejam alinhados. Geralmente é mais fácil rodar o gdb na máquina onde ocorreu o travamento. Você também precisará ter versões do binário e bibliotecas instaladas que tenham os dados simbólicos necessários para identificar os locais nos arquivos de origem onde as coisas aconteceram. Isso pode significar as versões dev das várias bibliotecas, mas Depende da distribuição do linux que você executa.

Tem a certeza de que tem a versão correta do APC instalada? Por exemplo, resolveu o problema dessa pessoa: link

A APC está falhando em processos da Web, bem como em processos de linha de comando? Se ele falhar apenas por um desses, verifique se ambos os pacotes php são as versões corretas para trabalhar com sua versão do APC.

Os dois primeiros arquivos de despejo que você listou parecem muito pequenos para mim. Pouco mais de 1 MB. O PHP normalmente fica maior do que antes de executar qualquer código. É provável que seja consistente com a falha antes de carregar o código, e se a APC estiver envolvida, é provável. O fpm é um processo web, não um cron job (a menos que seu cron chame php através da interface web?)

Configurar o apc.shm_size para 512MB pode ou não ser ideal para eficiência, mas eu não esperaria que fosse a causa de um segfault. No entanto, os dados corrompidos em seu cache do APC podem ser o problema, por isso sugiro que você limpe o cache. O processo normal é usar um arquivo apc.php que provavelmente é distribuído com o apc. As distribuições do fornecedor variam de acordo com isso, mas ele é incluído no código-fonte upstream, portanto, você deve conseguir uma cópia com bastante facilidade. Isso fornece uma interface da Web para examinar o estado do seu cache e para limpá-lo. Se a APC estiver falhando ao ponto de não funcionar, não sei qual é o processo. Provavelmente localize o cache, exclua-o e reinstale o APC, se necessário, para reconstruí-lo. (abordagem meio suja, mas pouco esforço se você puder pagar uma breve interrupção).

    

Answer 2

Isso deve ser realmente um comentário, mas é um pouco longo

isn't it too high or too low ?

Se você não sabe como, como deveríamos? Você não nos contou quanto RAM e swap há, quanto é usado para outras coisas. Você não nos disse quanto da memória APC é usado antes que o sistema trave.

file is not a core file (its format was not recognized).

Você verificou o ulimit? O mais provável é que o arquivo tenha sido truncado. Independentemente disso, uma falha de segmentação sugere um problema no próprio PHP (ou APC ou uma extensão). Você estava pensando em consertá-lo? Não me entenda mal - os caras que escrevem o material vão receber relatórios de bugs bem pesquisados e documentados - mas a primeira coisa que você deve olhar (e incluir em sua pergunta aqui) é a versão do PHP, as extensões instaladas e o versão do APC.