Re: Consumo de memoria con dispatch.fcgi

Community ES
1

La verdad es que yo tengo la misma duda, pero no sé si la carga sea
causada
por el dispatch o por typo.

Una sugerencia que me hicieron los del hosting fue hacer un cronjob para
estar matando el proceso diariamente por ejemplo. (pkill -9
dispatch.fcgi)

Agradeceríamos una respuesta a nuestra duda :stuck_out_tongue: Gracias.

---------- Forwarded message ----------

Gracias

Emili Parreño
www.eparreno.com

–

edgar.js

2

Yo tambien tengo el mismo problema, hay un querie que ejecuto contra una
base de datos en Oracle, mientras que en mongrel funciona bien en Apache
no.
Debido a que el sql hace un recorrido por una tabla de 4 millones de
registros, el tiempo requerido es mucho y en Apache se cuelga el Rails.
He
intentado aumentar el tiempo del dispatch.fcgi en el archivo de
configuración, pero igual da problemas.

El día 22/10/07, edgar. js [email protected] escribió:

3

On Mon, Oct 22, 2007 at 09:45:03PM -0400, Werner E. wrote:

Yo tambien tengo el mismo problema, hay un querie que ejecuto contra una
base de datos en Oracle, mientras que en mongrel funciona bien en Apache no.
Debido a que el sql hace un recorrido por una tabla de 4 millones de
registros, el tiempo requerido es mucho y en Apache se cuelga el Rails. He
intentado aumentar el tiempo del dispatch.fcgi en el archivo de
configuración, pero igual da problemas.

Yo, tras múltiples problemas y dolores de cabeza, abandoné apache+fcgi
por apache+mongrel[1]. Y, por el momento, no tengo quejas.

En cuanto a typo, es verdad que consume un montón de memoria. De hecho,
estoy pensando en cambiarlo, porque tengo ciertas limitaciones de
hardware y esa voracidad me está causando algunos problemas :stuck_out_tongue:

Saludos.

[1] http://mongrel.rubyforge.org/

–
Imobach González Sosa
Banot.net
imobachgs en banot punto net

4

Andrés gutiérrez
escribió:> Dos dudas, perdon por la intromisión. ¿Qué es typo? y ¿Cómo se pueden

mezclar dos servidores (Apache + Mongrel) ?
Un saludo

typo [1] es un blog desarrollado en rails, como ya han comentado,
nosotros lo probamos y daba la sensacion de
no ser muy rapido, ahora estamos probando mephisto [2] y tira muy bien,
aunque no tiene las mismas prestaciones.

Sobre lo de los servidores puedes tener varios mongrel y hacer que
apache haga de proxy de ellos [3] y [4]

Un saludo

[1] http://typosphere.org/
[2] http://mephistoblog.com/
[3] http://mongrel.rubyforge.org/docs/apache.html
[4]
http://blog.innerewut.de/2006/04/21/scaling-rails-with-apache-2-2-mod_proxy_balancer-and-mongrel

5

Dos dudas, perdon por la intromisión. ¿Qué es typo? y ¿Cómo se pueden
mezclar dos servidores (Apache + Mongrel) ?
Un saludo

El día 23/10/07, Imobach González Sosa [email protected] escribió:

6

Muchas gracias por las aclaraciones. Desde luego esta lista funciona muy
bien.

Gracias de nuevo CartuchoGL

El día 23/10/07, cartuchoGL [email protected] escribió:

7

Hola,

Por si os sirve de algo, en cuanto a blogs hechos en RoR se refiere, yo
me he decantado por uno que no es muy conocido, pero a mí me va de lujo.
Se llama Simplelog [1] y lo estoy usando actualmente [2] con
pequeñas modificaciones y un theme propio inspirado en uno de los que ya
hay creados y listos para usar [3].
No me ha parecido que consuma demasiado (nginx+mongrel), y se le ve muy
liviano.

Además es bastante sencillo “meterle mano” para cambiar alguna cosilla y
adaptarlo completamente a tu gusto. Aunque sí os digo que carece de cosas
como “pingback”, “trackback”, etc. Pero se puede vivir sin eso :wink:

Y a todo esto, aunque llevo meses en la lista, es mi primer mensaje. He
aprendido, y sigo aprendiendo mucho, gracias a todos vosotros. Seguiré por
aquí. Un saludo!

[1] http://simplelog.net/
[2] http://blog.keevu.com/
[3] http://wiki.simplelog.net/Themes/Public

–
Jesús Láiz

De: [email protected]
[mailto:[email protected]] En nombre de Andrés gutiérrez
Enviado el: martes, 23 de octubre de 2007 17:27
Para: La lista sobre Ruby On Rails (rubyonrails.com) en castellano
Asunto: Re: [Ror-es] Consumo de memoria con dispatch.fcgi

