Posts marcats amb performance
Accelerar el temps de càrrega de les aplicacions RubyOnRails
Mar 23
A vegades quan accedim a una aplicació RubyOnRails notem que la primera petició triga molt i després ja va més fluït. Això passa perquè a la primera connexió el Passenger ha de carregar l’aplicació en memòria, quan es deixen de rebre peticions durant un cert temps, el Passenger la descarrega i a la següent petició caldrà tornar a aixecar-la.
Podem evitar aquesta espera si mantenim sempre una o més instàncies de l’aplicació aixecades. Passenger ens permet configurar-ho amb el paràmetre PassengerMinInstances
PassengerPoolIdleTime 10
<VirtualHost *:80>
ServerName foobar.com
DocumentRoot /webapps/foobar/public
PassengerMinInstances 3
</VirtualHost>
amb aquesta configuració tindrem com a mínim sempre tres instàncies aixecades per servir peticions, excepte quan acabem d’engegar l’Apache, ja que per defecte el Passenger no carregarà les instàncies. Podem fer que es carreguin a l’engegar l’Apache amb PassengerPreStart:
PassengerPoolIdleTime 10
<VirtualHost *:80>
ServerName foobar.com
DocumentRoot /webapps/foobar/public
PassengerMinInstances 3
</VirtualHost>
PassengerPreStart http://foobar.com/
Així en arrencar l’Apache es farà una petició a la URL indicada i es carregaran les instàncies de Passenger.
Al comprovar la nova configuració, ens surt aquest error:
Syntax error on line 4 of /etc/apache2/sites-enabled/foobar.com.conf:
Invalid command 'PassengerMinInstances', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.
és perquè la versió de Passenger que porta Debian Squeeze (2.2.11debian), encara no suporta PassengerMinInstances, desinstal·lem el paquet libapache2-mod-passenger i instal·lem el Passenger amb Rubygems:
<IfModule mod_passenger.c>
PassengerRoot /var/lib/gems/1.8/gems/passenger-3.0.11
PassengerRuby /usr/bin/ruby1.8
</IfModule>
LoadModule passenger_module /var/lib/gems/1.8/gems/passenger-3.0.11/ext/apache2/mod_passenger.so
[root@webserver ~]# /etc/init.d/apache2 restart
Optimitzar Munin amb tmpfs
Oct 24
Al servidor on allotgem les webs, l’Apache cada vegada anava més lent.
Un apachectl fullstatus
ens mostrava molts workers en estat L (“Logging”) esperant obtenir accés a disc.
Vam descobrir que el problema era el Munin, a mida que havíem anat afegint nodes i gràfiques, el rendiment havia anat baixant. Cada node té unes 80 bases de dades RRD, depenent del nombre de gràfiques; si monitoritzem uns 50 nodes, són uns 4000 fitxers RRD a actualitzar cada 5 minuts i l’accés a disc comença a ser un problema.
Per solucionar-ho vam moure les bases de dades a la memòria RAM
a la gràfica es veu clarament com va desaparèixer l’espera per accedir al disc (iowait)
Configurar munin + tmpfs
per reduir l’espai usat, no esta de més esborrar els RRD antics que ja no s’utilitzin
# du -sh /var/lib/munin
305M /var/lib/munin
fem una còpia de la carpeta
afegim a /etc/fstab una partició tmpfs prou gran per posar-hi /var/lib/munin i amb l’uid i gid de l’usuari munin
la muntem i hi copiem les dades
# mount /var/lib/munin
# cp -ra /var/lib/munin-cache/* /var/lib/munin/
ara tenim les bases de dades RRD a la RAM, l’accés a disc ja no hauria de ser un problema, però si s’apaga el servidor es perden les dades de la RAM, per tant cal programar un cron que vagi copiant les dades a disc
posem a /etc/cron.hourly/munin-cache
# hem posat /var/lib/munin a la RAM, cal copiar-ho a /var/lib/munin-cache
# per no perdre les dades en cas de reiniciar.
cp -ra /var/lib/munin/* /var/lib/munin-cache/
i ho fem executable
per que es restauri automàticament la còpia a l’engegar, afegim a /etc/rc.local