Dreamhost, PHP y consumo de CPU: Round 2
Publicado el Viernes 09 de Febrero del 2007 @ 18:35 por Armonth.
- 43
- 9
Comentar
Los que llevéis un tiempo leyendo blogs recordareis una polémica que hubo a finales del 2005 cuando varios usuarios experimentaron problemas con Dreamhost por culpa del consumo de CPU:
Historia previa
- Boja inició la discusión.
- Muchos blogs se hicieron eco (1, 2, 3, etcétera).
- Ricardo Galli indicó que el problema es usar PHP como CGI.
- Y los problemas se arreglaron y se aprendieron algunas lecciones por el camino.
Pues bien, recientemente tuvimos un Round 2 en el que Boja volvió a tener problemas de CPU (ya tiene mala suerte xD).
Round 2: Desaparición de mod_php
Boja realizando unas pruebas puso La Maté por un Yogur como PHP 5.x (el cual sólo está como CGI) y cuando quiso volver a poner mod_php se encontró que la opción ya no existía.
Aunque hay formas de forzar el uso de mod_php pueden generar problemas, así pues veamos qué ha pasado.
Según parece, la solución de usar mod_php es muy buena: En lugar de optimizar al máximo los sitios y evitar fallos que consumen mucho los usuarios pasaban de CGI a mod_php para evitar ser detectados por eso aumentaban los problemas en los servidores.
Al final, Dreamhost decidió que los nuevos dominios no tuvieran la opción de elegir mod_php. A los que nos ha pillado con el dominio ya registrado se nos mantiene la opción de usar mod_php.
Los dos principales motivos para elegir CGI según Dreamhost son:
- Con mod_php no se puede monitorizar cuánto consume cada usuario, por lo que no se puede evitar que abusen de la CPU.
- Mayor seguridad: Con CGI ejecutas PHP con tu usuario en lugar de con el usuario de Apache.
¿Significa eso que sitios de tamaño medio no pueden usar Dreamhost? No, solamente hay que ver de qué modo está pensado: CGI para los usuarios con poco tráfico (== poco consumo de CPU) y FastCGI para los que tenemos un tráfico decente.
¿FastCGI?
FastCGI es una extensión abierta al CGI tradicional que como principal novedad mantiene en el servidor un único proceso persistente por cada programa FastCGI.
Recordemos que con CGI cada petición (cada visita) hace que Apache ejecute un fork+exec al PHP, es decir, ejecuta PHP cada vez que llega una visita.
Con FastCGI mantenemos un único proceso, es casi como tener PHP ejecutandose como módulo de Apache. De media puedes esperar un consumo de 4 a 8 veces menor si lo comparamos con CGI.
Repito que no es mejor que mod_php pero no es mala opción aunque los CGI hoy en día tengan mala prensa, como curiosidad estuve haciendo pruebas con un conocido usando lighttpd+PHP 4.3 FastCGI y me gusto mucho el rendimiento — pero ése no es el caso ahora –.
Por último, algunos scripts no son compatibles con FastCGI.
Me has convencido ¿cómo lo instalo?
Siguiendo las instrucciones que dá Dreamhost:
Primero debemos ir al Panel de administración para elegir usar PHP 5 y activar soporte de FastCGI. Tiene que ser PHP5, según ellos PHP4 no funciona con FastCGI.
Podemos tener un subdominio con FastCGI y seguir usando el dominio con otra cosa, los cambios se aplican desde donde activas FCGI hacía abajo.
Luego tenemos que hacer un wrapper que cuando se reciba una petición la envíe al php5.cgi en memoria. Para ello vamos al directorio de nuestro dominio (para el ejemplo, fcgi.test.tld) y crearemos un fichero php5-wrapper.fcgi:
cd $HOME/fcgi.test.tld
cat > php5-wrapper.fcgi << "EOF"
#!/bin/bash
export PHP_FCGI_CHILDREN=3
exec /dh/cgi-system/php5.cgi
EOF
chmod u+x php5-wrapper.fcgi
El cat crea el fichero php5-wrapper.fcgi con las líneas que hay hasta el EOF. PHP_FCGI_CHILDREN es el número de procesos “hijo” a ejecutar, para la mayoría un valor de 3 es suficiente.
Opcionalmente: La ruta puesta en exec es un enlace al fichero php5.cgi, algunos servidores de Dreamhost no tienen dicho enlace por lo que debemos hacer un locate php5.cgi para encontrar el ejecutable y poner la ruta correcta.
Por último solamente tenemos que añadir en el mismo sitio que donde está en php5-wrapper.fcgi un fichero .htaccess (sirve el creado por WordPress) poniendo al principio del todo lo siguiente:
Options +ExecCGI
AddHandler fastcgi-script fcg fcgi fpl
AddHandler php5-fastcgi .php
Action php5-fastcgi /php5-wrapper.fcgi
Ahora debemos visitar el sitio por web y al hacerlo si ejecutamos ps aux deberíamos ver 3 procesos /dh/cgi-system/php5.cgi ejecutandose, si todo va bien ya está funcionando.
Comprobando que funciona y consume menos
Toca esperar 24 horas hasta aproximadamente las 5 de la tarde para que se genere un nuevo informe en $HOME/logs/resources/ ahí deberíamos ver el php5.cgi y su consumo.
Aseguraos de que son 24h enteras (si hace falta esperad 48h para ver el último informe) con FCGI activado que se puede mezclar consumo de antes de FCGI y de después sobretodo si ya usabas php5.
Problemas típicos
Lo peor que te puede pasar es que te de un Error 500, asegurate de los siguientes puntos:
Tus ficheros PHP, CGI y FCGI no tienen permisos de escritura para todo el mundo:
chmod o-w *.php *.cgi *.fcgi- El nombre del fichero debe ser php5-wrapper.fcgi, de lo contrario los procesos seran matados (¡ugh!, ¡que cruel! :P) al momento.
Nada, esto no tira
¡A Boja le paso! (lo dicho: tiene mala suerte xD). Mismos pasos que yo en el Planet Webdev (que sí usa FCGI) y no le funcionaba, para desactivar FCGI solamente hace falta que borres o comentes las 4 líneas añadidas al htaccess.
Si siguiendo los pasos no te funciona o al hacer el ps aux te aparece el php5.cgi pero con un <defunct> al lado es que algo en el servidor no está bien.
Resumiendo
- Si usas mod_php no lo toques.
- Si usas CGI y tienes poco consumo (pongamos de referencia 2000 segundos) o no te dan ningún toque no te preocupes.
- Si consumes mucho con CGI prueba FCGI.
43 Comentarios
-
InKiLiNo:
Estupendo documento, me ha encantado, pero una pregunta como compruebo que tengo mod_php, creo que si pero me gustaría asegurarme.
-
Armonth:
Manage Domains -> El botón “Edit” en el dominio a revisar… si te sale php 4.4.2, 5.x y mod_php es que lo tienes…
-
Me sale esto.
Tendria que marcar Fast CGI o no? Estoy con php4
-
corsaria:
Uhmmm parece que no lo tienes Inkilino. :)
-
No, no tienes mod_php Inki… si tu consumo es alto (ver resumen) prueba FCGI ;)
-
Define consumo alto.
Si no me equivoco creo que en dreamhost me marca 20Gb
-
… inkilino hoy andas un poco “pez” ¿eh? ;-) … consumo de CPU eso se mira en $HOME/logs/resources y antes estaba limitado a 40 minutos (2400 seg) al día… ahora no hay limitación oficial pero te dan toques si te pasas mucho…
-
Es que creo que me enviaron un mail diciendome eso, pero como esta en inglés :(
Esto es un fragmento:
I’m writing to let you know that your domain inkilino.com was getting too
many hits and consequently kept crashing the shared apache service. I set
a restriction on the domain: it can receive 50 connections in 5 seconds
which resets every 5 seconds. This is to bring down the load on your
server, but still leave your site operational.Perdona que te moleste tanto, pero se que a ti esto te mola ;)
-
Mas que molar creo que le encanta. Armonth for betatester official of Dreamhost. ;-)
-
Inkilino lo que dice ese email no es por CPU: es por número de conexiones, que te restringen el número de conexiones a 50 cada 5 segundo y reseteando cada 5 segundos, que eso balanceara la carga pero mantendrá tu sitio operacional (¿?) ¿qué tráfico tienes para que te pase eso? quizá por eso no te va el ssh (a mí no me ha pasado eso nunca)…
-
fire!:
Lo trato de implementar, pero me da error 500. Hice todo lo que explicas y lo que explica el wiki de dreamhost y no paso nada. No se que puede estar pasando :(.
Una pregunta, ¿Con esto se logra que los scripts, en mi caso Drupal, corran “mas rápido”?
-
Fire, no me hagáis repetir lo que ya he escrito… no funcionan más rápido, solamente se encarga de que el programa se mantenga ininterrumpidamente para que el consumo de CPU baje…
Si te da Error500 es porque o el server no te rule bien con FCGI o algo, las instrucciones son las que son y si no funciona es por server o por el script usado (¿tiene Drupal soporte de FCGI?) y eso ya sobrepasa al artículo…
-
fire!:
Ok Armonth…. Gracias por la ayuda…. y drupal si tiene soporte para FCGI ;) …
-
magarto:
InKiLiNo, seguro que tú los usas :P
Yo en cambio, tenéis que ayudarme para utilizarlo que mi web es un poco nueva :DGracias por el tutorial, no tenía noi idea… me pensaba que ya no llamaban la atención por el consumo de la CPU
-
NOlo:
A mi ya me han cambiado 2 veces de servidor en dreamhost por consumo de CPU y ahora me mandaron un mail tal como a Inkilino en el que me decían que estaban limitando mi dominio a 250 conexiones.. no especifican cada cuanto tiempo.
Entre las soluciones que me han dado para reducir esto, fue primero instalar wp-cache, ya que lo hice y me seguían diciendo que estaba alterando su servidor, me dijeron que podía reducir esto si hacía varios subdominios para cada cosa….
Asi que ahora tengo un subdominio en donde meto todas las imagenes del blog y otro aparte para archivos. Según esto cada dominio y subdominio están hosteados en servidores diferentes de modo que cada uno tiene el límite de 250, por lo tanto las posibilidades de que llegues al limite se disminuyen bastante entre más subdominios tengas. Ando esperando a ver qué me dicen después de haber implementado este cambio… espero que ya le quiten el limite a mi blog :(….
Saludos y estaré al pendiente por acá a ver si alguien sale con alguna otra forma de optimización.
-
elvilla:
Muy interesante!
Ahora mismo estaba leyendo por la red opiniones de Dreamhost para darme de alta ya,pq pensaba esperar un tiempo y seguir tirando con servidores de blogs gratuitos, pero hoy he tenido un problemilla y he decidido q no merece la pena seguir utilizándolos
Buscando en google encontré el post de la maté por un yogur y vi q era antiguo bajé al final pa ver si se había solucionao y encontré un enlace a este, y bueno parece q más o menos sí se solucionó
asi q a ver si me doy de alta
gracias y un saludo!
-
por cierto se me olvidaba
aprovecho para hacer esta pregunta: ¿si deseas aumentar de un hosting básico a uno más avanzado, no me refiero simplemente a aumentar ancho de banda o espacio, sino pasar de un hosting “crazy domain” a un “code monster”, aunq hayas pagado un año entero, puedes cambiarte?
aunq supongo q esto no me hará falta de momento y me sobrará ancho de banda
venga, un saludo
-
Supongo que no tienes ningún problema, en cualquier caso si sabes inglés, casi todo lo que se te pueda ocurrir preguntar lo tienen en su wiki:
-
henri:
Yo tuve que cambiar mi blog ya que sólo tenía problemas con este hosting. Me cambié a los servidores de http://www.isyourhost.com que están en un centro de datos de España y los problemas que antes tenía con mi blog han desaparecido. Ahora todo me funciona correctamente.
-
gustavo:
Hola.
Tengo instalado postnuke en dreamhost y a partir de las 8 de la noche es imposible navegar por la web. Que me aconsejais hacer, activar el FCGI?
Mis estadisticas medias diarias son las siguientes:
Average successful requests per day: 172,873
Average successful requests for pages per day: 20411
Distinct hosts served: 3,265
Data transferred: 2.03 gigabytes
Average data transferred per day: 736.01 megabytesY las estadisticas de uso de CPU son las siguientes:
Process CPU seconds user machine count average
php5.cgi 6668.9400 99.998% 27.787% 24462 0.273
sendmail 0.0700 0.001% 0.000% 20 0.004
postdrop 0.0500 0.001% 0.000% 20 0.003
———————————————————————-
Total: 6669.0600 100.000% 27.788% 24502
Average per day: 6669.0600 1 days
CPU percentage assumes 24000 cpu seconds per day total.Un saludo
-
Gustavo pues yo de ti me miraría el tema de usar FastCGI pero a la de ya, que 110 minutos es mucho para 20.000 páginas vistas…
Y ya de paso usar un PostNuke no es la mejor solución (dejo aparte temas de seguridad: me pregunto que medidas de cache y formas de ahorrar recursos tiene)…
-
Para todo aquel que siga con problemas al hacer esto. Aseguraos tener el plugin wp-cache desactivado y la línea de este maldito plugin en wp-config.php borrada o comentada.
-
Sergio:
Hola a todos. He intentado activar FastPHP pero no se si esta funcionando o no. En primer lugar no puedo conectarme con ssh al servidor asi que no puedo ver los procesos lanzados. He tenido que hacer unas modificaciones en el .htaccess porque mis ficheros son .html pero necesito que los interprete el php. Esto es porque inicialmente no pensaba usar php pero se me hizo imposible y una vez que google me tenia indexado como .html tuve que cambiar la directiva. Ahora mismo mi .htaccess es :
RemoveHandler .html .htm
Options +ExecCGI
AddHandler fastcgi-script fcg fcgi fpl
AddHandler php5-fastcgi .php .html .htm
Action php5-fastcgi /php5-wrapper.fcgi
AddType application/x-httpd-php .html .htm
¿Alguien sabe si esto es correcto y devería de estar funcionando correctamente? Es que tampoco tengo aceso a las estadisticas de consumo de CPU.
Saludos -
A simple vista parece correcto Sergio. Una manera “fácil” de comprobarlo es que te cierren el sitio por exceso de CPU. Aparte de eso, si no te dicen el consumo de CPU en cada momento y al mismo tiempo te pueden/quieren cerrar por ello cambiate de hosting…
-
sekano:
Hola, a mi me acaban de mandar el mail de aviso de alto consumo y estoy algo angustiado porque no entiendo nada de fastcgi ni tocar el htacces pero no quiero tener que mudarme ni andar haciendo equilibrios para dejar a los de dreamhost tranquilos.
Yo les digo que me lo solucionen ellos, que para eso les pago. Si se les sobrecalienta la maquina pues que se lo curren para optimizar. Desde cuando es el cliente el que tiene que mirar estas cosas, si muy pocos son los que saben de php, cgi y esas historias. Yo sólo se postear de medio ambiente y nada más.
Del enorme ancho de banda no consumo ni un 1% con 4500 visitas diarias y tampoco llego al 1% del espacio utilizado del crazy domain ese, que tan loco no estará si me mandan ahora mensajes de esos.
Esto es lo que me dice John:
—————
Hello,We still haven’t heard back from you regarding upgrading your account or
lowering your usage so please provide some feedback or we may be forced
to disable your account:john$dreamhost.com
Thanks!
John
———————–
Si el Wp-Cache es la solución no lo se. Por el momento he borrado un dominio con blog que sólo hacía que leer RSS de otros blogs y republicar (lo hice como experimento) y otros dos blogs que no les daba mucho uso. También he optimizado las BBDD y vaciado tablas, además de eliminar PopStats, Algún Fisgón (aunque estaban desactivados) y SpamKarma (cambiados por Akismet). La estadísticas las tengo hace tiempo con el plugin de Wordpress.com.Agradecería cualquier ayuda por pequeña que sea para saber cual puede ser el próximo paso a dar ya que no se cuanto tardarán en cerrarme la cuenta porque no me entiendo muy bien con ellos por mi cutre inglés.
Eso sí, si me cierran la cuenta la monto gorda y después me voy a un servidor dedicado me cueste lo que me cueste. Lo que me jode es que me ofrecen ellos un servidor dedicado (más caro que el actual, claro) y me tengo una mosca detrás de la oreja que me dice que esto no es más que una maniobra para sacarme más pasta. No creo que mi cuenta de tantos problemas de consumo como ellos me cuentan y si los da es problema suyo (bueno, también mio si me cierran la cuenta).Un saludo y gracias por adelantado
-
Sekano, de más a menos imprescindible:
1. Instala si no lo tienes WP-Cache.
2. Si usas PHP, mira a ver si puedes elegir de versión “mod_php” y te quitarás de problemas, de lo contrario tienes que usar PHP-CGI como FastCGI, por muy chungo que sea.
3. Elimina todos los plugins que no te hagan falta.Y poco más que decir…
-
He instalado el Wp-Cache 2.1 de Ricardo Galli y he quitado algún plugin. También he puesto que todos los blog muestren sólo los últimos 5 post y he quitado el post-views del index.
Dreamhost me ha respondido a la petición de ayuda diciendome un robot que han pasado mi ticket a la persona adecuada y me responderá en 24 horas (se han tomado otras 24 para lo del robot).
Lo del mod_php no lo tengo pero sí puedo activar el FastCGI aunque no se como preparar el sitio para aprovecharlo. -
A ver, tengo que crear el “fcgi.test.tld” y colocarlo en el dominio del blog. Y después añadir unas líneas al htaccess y activar el FastCGI en Dreamhost. ¿Es así?
-
Sekano: casi, el fcgi.test.tld es el dominio/subdominio del blog en que queremos poner FCGI. En tu caso /home/TU-USUARIO/blog.sekano.org/
-
Buff…no me entero. Entonces cuantos archivos tengo que crear y como se llaman?
-
Sekano: dos. El php5-wrapper.fcgi con el código:
#!/bin/bash export PHP_FCGI_CHILDREN=3 exec /dh/cgi-system/php5.cgi
Y el otro código va al htaccess, por favor re-leete el artículo anda xD
-
Gracias Armonth, creo que lo que yo pensaba parte del código son comandos tecleados en una interfaz shell o algo similar. Espero que sea tan fácil como parece. Por el momento he realizado los cambios y he activado el FastCgi en Dreamhost y en vez del blog me aparece un Internal Server Error. También he cambiado la versión de PHP de la 4 noseque a la 5 nosecuantos.
Una cosa que me salía de vez en cuando mirando mi blog es esta ventanita muy extraña que no se si estaría relacionada con el alto consumo de CPU.
http://blog.sekano.org/wp-content/uploads/2007/09/php-script.jpg -
No sé exactamente por qué, pero en algunos servidores el uso de FastCGI simplemente no funciona :\.
En esos casos, poco más se puede hacer.
-
Entonces el problema es claramente de Dreamhost (aunque pienso que antes también lo era) así que podrían cambiarme de servidor o hacerme algún apaño en vez de amenazarme con el cierre de cuenta y que tenga que hacerme hacker en un cursillo express ;)
Mira, he hecho las cosas esas que se dicen en el post, pero no entiendo los resultados y no se si he puesto los permisos de escritura como hay que ponerlos. Tampoco se interpretar lo de ps aux
http://blog.sekano.org/wp-content/uploads/2007/09/ps-aux-sekano.jpg
PD: Pero se hacer fotos de la pantalla -
Nada, no te mates, si al hacerlo te da internal server error dudo mucho que consigas que funcione…
-
Como me dijiste que el FastCGI podía no chutar descomente las líneas del .htaccess que hacían referencia al php5-wrapper.fcgi, aunque deje el FAstCGi activado y el archivo fcgi andando por el dominio. El blog volvió a funcionar y supuse que nuevamente con el php como cgi normal.
Dreamhost me ha contestado y dice que ya no consumo exceso de CPU y cierra la incidencia. A mi eso no me sirve y quiero que me lo expliquen. Mientras tanto active el CPU reports resources y estoy aprendiendo a interpretar los resultados.
He ampliado el post inicial que si leyerás seguro que me harías alguna interesante aclaración:
http://blog.sekano.org/?p=1235
Gracias por tu ayuda y tu tiempo, algún día alguien te lo pagará Armonth -
Sekano, mientras no te pases de los 24000seg no te dirán nada (en teoría) por lo que con esos 4000seg vas bien.
El uso que haces de php5.cgi es normal ya que si activas php 5 usará php5.cgi siempre (y si activas FCGI también). El php.cgi sale porque ese día hubo peticiones que todavía fueron tratadas por PHP 4.
Mira, la única diferencia entre FCGI y CGI es que al hacer una petición pasa lo siguiente:
CGI -> se abre el PHP -> procesa la petición -> se cierra el PHP .
FCGI -> se abren X copias de PHP -> una de las copias procesa la petición -> las X copias permanecen en memoria a la espera de más peticiones.Una vez abierto PHP, solo gasta memoria el mantenerlo en memoria (valga la redundancia) pero no gasta CPU. En CGI normal cada petición debe abrir una copia de PHP (X gasto de CPU) mientras que en FCGI no.
Sobre lo que preguntas en el blog, voy a dejar ahí también un comentario.
-
Gracias Armonth por tus aclaraciones, la verdad es que me vas guiando en estos oscuros territorios para mi de los procesos ocultos y los consumos misteriosos.
He mirado un archivo raro del resources llamado sa.itemized.0 y observo que el día de ayer, en el que dices que convivieron las dos versiones de PHP en el blog, las consultas con php5 (v.5.2.2) parecen consumir de media más memoria que las de php (v.4.4.7).
Como me aburro bastante he analizado con excel los 10.872 procesos que listaba el susodicho archivo, de los que 5.537 corresponden a php.cgi y 5.335 a php5.cgi.
En el primer caso la media de consumo de CPU es de 0,34 con una ocupación de memoria media por proceso de 3.868k. Los mismos datos para el php5.cgi son de 0,39 y 4.370k.
¿Esto significa algo relevante?. ¿O mejor lo dejo y me olvido de estos asuntos?. Yo quiero entender que php5 sea una mejora del php versión 4 pero no me cuadra con que consuma más memoria y más CPU.
El blog iba igual con la versión 4, así que al poner la 5 no le estoy pidiendo que haga cosas extras y deberia dedicarse a hacerlas mejor y más rápido, digo yo.
He dejado una captura del archivillo en el post de antes:
http://blog.sekano.org/?p=1235 -
Que sea una mejora no significa que no consuma más memoria, normalmente cuantas más funcionalidades le pongas más consume.
Es algo sabido que PHP5 consume más memoria que PHP4, pero 4 o 5MB de RAM no son nada por eso es mejor mantener PHP en memoria como módulo de apache o como FCGI…
-
Estos de dreamhost me están empezando a volver loco. A raíz de los cambios de versión del PHP ahora no se ven comas ni acentos en Internet Explorer, aunque en Firefoz todo parece normal. ¿A que puede deberse esto? y lo que es más importante ¿como se soluciona?. Tengo el blog en UTF8 que se supone que era lo más universal para estas cosas.
-
Vaya, parece que esta vez no era cosa de Dreamhost, he desactivado el WP-Cache y ha dejado de producirse el fallo de los acentos. Lo malo es que si WP-Cache era quien me libraba del alto consumo de CPU, ahora vamos a volver a la misma historia. Puede ser también esta la causa de que contabilizo 2000 visitas menos de lo habitual?
-
He llegado a la conclusión de que Dreamhost te da mucho más de lo que te permite luego utilizar, lo que considero un engaño exista letra pequeña o no. Me gustaría que me dieras tu opinión por si he cometido algún error de bulto en mis cálculos.
Un saludo y gracias por tu atención. El post en cuestión:
http://blog.sekano.org/?p=1258 -
Jairo Aodlfo:
El problema de Sekano con los acentos posiblemente tenia que ver con la codificación por defecto de los archivos de su servidor, de seguro distinta a la que su WordPress tiene configurada. Me explico, cuando las páginas solicitadas no pasan por el caché, el propio WP envía la cabecera que define la codificación (por ejemplo utf8), pero cuando la página es tomada del cache sin pasar por el CMS es enviada con la codificación por defecto (ISO-8859-1 por ejemplo), lo que seria inconsistente. Como solución yo habría colocado un .htaccess en la carpeta que almacena el cache definiendo la codificación por defecto para todos los ficheros y directorios contenidos en ella. Suponiendo que sea utf8 quedaria así:
AddDefaultCharset UTF-8
Saludos cordiales para todos …
