Come posso mantenere Apache dalla caduta?

Ho un paio di server che ospitano un singolo sito di ecommerce Magento con traffico moderato (60k visualizzazioni di pagina al giorno riportte da Google Analytics, mi sembra 80k riferito sul server stesso). Il server di database funziona senza problemi e rapidamente, a parte una rara occasionalità, ma il server apache è in calo each tanto.

Ho impostato magento per utilizzare la cache PHP consigliata (APC), oltre a contenere i propri file di cache in un tmpfs di 1.5 gig (questo tmpfs ottiene regolarmente pieno e ho uno script in esecuzione per cancellare i file di cache quando il tmpfs è più dell'80% pieno). Servo la maggior parte delle immagini dal tunnel amazon. Ho recentemente impostato nginx come proxy inverso a apache (nginx serve anche i file statici). Ho configurato apache al meglio della mia capacità – keepalives e hostnamelookups sono spenti e il prefork è configurato come segue:

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

Non ho distriggersto i file .htaccess e la logging di accesso è triggers. So che ci sono alcuni moduli che posso spegnere. Non sono sicuro di quale effetto uno di questi tre cambiamenti avrebbe, se ne fosse.

Il server apache è un VPS con 6 gig RAM. A partire dal momento della scrittura il server sta riportndo la load average: 17.77, 18.27, 49.76 , ma ci sono circa 2 gig di RAM liberi. Quando va davvero male, il carico passa a 120+ e rimane lì – riavviando apache port il sito in back up e il carico indietro.

vmstat è (mentre il server sta riportndo il carico sopra), credo, mostrando un valore del minimo di CPU che varia da 0 a 70 circa. iostat sta mostrando un valore iowait compreso tra 0 e 0,2%.

Sono un po 'bloccato. Quello che so poco mi sta dicendo che il problema è che la CPU è sovraccaricata 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 siano o migliorare il codice o dividere il sito che ospita su due VPS con un bilanciatore di carico.

Quindi, credo che le mie domande siano:

  1. Cosa posso fare per trovare problemi o colli di bottiglia sul server?
  2. C'è qualche evidente cambiamento che posso fare al server config per migliorare questo?
  3. È una buona idea impostare un sistema automatico per riavviare apache quando il carico supera un certo livello?
  4. Da quanto sopra, quanto è probabile che il sito abbia superato il server?

Edit:

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

  • apache sendmail: cercando di cambiare l'utente "da" dall'appache all'account di dominio
  • Alias ​​che utilizza Nginx causando il phpMyAdmin login endless loop
  • Come controllare la mia versione di PHP e MySQL su Ubuntu VPS?
  • Come devo accordare apache quando vedo la CPU elevata, ma l'utilizzo di memory ridotta?
  • Roundcube & Postfix SMTP: routine SSL: SSL3_READ_BYTES: avvisi tlsv1 sconosciuti ca: s3_pkt.c
  • Imansible avviare php-cgi.exe - MSVCR110.dll manca
  • Che cosa provoca il limite di 300 connessioni al secondo in Apache 2.2?
  • PHP è rotto dopo l'aggiornamento a php 5.4
  • 6 Solutions collect form web for “Come posso mantenere Apache dalla caduta?”

    Magento e Zend Framework sono abbastanza pesanti per la CPU, come notai. Il modo migliore per evitare il carico della CPU è semplicemente rendere qualsiasi contenuto solo una volta, fino a quando non cambia. La maggior parte delle parti del tuo catalogo non cambiano spesso, e spesso solo il block dei carrelli della tua pagina o il block "elementi più popolari" sono le uniche parti dinamiche.

    Vorrei suggerire di mettere una cache di vernice di fronte a Apache. Ciò consente di eseguire una cache di pagina ad alte performance che può gravemente scaricare il tuo stack LAMP. Recentemente siamo sopravvissuti a un lancio molto pubblico di un sito web grazie a Varnish e sono stato seriamente impressionato dalla velocità e dal basso carico di cpu. La vernice è libera e abbastanza flessibile per memorizzare intere pagine o per cache solo le parti relativamente statiche e includere dynamicmente il carrello.

    Tuttavia, la vernice non cache molto su un'installazione predefinita di Magento, poiché c'è un sacco di contenuti dinamici per utente, cookie, ecc. Un module Magento come " PageCache alimentato da vernice " modifica Magento per funzionare bene con la vernice. Fornisce inoltre un file di configuration Varnish che corrisponde all'impostazione di Magento. Questi due insieme fanno un setup molto efficiente. È un module commerciale, ma molto più conveniente di un server più potente sarebbe.

    Le parti che il tuo scaricamento a un CDN o Nginx non sono il tuo vero problema, anche se aiuta. Anche Apache può gestire un certo numero di richieste statiche. Devi memorizzare nella cache la roba che richiede sforzi per generare nuovamente, ovvero le tue parti dinamiche.

    Normalmente imposta il MaxRequestsPerChild per essere in migliaia – di solito, più vicino 10.000.

    Dici di avere "la cache PHP consigliata" – ma hai APC installato? Infine, quanti utenti vedete di colpire il sito web contemporaneamente. Se hai statistiche estese di Apache, potrai vedere quanti processi Apache sono effettivamente nello stato di esecuzione alla volta.

    800 colpi di APC al secondo, e altri 200 cache dell'utente è molto. Se si tratta di un dual o di un quad-core, mi aspetterò che continuasse a mantenere OK. Se la base di dati è in realtà mantenendo in su, quindi get una macchina più grande – e più CPU, può essere la cosa migliore per esso, alless in questo momento.

    Il carico medio è troppo alto per un VPS a doppio nucleo. 8 dovrebbe essere il massimo.

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

    Ulteriori informazioni sull'evento MPM: la documentazione MPM di evento Apache

    E mod_pagespeed: Google Code: mod_pagespeed

    Se continui ad avere problemi di carico anche dopo aver apportto le modifiche precedenti, puoi prendere in considerazione la possibilità di passare a un diverso piano VPS migliore.

    Come afferma Alister, un valore MaxRequestsPerChild di 400 è assurdo basso.

    La media del carico è molto elevata – ma 60k di visualizzazioni di pagina al giorno non è molto traffico.

    quanti processi normalmente avete richieste di servizio?

    Non ho familiarità con Magento ma sembra che c'è qualcosa che non va in questa configuration. Mi aspetterei che potresti get una maggiore produttività a un livello di carico inferiore.

    Prendi una copia del libro di Steve Souders e legga. Attiva la compressione per tutti i contenuti HTML in output (statici e dinamici). E assicurati di avere una buona configuration di cache. Avviare la logging di% D nel file access_log e creare alcuni strumenti per analizzare i dati / isolare la lentezza. Simile per MySQL.

    Provare mysqltuner.pl e vedere se segnala eventuali problemi.

    Ho eseguito un'impostazione simile, ma con nginx / php-fpm / apc (opcode e fast_backend / memcached (slow_backend).) Trovo php per essere il problema più grande della risorsa, probabilmente perché il magento è insanamente big o appena codificato male. guarda su cosa esattamente sta mangiando le risorse, potrebbe essere php come nel mio caso?

    Oltre a quello che scrive Martijn Heemels, c'è un module di vernice open source che potresti provare. Check out 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 prova e finora così bene.

    Salvi le sessioni nel database o sul disco (e, in caso affermativo, su tmpfs)?

    Quando si utilizza VPS stai condividendo la CPU. Vi consiglio di parlare con il tuo host per spostare il VPS in un hardware less occupato o andare dedicato.

    A causa della CPU condivisa le tue applicazioni non sono in grado di eseguire in tempo e continuano ad essere in coda, creando richieste più elevate da elaborare e anche le spese generali che vengono con esso. Alla fine c'è una condizione in cui Apache o php o mysql avrebbero messo a punto i propri limiti e quelli causano problemi.

    Bottomline è. VPS è fondamentalmente condivisa dalla CPU. Il tuo host può mettere troppi account VPS sulla stessa CPU.

    Se vuoi sfruttare appieno la CPU allocata o chiedere un server migliore con less VPS se ansible (spostare l'host anche se è difficile) o andare dedicato.

    Potresti anche scegliere Amazon completamente e non preoccuparti di nginx utilizzando il loro bilanciere del carico che è pochi clic per impostare per tutti i tuoi server sotto la loro nuvola.

    la cartella /var/mail…/root è tinta significa raccogliere molte email provenienti dalle tue applicazioni in genere. Per esempio uno script php buggy sta cercando di submit e-mail o tutti i lavori di cron sono configurati per submit via email lo stato delle esecuzioni di 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 where viene.

    Io aggiungerò di più se hai bisogno di ulteriori informazioni e potrebbe essere bisogno di alcune informazioni troppo

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