Problemas de interbloqueo en el servidor

Community ES
1

Hola,
Estoy intentando hacer pruebas de escalado con varios clientes en DCoR
(http://rubyforge.org/projects/dconrails/, en el que estamos currando
Juan Lupión y yo), un sistema de computación distribuida que usa RoR.
Y me está dando resultados bastante malos; a partir de 3-4 clientes
prácticamente los tiempos no mejoran. Y me estoy preguntando si habrá
algún problema de interbloqueo de hebras. Mi primera hipótesis es que
puede estar aquí el problema:
http://rubyforge.org/viewvc/app/controllers/algoritmo_controller.rb?revision=32&root=dconrails&view=markup
En concreto, en este cacho de código:
puts “— Poblacion enviada ------------------------”
guys.each do |x|
puts " id: #{x.id} cromosoma: #{x.cromosoma} fitness:
#{x.fitness} status: #{x.status}"
end
puts “----------------------------------------------”
Que escribe directamente en el log de salida, y, al bloquear el uso
del buffer, no es reentrante, por lo que las otras hebras tienen que
esperar a que se desbloquee para escribir en ese mismo fichero.
Pero claro, no tengo ni idea de si eso es así. Lo cierto es que con 5
clientes no se debería de degradar mucho la mejora de prestaciones,
así que debe haber algún cuello de botella en el cliente de este
estilo.

En fin, cualquier cosa que se os ocurra os lo agradezco. Un saludo.

JJ

2

On Jan 11, 2007, at 7:49 AM, JJ Merelo wrote:

Yepa! :slight_smile:

Hola,
Estoy intentando hacer pruebas de escalado con varios clientes en DCoR
(http://rubyforge.org/projects/dconrails/, en el que estamos currando
Juan Lupión y yo), un sistema de computación distribuida que usa RoR.
Y me está dando resultados bastante malos; a partir de 3-4 clientes
prácticamente los tiempos no mejoran. Y me estoy preguntando si habrá
algún problema de interbloqueo de hebras.

Es que corres Rails en modo multi-thread?

– fxn

3

Hola

Estoy intentando hacer pruebas de escalado con varios clientes en DCoR
(http://rubyforge.org/projects/dconrails/, en el que estamos currando
Juan Lupión y yo), un sistema de computación distribuida que usa RoR.
Y me está dando resultados bastante malos; a partir de 3-4 clientes
prácticamente los tiempos no mejoran. Y me estoy preguntando si habrá
algún problema de interbloqueo de hebras.

Es que corres Rails en modo multi-thread?

Bueno, supongo que si. Si no, como contesta a las múltiples peticiones
simultáneas? O hay que hacer algo especial para correrlo en modo
multi-hebra?

Perdonadme, pero estoy un poco pegado…

JJ

4

Hola,

Rails no es thread-safe, por eso el deployment normal de Rails es
multi-proceso. Por ejemplo con multiples FastCGIs, o con
mongrel_cluster balanceado.

Hum. ¿Como se hace eso? ¿Algún enlace?

Mongrel es multi-thread, encola peticiones y por ejemplo puede ir
sirviendo ficheros estaticos si se encarga el, pero las peticiiones
dinamicas a Rails se sirven una a una (por proceso) con un bloqueo
gordo sobre el dispatcher.

Es decir, ¿hasta que no se sirve una petición completa no se pasa a la
siguiente?

Quiza si quitas la hipotesis multi-thread te ayude a depurar el
problema.

Bueno, es que quiero que sea multi-thread, que responda a varias
peticiones simultáneamente. ¿Cómo lo hago?

JJ

5

Hola,
Ya lo estoy viendo:

http://mongrel.rubyforge.org/docs/mongrel_cluster.html

y no es trivial. Me refiero, tendré que echar un rato.

Mongrel es multi-thread, encola peticiones y por ejemplo puede ir
sirviendo ficheros estaticos si se encarga el, pero las peticiiones
dinamicas a Rails se sirven una a una (por proceso) con un bloqueo
gordo sobre el dispatcher.

Es decir, ¿hasta que no se sirve una petición completa no se pasa a la
siguiente?

Vale, y cómo hago para decirle que arranque, por ejemplo, 5 procesos
de principio? Se puede hacer por las buenas, o hace falta el
mongrel_cluster?

Bueno, ya miro la página de manual. Gracias. Y no hay ningún servidor
alternativo multihebra, o que arranque múltiples workers, como el
Apache?

JJ

6

On Jan 11, 2007, at 11:56 AM, JJ Merelo wrote:

habrá
algún problema de interbloqueo de hebras.

Es que corres Rails en modo multi-thread?

Bueno, supongo que si. Si no, como contesta a las múltiples peticiones
simultáneas? O hay que hacer algo especial para correrlo en modo
multi-hebra?

Rails no es thread-safe, por eso el deployment normal de Rails es
multi-proceso. Por ejemplo con multiples FastCGIs, o con
mongrel_cluster balanceado.

Mongrel es multi-thread, encola peticiones y por ejemplo puede ir
sirviendo ficheros estaticos si se encarga el, pero las peticiiones
dinamicas a Rails se sirven una a una (por proceso) con un bloqueo
gordo sobre el dispatcher.

Quiza si quitas la hipotesis multi-thread te ayude a depurar el
problema.

– fxn

7

Como dice Xavier , rails es single_thread … aunque algunos de sus
componentes como ActiveRecord no tienen porque dar problema si se
utilizan fuera de rails en entornos multi-thread:

