Come posso impedire ad Apache di cadere?

Ho un paio di server che ospitano un singolo sito di e-commerce Magento con traffico moderato (60k visualizzazioni di pagina al giorno segnalate da Google Analytics, penso a 80k riportate sul server stesso). Il server database funziona senza intoppi e rapidamente, a parte un raro singhiozzo occasionale, ma il server apache è caduto ogni tanto.

Ho impostato magento per utilizzare la cache di PHP (APC) consigliata, oltre a contenere i propri file di cache in un tmpfs da 1,5 gig (questo tmpfs diventa regolarmente abbastanza pieno e ho uno script in esecuzione per cancellare i file di cache quando il tmpfs è più dell'80% completo). Fornisco la maggior parte delle immagini da Amazon Cloudfront. Di recente ho impostato nginx come proxy inverso per apache (nginx serve anche i file statici). Ho configurato apache al meglio delle mie possibilità - keepalive e hostnamelookups sono disattivati ​​e il prefork è configurato come segue:

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

Non ho disattivato i file .htaccess e la registrazione degli accessi è attiva. So che ci sono alcuni moduli che posso disattivare. Non sono sicuro di quale effetto avrebbe una di queste tre modifiche, se presente.

Il server apache è un VPS con 6 gig di RAM. Al momento della stesura del report load average: 17.77, 18.27, 49.76, il server riporta , ma ci sono circa 2 gig di RAM liberi. Quando va davvero male, il carico va a 120+ e rimane lì - riavviare apache riporta il sito su e il carico di nuovo.

vmstatè (mentre il server segnala il carico sopra), penso, mostrando un valore di inattività della CPU che oscilla tra 0 e 70 o giù di lì. iostatmostra un valore di iowait compreso tra 0 e 0,2%.

Sono un po 'bloccato. Quello che poco so mi sta dicendo che il problema è che la CPU è sovraccarica a causa della combinazione del codice in esecuzione e del numero di utenti. Ma non sono abbastanza esperto per essere certo che questo è il problema. Se questo è il problema, penso che le soluzioni consistano nel migliorare il codice o nel dividere l'hosting del sito su due VPS con un bilanciamento del carico.

Quindi, immagino che le mie domande siano:

1. Cos'altro posso fare per trovare problemi o colli di bottiglia sul server?
2. Ci sono delle ovvie modifiche che posso apportare alla configurazione del server per migliorare questo?
3. È una buona idea impostare un sistema automatizzato per riavviare apache quando il carico supera un determinato livello?
4. Da quanto sopra, quanto è probabile che il sito abbia superato il server?

Modificare:

Ho trovato qualcosa di strano - / var / spool / mail / root era grande ... 38 gig. Sembra ... malsano. Potrebbe essere questo il problema?

Magento e Zend Framework sono abbastanza pesanti per la CPU, come hai notato. Il modo migliore per evitare il carico della CPU è semplicemente il rendering del contenuto una sola volta, fino a quando non cambia. La maggior parte delle parti del catalogo non cambia così spesso, e spesso solo il blocco del carrello della spesa nella pagina o il blocco degli "articoli più popolari" sono le uniche parti dinamiche.

Suggerirei di mettere una cache Varnish di fronte ad Apache. Questo ti offre un caching delle pagine ad alte prestazioni che può scaricare seriamente il tuo stack LAMP. Di recente siamo sopravvissuti a un lancio molto pubblico di un sito Web grazie a Varnish e sono rimasto molto colpito dalla velocità e dal basso carico di CPU. Varnish è gratuito e abbastanza flessibile da memorizzare nella cache intere pagine o memorizzare nella cache solo le parti relativamente statiche e includere il carrello in modo dinamico.

Tuttavia, Varnish non memorizzerà molto nella cache su un'installazione di Magento predefinita, poiché ci sono molti contenuti dinamici per utente, cookie, ecc. Un modulo Magento come " PageCache basato su Varnish " modifica Magento per funzionare bene con Varnish. Fornisce inoltre un file di configurazione di Varnish che corrisponde all'impostazione di Magento. Questi due insieme rendono l'installazione molto efficiente. È un modulo commerciale, ma molto più conveniente di un server più potente.

Le parti che scarichi su una CDN o Nginx non sono il tuo vero problema, anche se aiutano. Anche Apache è in grado di gestire numerose richieste statiche. È necessario memorizzare nella cache le cose che si impegnano a generare ancora e ancora, cioè le parti dinamiche.

Normalmente installo MaxRequestsPerChild in modo che sia migliaia - di solito più vicino a 10.000.

Dici di avere "la cache PHP consigliata", ma hai APC installato? Infine, quanti utenti vedi colpire il sito Web contemporaneamente. Se hai le statistiche estese di Apache, sarai in grado di vedere quanti processi Apache sono effettivamente nello stato In esecuzione alla volta.

800 file APC colpiscono al secondo e altri 200 cache utente sono molti. Se si tratta di un dual o quad-core, mi aspetterei comunque che stia bene. Se il database sta davvero mantenendo il passo, quindi ottenere una macchina più grande - e più CPU, potrebbe essere la cosa migliore per questo, almeno in questo momento.

Il tuo carico medio è del tutto troppo elevato per un VPS dual core. 8 dovrebbe essere il massimo.

Ho avuto un buon successo con l'utilizzo di mod_pagespeed e dell'evento MPM per Magento. Consiglierei di passare all'utilizzo dell'evento MPM e di installare mod_pagespeed.

Ulteriori informazioni su Event MPM: Documentazione MPM dell'evento Apache

E mod_pagespeed: Codice Google: mod_pagespeed

Se continui ad avere problemi di caricamento anche dopo aver apportato le modifiche di cui sopra, ti consigliamo di passare a un piano VPS diverso e migliore.

Come suggerisce Alister, un valore MaxRequestsPerChild di 400 è assurdamente basso.

La media del carico è molto alta, ma 60k visualizzazioni di pagina al giorno non sono molto trafficate.

quanti processi hai normalmente richieste di servizio?

Non ho familiarità con Magento ma sembra che ci sia qualcosa di sbagliato in questa configurazione. Mi aspetto che tu possa ottenere una produttività significativamente maggiore a un livello di carico inferiore.

Vai a prendere una copia del libro di Steve Souders e leggilo. Abilita la compressione per tutto il contenuto HTML in uscita (statico e dinamico). E assicurati di avere una buona configurazione della cache. Inizia a registrare% D nel tuo file access_log e crea alcuni strumenti per analizzare i dati / isolare la lentezza. Simile per MySQL.

Prova mysqltuner.pl e vedi se segnala eventuali problemi.

Eseguo un'installazione simile, ma con nginx / php-fpm / apc (opcode e fast_backend / memcached (slow_backend). Trovo che php sia il problema di risorse più grande, probabilmente perché magento è follemente grande o semplicemente codificato male. guarda cosa sta esattamente mangiando le risorse, potrebbe essere php come nel mio caso?

Oltre a ciò che scrive Martijn Heemels, c'è un modulo di vernice open source che potresti provare. Dai un'occhiata a http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ e https://github.com/madalinoprea/magneto-varnish .
L'ho provato solo in un ambiente di test, e finora tutto bene.

Salvate sessioni nel database o su disco (e, in tal caso, su tmpfs)?

Quando usi VPS stai condividendo la CPU. Ti consiglio di parlare con il tuo host per spostare il tuo VPS su un hardware meno occupato o dedicarti.

A causa della CPU condivisa, le tue applicazioni non sono in grado di funzionare in tempo e continuano ad essere messe in coda creando richieste più elevate da elaborare e anche le spese generali che ne derivano. Alla fine c'è una condizione in cui Apache o php o mysql avrebbero raggiunto il limite massimo e questi causerebbero problemi.

La linea di fondo è. VPS è sostanzialmente una CPU condivisa. Il tuo host potrebbe mettere troppi account VPS sulla stessa CPU.

Se si desidera sfruttare appieno la CPU allocata, richiedere un server migliore con meno VPS, se possibile (spostare l'host anche se è problematico) o dedicarsi.

Potresti anche scegliere Amazon completamente e non preoccuparti di nginx usando il bilanciamento del carico, che richiede pochi clic per configurare tutti i tuoi server nel loro cloud.

la cartella /var/mail.../root è hue significa che raccoglie molte e-mail che provengono solitamente dalle tue applicazioni. Ad esempio, uno script php con errori sta tentando di inviare e-mail o tutti i processi cron sono configurati per inviare all'utente lo stato delle esecuzioni cron e l'output. Puoi guardare dentro la posta e vedere cosa ha il file. Sto indovinando i suoi messaggi di errore in modo da poter trovare da dove viene.

Aggiungerò altro se hai bisogno di ulteriori informazioni e potrebbe essere che avrò bisogno anche di alcune informazioni