# Rails, Passenger e VMSize **URL:** \ **Category:** IT\ **Created:** [May 16, 2011, 11:09am UTC](https://www.ruby-forum.com/t/rails-passenger-e-vmsize/207016 "2011-05-16T11:09:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [May 16, 2011, 11:09am UTC](https://www.ruby-forum.com/t/rails-passenger-e-vmsize/207016/1 "2011-05-16T11:09:41Z")
Salve lista, Versione breve: Come posso abbassare il footprint di memoria di un’applicazione Rails? Se ci sono delle best pratice, e da cosa dipende l’uso di memoria: quantit di modelli, quantit di query… Versione lunga: sto lavorando da qualche mese ad un progetto Rails che gira in produzione in questo ambiente: - VPS OpenVZ - Linux Gentoo - Ruby 1.8.7 (2010-01-10 patchlevel 249) - Apache 2.2.4 MPM worker - Passenger 2.2.15 smart-lv2 - Rails 2.3-stable - Rails plugin e gem a pacchi, molte da git, tra cui prawn, formtastic, activescaffold, rubyvis, rmagick, paperclip, class-table-inheritance, cancan, breadcrumbs\_on\_rails, delocalize, globalize2, render\_component … Da un po’ di tempo ad intervalli variabili da 2-4 ore a 2-4 giorni tutto passenger si ferma, i processi di passenger (ApplicationPool, spawn server, ApplicationSpawner, e workers) sembrano essere OK ma semplicemente non rispondono, esaminando con strace sembrano attendere in read indefinitamente senza fare niente quando ricevono richieste HTTP. Per anni tutto ha funzionato correttamente, mai uno stop di passenger. L’evento scatenante sembra essere stato il passaggio da ruby 1.8.6 a 1.8.7 oppure il fatto che ho messo in produzione l’applicazione di cui sopra che da passenger-memory-stats dice di occupare tantissimo: VMSize=196.7 MB Private=150.8 MB Tantissimo visto che Redmine dice di occupare meno della met. Non sembra essere un problema di risorse esaurite perch il VPS segnala che i limiti non vengono raggiunti. Facendo dei test con ab2 tutto risponde bene ad un accettabile livello di performance sul tempo di risposta e sulla concorrenza. Ormai ho rinunciato a capire perch Passenger smette di rispondere ed ho messo nagios a controllare e riavviare. Il supporto di passenger sembra segnalare tantissimi utenti che hanno problemi simili senza soluzione Domande: 1- Avete applicazioni che occupano cos tanto? 2- Sapete come ridurne il footprint? 3- Avete passenger che si riavviano cos spesso? Grazie, Antonio B. ---
**Author:** ![worzeel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/f4b2a3/32.png) [@worzeel](https://www.ruby-forum.com/u/worzeel)\ **Post date:** [May 16, 2011, 12:26pm UTC](https://www.ruby-forum.com/t/rails-passenger-e-vmsize/207016/2 "2011-05-16T12:26:58Z")
2011/5/16 Antonio B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > Domande: > 1- Avete applicazioni che occupano cos tanto? Si, decisamente. 200M non sono necessariamente tanti, e la valutazione se sia tanto o poco dipende da quanta memoria hai / quanti worker passenger. Se hai una footprint di 200M, 8 processi e 4G la memoria non e’ un problema. > 2- Sapete come ridurne il footprint? Profilando l’occupazione di memoria, cerca rails memory profiling. Anche se non e’ necessariamente un problema, in linea di massima ridurre la footprint e’ meglio, dato che meno memoria occupi piu’ le risposte saranno veloci, per via della vituperata garbage collection di ruby. > 3- Avete passenger che si riavviano cos spesso? Da come dici, non sembra che si riavviino, sembra piuttosto che si blocchino il che e’ molto diverso! se sei su apache, potresti provare a giocare con la direttiva PassengerMaxRequests ([Phusion Passenger users guide, Apache version](http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerMaxRequests)) che fa si che i singoli worker vengano riavviati dopo n richieste. Parti con 50, se il problema non si presenta piu’ vuol dire che sono i singoli processi che si impicciano, se invece si presenta ancora vuol dire che e’ passenger stesso, ovvero il processo responsabile di gestire i worker. In quel caso puoi provare ad aggiornarlo, in alcuni casi funziona (in altri peggiora le cose, almeno una volta mi e’ capitato, mentre una versione ancora successiva rimetteva le cose a posto)… anche la direttiva SpawnMethod ha un impatto enorme: il metodo conservativo funziona in piu’ casi, ma se hai parecchio carico il tempo per startare n worker puo’ diventare piu’ di quanto i client sono disposti ad aspettare. Se invece usi nginx, puoi determinare comunque un riavvio dopo n richieste in questo modo: in ApplicationController metti una after filter di questo tipo: after\_filter(:expire\_process) a poi il corrispondente metodo # after\_filter che fa terminare il processo dopo un certo numero di richieste def expire\_process $served\_requests = ($served\_requests || 0) + 1 if $served\_requests \>= REQUEST\_LIMIT\_FOR\_AUTO\_SHUTDOWN # logger.debug “Process #{ Process.pid } ha raggiunto il limite, si manda #{ AUTO\_SHUTDOWN\_SIGNAL }” Process.kill AUTO\_SHUTDOWN\_SIGNAL, Process.pid end end In environment.rb ho definito le due costanti usate: REQUEST\_LIMIT\_FOR\_AUTO\_SHUTDOWN = 50 # In genere e’ USR1 AUTO\_SHUTDOWN\_SIGNAL = :USR1 Ciao ---
**Author:** ![worzeel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/f4b2a3/32.png) [@worzeel](https://www.ruby-forum.com/u/worzeel)\ **Post date:** [May 16, 2011, 12:46pm UTC](https://www.ruby-forum.com/t/rails-passenger-e-vmsize/207016/3 "2011-05-16T12:46:09Z")
Grazie Luca per la risposta dettagliata ed i consigli, Ho: PassengerMaxRequests 20 quindi credo sia un problema di Passenger che smette di funzionare. Aggiornare la versione vorrebbe dire passare alla serie 3.x che da quello che si legge sul loro supporto sembra presentare questi ed altri problemi, anche se prima o poi dovr provare. Tempo fa avevo provato: RailsSpawnMethod conservative ma non cambiava il problema. Il 16/05/2011 12:26, Luca De Marinis ha scritto: ---
**Author:** ![worzeel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/f4b2a3/32.png) [@worzeel](https://www.ruby-forum.com/u/worzeel)\ **Post date:** [May 30, 2011, 6:30pm UTC](https://www.ruby-forum.com/t/rails-passenger-e-vmsize/207016/4 "2011-05-30T18:30:55Z")
> Parti con 50, se il problema non si presenta piu’ vuol dire che sono i > singoli processi che si impicciano, se invece si presenta ancora vuol > dire che e’ passenger stesso, ovvero il processo responsabile di > gestire i worker. In quel caso puoi provare ad aggiornarlo, in alcuni > casi funziona (in altri peggiora le cose, almeno una volta mi e’ > capitato, mentre una versione ancora successiva rimetteva le cose a > posto) > Aggiornato Passenger a 3.0.7 funziona da pi di una settimana e credo > che non si fermer pi: mi tornato a funzionare come facevano le > vecchie versioni di Passenger su Ruby 1.8.6. L’aggiornamento e lo switch tra diverse versioni di Passenger anche molto facile senza compilcarsi la vita con i package manager di sistema: basta installare la versione che si vuole via gem e poi cambiare in Apache il percorso in cui installata la gem. Saluti, Antonio B.