Dependerá bastante del servidor y de la programación, obviamente.
Cita:
Esto es un boboapunte, pero es que ya no puedo reprimirme. Cuando llegó a 50.000 minutos lo hice, pero ahora con 60.000 ya no aguanto las ganas :-)
790 ? Sl 60235:33 /usr/sbin/mysqld
La línea anterior muestra que el servidor del MySQL (del servidor del Menéame) consumió más de 60.000 minutos de CPU desde la última vez que se reinició –en una actualización de seguridad–, son casi 42 días completos de CPU.
El status da la siguiente salida:
Server version: 5.0.51a-3-log (Debian)
…
Uptime: 79 days 18 hours 10 min 21 sec
…
Threads: 287 Questions: 6812282200 Slow queries: 51042 Opens: 64030 Flush tables: 1 Open tables: 497 Queries per second avg: 988.574
Está en marcha sin parar hace casi 80 días –a punto de dar la vuelta al mundo– y sin nada de “mantenimiento”. En ese período recibió casi 7.000 millones de consultas a casi 1.000 consultas por segundo de media con picos que superan los 10.000 consultas por segundo, sobre una base de datos que no es minúscula –más de 2 millones de comentarios, casi 400.000 artículos y más de 25 millones de votos registrados–.
No está nada mal para una base de datos que tiene sus limitaciones [*] y que hay que tratarla con cariño en las consultas, pero que difícilmente pueda ser batida en estabilidad y eficiencia.
No está nada mal, aunque el FUD no enterprise ready continúa a pesar de la evidencia de los años.
[*] La versión que tenemos es la de etch-backports, ya que la que está en Etch tiene problemas con algunas consultas full-text en UTF-8. También necesitó su trabajo de tuning en las consultas e índices, pero de eso no se escapa ninguna base de datos que tenga que deba dar tiempos de respuestas tan bajos como los que se necesita en las aplicaciones web en general y el Menéame en particular –que necesita hacer muchas consultas diferentes para generar cada página–.
|
Por si te sirve de algo, es del blog de Ricardo Galli, de meneame.net
http://gallir.wordpress.com/2008/06/...ra-la-empresa/