Muchas gracias por las aclaraciones. Desde luego esta lista funciona muy
bien.

Gracias de nuevo CartuchoGL
El día 23/10/07, cartuchoGL [email protected]
escribió:Andrés gutiérrez
escribió:> Dos dudas, perdon por la intromisión. ¿Qué es typo? y ¿Cómo se pueden

mezclar dos servidores (Apache + Mongrel) ?
Un saludo

typo [1] es un blog desarrollado en rails, como ya han comentado,
nosotros lo probamos y daba la sensacion de
no ser muy rapido, ahora estamos probando mephisto [2] y tira muy bien,
aunque no tiene las mismas prestaciones.

Sobre lo de los servidores puedes tener varios mongrel y hacer que
apache haga de proxy de ellos [3] y [4]

Un saludo

[1] http://typosphere.org/
[2] http://mephistoblog.com/
[3] http://mongrel.rubyforge.org/docs/apache.html
[4]
http://blog.innerewut.de/2006/04/21/scaling-rails-with-apache-2-2-mod_proxy_balancer-and-mongrel

8

Emili Parreño escribió:

Yo tengo claro que el quid de la cuestión está en configurar bien el
mod_fastcgi, cómo no lo sé. He probado alguna opción pero sigo en las
mismas. Se va comiendo la memoria y lo peor es que no se recupera o
tarda muchísimo.

Creo que si no encuentro una solución rápida voy a optar por instalar
Mongrel (del que todo el mundo habla muy bien) y que Apache haga de
proxy redireccionando las peticiones a otro puerto mediante un archivo
htaccess.

Una solución que se usa en servidores como DH es matar el proceso 1 vez
a la semana (depende de lo rápido que se coma la memoria) con un script
y cron.

Aun así si tienes oportunidad de usar apache+mongrel es mejor opción.

Saludos

9

Buen día. Tengo similares problemas en el hosting que utilizo, DH[1].
Más
que nada con el uploading de imágenes, en el proceso que hace Rmagick
para
cambiar de tamaño las imágenes. He configurado el .htaccess[2] y el
dispatch.fcgi de diversas formas para que corra bien la aplicación y me
he
quedado en esta última configuración [3]. Como recomendación en
hostings,
utilizar un usuario por aplicación porque sino cada vez que se matan los
procesos caen todas las aplicaciones.

Así como está ahora, el aplicativo corre rápido. Pero estoy probando
otras
configuraciones para que no caiga el proceso de Rmagick. He buscado
bastante información y parece que nadie de DH tiene problemas con
Rmagick o
no lo utiliza. Igualmente me queda la duda de que sea DH el que mata el
proceso al superar X recursos y no el fcgi. En ese caso reemplazaré la
utilidad por el gem ImageScience[4] que es más liviano. Pero antes voy
a
probar este script [5] relativo a las fugas de memoria.

En cuanto a blogs en hostings, ví bastantes solicitudes en el foro de
DH[6].

Quizás algo de mis problemas sean soluciones para otros :stuck_out_tongue:

Un Saludo!,
Dario Brozzi
http://www.dariobrozzi.com.ar/

[1] http://www.dreamhost.com/

[2]
AddHandler fastcgi-script .fcgi
Options +FollowSymLinks +ExecCGI
RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

[3] → Ruby on Rails Dreamhost plugin | Todd Huss

#!/usr/bin/ruby1.8

require File.dirname(FILE) + “/…/config/environment”
require ‘fcgi_handler’

class RailsFCGIHandler
private
def busy_exit_handler(signal)
dispatcher_log :info, “busy: asked to terminate during request signal
#{signal}, deferring!”
@when_ready = :exit
end

Dreamhost sends the term signal and if we’re handling a request defer

it
def term_process_request(cgi)
install_signal_handler(‘TERM’,method(:busy_exit_handler).to_proc)
Dispatcher.dispatch(cgi)
rescue Exception => e # errors from CGI dispatch
raise if SignalException === e
dispatcher_error(e)
ensure
install_signal_handler(‘TERM’, method(:exit_now_handler).to_proc)
end
alias_method :process_request, :term_process_request
end

RailsFCGIHandler.process !

[4] http://seattlerb.rubyforge.org/ImageScience.html

[5]

[6] http://discussion.dreamhost.com/

10

Yo tengo claro que el quid de la cuestión está en configurar bien el
mod_fastcgi, cómo no lo sé. He probado alguna opción pero sigo en las
mismas. Se va comiendo la memoria y lo peor es que no se recupera o
tarda muchísimo.

Creo que si no encuentro una solución rápida voy a optar por instalar
Mongrel (del que todo el mundo habla muy bien) y que Apache haga de
proxy redireccionando las peticiones a otro puerto mediante un archivo
htaccess.