Come posso spegnere con garbo un server web Mongrel

Question

La mia app RubyOnRails è configurata con il solito pacchetto di bastardi dietro la configurazione di Apache.Abbiamo notato che l'utilizzo della memoria del nostro server web Mongrel può aumentare notevolmente in determinate operazioni e ci piacerebbe davvero essere in grado di eseguire dinamicamente un riavvio graduale dei processi Mongrel selezionati in qualsiasi momento.

Tuttavia, per ragioni che non entrerò qui, a volte può esserlo molto È importante non interrompere un Mongrel mentre sta soddisfacendo una richiesta, quindi presumo che un semplice processo kill non sia la risposta.

Idealmente, voglio inviare al Mongrel un segnale che dice "finisci quello che stai facendo e poi esci prima di accettare altre connessioni".

Esiste una tecnica standard o una best practice per questo?

Answer 1

Ho effettuato ulteriori indagini sul sorgente Mongrel e ho scoperto che Mongrel installa un gestore di segnale per rilevare un processo standard kill (TERM) ed eseguire uno spegnimento regolare, quindi dopo tutto non ho bisogno di una procedura speciale.

Puoi vedere che funziona dall'output del registro che ottieni quando uccidi un Mongrel mentre sta elaborando una richiesta.Per esempio:

** TERM signal received.
Thu Aug 28 00:52:35 +0000 2008: Reaping 2 threads for slow workers because of 'shutdown'
Waiting for 2 requests to finish, could take 60 seconds.Thu Aug 28 00:52:41 +0000 2008: Reaping 2 threads for slow workers because of 'shutdown'
Waiting for 2 requests to finish, could take 60 seconds.Thu Aug 28 00:52:43 +0000 2008 (13051) Rendering layoutfalsecontent_typetext/htmlactionindex within layouts/application

Answer 2

Guarda come usare monit.Puoi riavviare dinamicamente Mongrel in base all'utilizzo della memoria o della CPU.Ecco una riga da un file di configurazione che ho scritto per uno dei miei clienti.

check process mongrel-8000 with pidfile /var/www/apps/fooapp/current/tmp/pids/mongrel.8000.pid
    start program = "/usr/local/bin/mongrel_rails cluster::start --only 8000"
    stop program = "/usr/local/bin/mongrel_rails cluster::stop --only 8000"

    if totalmem is greater than 150.0 MB for 5 cycles then restart       # eating up memory?
    if cpu is greater than 50% for 8 cycles then alert                  # send an email to admin
    if cpu is greater than 80% for 5 cycles then restart                # hung process?
    if loadavg(5min) greater than 10 for 3 cycles then restart          # bad, bad, bad
    if 3 restarts within 5 cycles then timeout                         # something is wrong, call the sys-admin

    if failed host 192.168.106.53 port 8000 protocol http request /monit_stub
        with timeout 10 seconds
        then restart
    group mongrel

Dovresti quindi ripetere questa configurazione per tutte le istanze del tuo cluster bastardo.La riga monit_stub è solo un file vuoto che monit tenta di scaricare.In caso contrario, tenta anche di riavviare l'istanza.

Nota:il monitoraggio delle risorse sembra non funzionare su OS X con il kernel Darwin.

Answer 3

La domanda migliore è come evitare che la tua app consumi così tanta memoria da richiedere il riavvio di bastardi di tanto in tanto.

www.modrails.com ha ridotto significativamente la nostra occupazione di memoria

Answer 4

Paludoso:

Se hai un processo in esecuzione, si spegnerà normalmente (soddisfa tutte le richieste nella sua coda che dovrebbero essere solo 1 se stai utilizzando il corretto bilanciamento del carico).Il problema è che non puoi avviare il nuovo server finché quello vecchio non muore, quindi i tuoi utenti si metteranno in coda nel bilanciatore del carico.Ciò che ho riscontrato con successo è un riavvio "a cascata" o progressivo dei bastardi.Invece di fermarli tutti e avviarli tutti (quindi mettere in coda le richieste finché un bastardo non viene terminato, arrestato, riavviato e accettato le connessioni), è possibile interrompere e avviare ciascun bastardo in sequenza, bloccando la chiamata per riavviare il bastardo successivo finché non viene terminato quello precedente. eseguire il backup (utilizzare un vero controllo HTTP su un controller /status).Man mano che i tuoi bastardi rotolano, solo uno alla volta è inattivo e stai servendo su due basi di codice: se non puoi farlo dovresti aprire una pagina di manutenzione per un minuto.Dovresti essere in grado di automatizzarlo con capistrano o qualunque sia il tuo strumento di distribuzione.

Quindi ho 3 compiti:cap:deploy - che esegue il tradizionale metodo di riavvio tutto allo stesso tempo con un hook che apre una pagina di manutenzione e poi la rimuove dopo un controllo HTTP.cap:deploy:rolling - che fa questo effetto a cascata su tutta la macchina (prendo da un iClassify per sapere quanti bastardi ci sono su una determinata macchina) senza una pagina di manutenzione.cap deploy:migrations - che fa la pagina di manutenzione + le migrazioni poiché di solito è una cattiva idea eseguire le migrazioni "dal vivo".

Answer 5

Prova a utilizzare:

mongrel_cluster_ctl stop

Puoi anche usare:

mongrel_cluster_ctl restart

Answer 6

ho una domanda

cosa succede quando viene attivato /usr/local/bin/mongrel_rails cluster::start --only 8000?

tutte le richieste vengono soddisfatte da questo particolare processo, fino alla fine?oppure vengono interrotti?

Sono curioso di sapere se tutta questa faccenda di avvio/riavvio può essere eseguita senza influenzare gli utenti finali...