Processi in Apache?

Sto eseguendo Apache 2.2.21 con il prefork MPM su un server dedicato. Più dettagli:

Server Version: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/1.0.0-fips DAV/2 SVN/1.7.0 mod_python/3.3.1 Python/2.6.5 mod_bwlimited/1.4 PHP/5.3.6 

Il traffico è di solito da 10 a 30 richieste / sec, ci sono 12 GB di RAM, e abbiamo sintonizzato MaxClients abbastanza conservativamente (250). Vediamo spie di utilizzo per vari motivi (su un server più vecchio, abbiamo colpito i nostri MaxClients di 100 diverse volte durante questi picchi).

  • Memcache + PHP tuning di session: come i memcache scadono le chiavi?
  • Distriggersre il file di log di MySQL
  • Monit non riesce a rilevare MySQL, ma posso
  • Cosa significa il codice HTTP 172?
  • IPv6 funziona bene, IPv4 lancia l'errore OpenSSL
  • Esegui un server virtuale o acquista un server fisico?
  • Comunque, questo è un nuovo server. Dopo aver funzionato per un po ', il nostro stato Apache inizia a sembrare qualcosa di simile:

     GGG_._._RC_.G..C.G_G.C_G..C_.CG_._._G__W____..R.WCR_.W..G_...... 

    I G ("Gracefully finishing") stanno bloccando. Spariscono solo se riavvii Apache. Ciò sicuramente ci farà toccare il nostro limite MaxClients senza monitoraggio / fissaggio regolare. Leggo su Internet e sembra che ci sia un bug in Apache che è simile a questo, ma succede in condizioni diverse. E 'stato anche apparentemente corretto nella versione 2.2.14.

    Sono inclusa la stacktrace di un process appeso per l'ispezione.

     #0 0x000000350c6f119e in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x000000350c67c138 in _L_lock_9164 () from /lib64/libc.so.6 #2 0x000000350c679a32 in malloc () from /lib64/libc.so.6 #3 0x000000350c66fcfb in __libc_message () from /lib64/libc.so.6 #4 0x000000350c675676 in malloc_printerr () from /lib64/libc.so.6 #5 0x000000350c675aa1 in malloc_consolidate () from /lib64/libc.so.6 #6 0x000000350c677f38 in _int_free () from /lib64/libc.so.6 #7 0x0000003906c64cbb in my_once_free () at my_once.c:117 #8 0x0000003906c5d6ff in my_end (infoflag=0) at my_init.c:170 #9 0x0000003906c5c547 in mysql_server_end () at libmysql.c:209 #10 0x00007f34ac195be8 in zm_shutdown_mysqli (type=<value optimized out>, module_number=22) at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli.c:834 #11 0x00007f34ac2b825f in module_destructor (module=0x1eafce0) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_API.c:2098 #12 0x00007f34ac2be945 in zend_hash_apply_deleter (ht=0x7f34ac988aa0, p=0x1eafc80) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_hash.c:614 #13 0x00007f34ac2bebd8 in zend_hash_graceful_reverse_destroy (ht=0x7f34ac988aa0) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_hash.c:649 #14 0x00007f34ac2b3085 in zend_shutdown () at /home/cpeasyapache/src/php-5.3.6/Zend/zend.c:759 #15 0x00007f34ac26017a in php_module_shutdown () at /home/cpeasyapache/src/php-5.3.6/main/main.c:2146 #16 0x00007f34ac260229 in php_module_shutdown_wrapper (sapi_globals=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/main/main.c:2118 #17 0x00007f34ac33a461 in php_apache_child_shutdown (tmp=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/sapi/apache2handler/sapi_apache2.c:399 #18 0x00007f34ae59dea4 in run_cleanups () from /usr/local/apache/lib/libapr-1.so.0 #19 0x00007f34ae59cd72 in apr_pool_destroy () from /usr/local/apache/lib/libapr-1.so.0 #20 0x00000000004cc004 in clean_child_exit () #21 0x00000000004ccd00 in child_main () #22 0x00000000004cce62 in make_child () #23 0x00000000004cd107 in perform_idle_server_maintenance () #24 0x00000000004cd664 in ap_mpm_run () #25 0x000000000042e24f in main () 

    Sembra che il problema si verifichi quando il nostro script PHP chiude la connessione mysqli. C'è un appello quando si cerca di liberare la memory. Chiunque abbia una configuration simile – Apache 2.2.21, PHP 5.3.6, MySQL / mysqli (5.1.56) – ha problemi simili?

    Qualcuno sa cosa posso cercare di fare per risolvere questo problema? Aggiornare MySQL / Apache / PHP? Sono felice di fornire ulteriori informazioni se aiuta.

    Grazie!

    UPDATE: Sembra che MySQL non sia veramente coinvolto nel problema. Ecco un'altra stacktrace di un process appeso che include solo PHP:

     #0 0x000000350c6f119e in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x000000350c67c138 in _L_lock_9164 () from /lib64/libc.so.6 #2 0x000000350c679a32 in malloc () from /lib64/libc.so.6 #3 0x000000350c66fcfb in __libc_message () from /lib64/libc.so.6 #4 0x000000350c675676 in malloc_printerr () from /lib64/libc.so.6 #5 0x000000350c675aa1 in malloc_consolidate () from /lib64/libc.so.6 #6 0x000000350c677f38 in _int_free () from /lib64/libc.so.6 #7 0x00007f532accb951 in zend_mm_shutdown (heap=0x2327aa0, full_shutdown=1, silent=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_alloc.c:1648 #8 0x00007f532ac951af in php_module_shutdown () at /home/cpeasyapache/src/php-5.3.6/main/main.c:2159 #9 0x00007f532ac95229 in php_module_shutdown_wrapper (sapi_globals=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/main/main.c:2118 #10 0x00007f532ad6f461 in php_apache_child_shutdown (tmp=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/sapi/apache2handler/sapi_apache2.c:399 #11 0x00007f532cfd2ea4 in run_cleanups () from /usr/local/apache/lib/libapr-1.so.0 #12 0x00007f532cfd1d72 in apr_pool_destroy () from /usr/local/apache/lib/libapr-1.so.0 #13 0x00000000004cc004 in clean_child_exit () #14 0x00000000004ccd00 in child_main () #15 0x00000000004cce62 in make_child () #16 0x00000000004cd107 in perform_idle_server_maintenance () #17 0x00000000004cd664 in ap_mpm_run () #18 0x000000000042e24f in main () 

    UPDATE 2: scopre che questo è un problema noto per alcuni sisthemes.

    http://docs.cpanel.net/twiki/bin/view/EasyApache3/EA3KnownIssues#Bug:%20Apache%202.2%20Child%20Processes

    Ho notato che stavo anche ottenendo lo stato di "C" che i processi di Apache appendono per un bel po 'di tempo (> 3000 secondi). Ho scritto un cron per uccidere i processi che appaiono nello stato "G" o "C" per lungo tempo … ma questo è un aiuto a banda. Vorrei risolvere il problema.

    Una cosa che ho notato e anche cambiato, circa la mia configuration è stato che non stavo impostando la direttiva "GracefulShutdownTimeout":

    http://httpd.apache.org/docs/2.2/mod/mpm_common.html#gracefulshutdowntimeout

    Ho aggiunto questo e cambiato in 30 secondi. Vedremo se anche questo aiuterà.

    Ulteriori informazioni: Ecco l'output del cat / proc / PROCESS_ID / stato per uno dei processi "G":

     Name: httpd State: S (sleeping) Tgid: 14867 Pid: 14867 PPid: 30017 TracerPid: 0 Uid: 99 99 99 99 Gid: 99 99 99 99 Utrace: 0 FDSize: 64 Groups: 99 VmPeak: 355752 kB VmSize: 222996 kB VmLck: 0 kB VmHWM: 191120 kB VmRSS: 77928 kB VmData: 62300 kB VmStk: 96 kB VmExe: 1032 kB VmLib: 24736 kB VmPTE: 488 kB VmSwap: 0 kB Threads: 1 SigQ: 0/95107 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 000000018c0046eb CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffffffffffff Cpus_allowed: ffffff Cpus_allowed_list: 0-23 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003 Mems_allowed_list: 0-1 voluntary_ctxt_switches: 24708 nonvoluntary_ctxt_switches: 2651 

    Moduli caricati in Apache:

      core_module (static) authn_file_module (static) authn_default_module (static) authz_host_module (static) authz_groupfile_module (static) authz_user_module (static) authz_default_module (static) auth_basic_module (static) include_module (static) filter_module (static) log_config_module (static) logio_module (static) mime_magic_module (static) expires_module (static) setenvif_module (static) ssl_module (static) mpm_prefork_module (static) http_module (static) mime_module (static) dav_module (static) status_module (static) autoindex_module (static) info_module (static) suexec_module (static) cgi_module (static) dav_fs_module (static) dav_lock_module (static) negotiation_module (static) dir_module (static) actions_module (static) userdir_module (static) alias_module (static) rewrite_module (static) so_module (static) python_module (shared) dav_svn_module (shared) authz_svn_module (shared) bwlimited_module (shared) php5_module (shared) 

    Moduli caricati in PHP:

     [PHP Modules] bcmath Core ctype curl date dom eAccelerator ereg exif filter gd gettext hash iconv imap json libxml mbstring mcrypt memcache mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite sqlite3 standard tokenizer xml xmlreader xmlwriter zlib [Zend Modules] eAccelerator 

  • La simulazione DNS per scopi di test?
  • Come faccio a sbarazzare di socket nello stato FIN_WAIT1?
  • Forza l'URL root per essere HTTPS anziché HTTP per l'applicazione RoR
  • (networking inaccessibile) nei miei registri del server
  • Come recuperare i dati da una partizione ext3 danneggiata?
  • Come utilizzare GZip per creare un file zip
  • 2 Solutions collect form web for “Processi in Apache?”

    Provare a impostare Keepalive Off . Tendo a farlo automaticamente, in particolare sui sisthemes contestati da IO, come le macchine virtuali.

    Alcune linee guida generali che mi occupo, mi dispiace se questo non è immediatamente ansible per te:

    • utilizzare il lavoratore MPM
    • evitare mod_<language>
    • utilizzare invece le interfacce fcgi PHP, Python ecc
    • utilizzare mod_fcgid

    Se non modifichi le intestazioni HTTP o simili nella tua applicazione, potresti essere in grado di passare a fcgi senza modifiche di codice.

    Quello che guadagni da questo è una separazione molto più pulita dei vari elementi che prendono gioco in questa configuration. Il httpd sarà molto più robusto nei confronti di qualsiasi bug (performance, ma anche sicurezza) che i moduli di terze parti causano.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.