config.active_record.allow_concurrency

De cualquier manera lo dicho, cuidadito con estas opciones y con la
utilizacion de entornos multi-thread.

On 1/11/07, Xavier N. [email protected] wrote:

Y me está dando resultados bastante malos; a partir de 3-4 clientes
Rails no es thread-safe, por eso el deployment normal de Rails es

– fxn

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Un saludo,
Aitor Garcia
bloggin’ : http://www.finiscoronatopus.com
tumblin’ : http://tumble.finiscoronatopus.com
monkin’ : http://www.viralmonkeys.com
questin’ : http://www.orthonauts.com

8

Hola,

Bueno, ya miro la página de manual. Gracias. Y no hay ningún servidor
alternativo multihebra, o que arranque múltiples workers, como el
Apache?

Perdón, me corrijo a mi mismo: ya entiendo que Mongrel es multihebra,
pero que hay una sola cola de peticiones, y por lo tanto es secuencial
sirviendo la petición. ¿No habría forma simple de que arrancara
múltiples procesos?

En fin, si no hay otra cosa, intentaremos mongrel_cluster. O disminuir
el tiempo que tardan en servirse las peticiones en el servidor.

JJ

9

Gracias por las instrucciones detalladas. Lo intentaré…
másadelante. E informaré del resultado. Por lo pronto, trataré de
toquetear un poco el mongrel y el código para que los bloqueos no
duren mucho.

JJ

10

On Jan 11, 2007, at 12:06 PM, JJ Merelo wrote:

Hola,

Rails no es thread-safe, por eso el deployment normal de Rails es
multi-proceso. Por ejemplo con multiples FastCGIs, o con
mongrel_cluster balanceado.

Hum. ¿Como se hace eso? ¿Algún enlace?

Es sencillote con Apache 2.2.3 o superior. Lo compilas con
mod_proxy_balancer:

./configure
–enable-proxy
–enable-proxy-balancer
–enable-proxy-http
–enable-rewrite
–enable-cache
–enable-headers
–enable-ssl
–enable-info

Metes un config/mongrel_cluster.yml con esta pinta

port: “3001”
environment: development
address: 127.0.0.1
pid_file: log/mongrel.pid
servers: 3

que configura tres servidores con puertos 3001, 3002, 3003 (no se que
pasa si uno de ellos esta ocupado). Mongrel puede invocarse para que
genere ese YAML a partir de opciones en linea de comandos, pero al
final es eso. Quien pone 3 puede poner 7, eso ya ves un poco. Como
sabes en modo produccion la cosa va mucho mas rapida.

Y configuras Apache como va abajo, han de casar los puertos Mongrel
con los que se configuran en el balanceador. Una vez hecho eso lanzas
Apache y en la aplicacion ejecutas

mongrel_rails cluster::start

Tienes tambien comandos “cluster::stop”, “cluster::restart”. El
balanceador y Mongrel se repescan solos, no hay dependencia en el
lanzamiento. En particular puedes tirar y arrancar Mongrel de nuevo
sin tocar Apache.

– fxn

This is the recommend MIME type according to http://

Favicon - Wikipedia.
AddType image/vnd.microsoft.icon .ico

Configure the balancer to dispatch to the Mongrel cluster.

<Proxy balancer://example_cluster>
BalancerMember http://127.0.0.1:3001
BalancerMember http://127.0.0.1:3002
BalancerMember http://127.0.0.1:3003

Setup the VirtualHost for your Rails application

NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin [email protected]
ServerName www.example.com
ServerAlias localhost

Not supported on Mac OS X.

EnableSendfile On

DocumentRoot /home/oper/www/public
<Directory ‘/home/oper/www/public’>
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all

ProxyPass /images !
ProxyPass /stylesheets !
ProxyPass /javascripts !
ProxyPass /favicon.ico !
ProxyPass /system !
ProxyPass / balancer://example_cluster/
ProxyPassReverse / balancer://example_cluster/

Setup your Rewrite rules here

RewriteEngine On

This rewrites all requests to /system/maintenance.html if that

file exists, this file is created by Capistrano’s disable task.

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /system/maintenance.html [L]

Deflate

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/
css application/x-javascript

Error logs

ErrorLog /home/oper/www/log/apache_error_log
CustomLog /home/oper/www/log/apache_access_log combined

11

On 1/11/07, Juan Lupión [email protected] wrote:

Aquí hablan del problema del multithread con Rails:

http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads

“Then another dynamic content request can go ahead and chaos ensues
(ouch). This often manifests as a lost connection to mysql server
during query message.”

¿No era este uno de lso mensajes de error que daba Mongrel?

Al principio, puede ser, pero ya uso todo el tiempo mongrel, no WEBrick.

JJ

12

Aquí hablan del problema del multithread con Rails:

http://wiki.rubyonrails.org/rails/pages/HowTosWorkerThreads

“Then another dynamic content request can go ahead and chaos ensues
(ouch). This often manifests as a lost connection to mysql server
during query message.”

¿No era este uno de lso mensajes de error que daba Mongrel?

13

Estoy empezando a usar mongrel_cluster, y no hace falta configurar
gran cosa: simplemente el número de procesos que quieres lanzar y
listo. Aparentemente, está dando buen resultado, pero tendré que hacer
medidas más exactas… Y está el problema del bloqueo del fichero de
salida, que fue el que planteé inicialmente. Voy a ver si soluciono
eso también.

JJ