Foros del Web » Administración de Sistemas » Cloud Computing »

Mi VPS nunca parece ser suficiente

Estas en el tema de Mi VPS nunca parece ser suficiente en el foro de Cloud Computing en Foros del Web. Buenas chicos y feliz año a todos, Tengo un verdadero problema con mi VPS puesto que llevo unos cuantos meses con un sobreuso del servidor ...
  #1 (permalink)  
Antiguo 02/01/2009, 05:58
 
Fecha de Ingreso: diciembre-2006
Mensajes: 21
Antigüedad: 17 años, 5 meses
Puntos: 0
Mi VPS nunca parece ser suficiente

Buenas chicos y feliz año a todos,

Tengo un verdadero problema con mi VPS puesto que llevo unos cuantos meses con un sobreuso del servidor que no cuadra para nada con mis estadísticas (la web no supera las 3000 visitas diarias)...

Especificaciones de mi VPS:
Cita:
512 MB Guaranteed RAM (1024 Max)
Guaranteed CPU 2.0 GhZ
800 GB Bandwith
Segun Virtuozzo tengo un uso del 60% del servidor cuando (que sube considerablemente cuando aumenta el trafico) y lo que más me preocupa es que tengo continuamente alertas QoS de privvmpages (zona amarilla)...

Os copio datos que he recuperado...

Mysql report:
Cita:
Uptime = 7 days 12 hrs 8 min 9 sec
Avg. qps = 16
Total Questions = 10964329
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/...variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 14 out of 10964350 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/...-recovery.html

WORKER THREADS
Current thread_cache_size = 128
Current threads_cached = 65
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 500
Current threads_connected = 1
Historic max_used_connections = 66
The number of used connections is 13% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 640 M
Configured Max Per-thread Buffers : 2 G
Configured Max Global Buffers : 282 M
Configured Max Memory Limit : 2 G
Physical Memory : 900.00 M

Max memory limit exceeds 90% of physical memory

KEY BUFFER
Current MyISAM index space = 146 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 927
Key buffer fill ratio = 100.00 %
You could increase key_buffer_size
It is safe to raise this up to 1/4 of total system memory;
assuming this is a dedicated database server.

QUERY CACHE
Query cache is enabled
Current query_cache_size = 256 M
Current query_cache_used = 93 M
Current query_cache_limit = 8 M
Current Query cache Memory fill ratio = 36.47 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 4109 queries where a join could not use an index properly
You have had 1 joins without keys that check for key usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 2558 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your open_files_limit
You should set a higher value for open_files_limit in my.cnf

TABLE CACHE
Current table_cache value = 1024 tables
You have a total of 946 tables
You have 1024 open tables.
Current table_cache hit rate is 33%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 336451 temp tables, 12% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 2 M
Current table scan ratio = 75 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 770
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.
Otro análisis:

Cita:
MySQL 5.0.67-community uptime 7 12:9:40 Wed Dec 31 01:58:20 2008

__ Key __________________________________________________ _______________
Buffer used 14.16M of 16.00M %Used: 88.48
Current 16.00M %Usage: 100.00
Write hit 51.00%
Read hit 99.89%

__ Questions __________________________________________________ _________
Total 10.97M 16.9/s
QC Hits 6.88M 10.6/s %Total: 62.78
DMS 3.01M 4.6/s 27.45
Com_ 667.04k 1.0/s 6.08
COM_QUIT 374.91k 0.6/s 3.42
+Unknown 29.16k 0.0/s 0.27
Slow 10 s 14 0.0/s 0.00 %DMS: 0.00 Log: OFF
DMS 3.01M 4.6/s 27.45
SELECT 1.89M 2.9/s 17.21 62.69
UPDATE 664.53k 1.0/s 6.06 22.08
INSERT 206.02k 0.3/s 1.88 6.84
DELETE 197.83k 0.3/s 1.80 6.57
REPLACE 54.65k 0.1/s 0.50 1.82
Com_ 667.04k 1.0/s 6.08
change_db 507.65k 0.8/s 4.63
set_option 154.02k 0.2/s 1.40
show_proces 2.17k 0.0/s 0.02

__ SELECT and Sort __________________________________________________ ___
Scan 733.35k 1.1/s %SELECT: 38.87
Range 64.09k 0.1/s 3.40
Full join 4.11k 0.0/s 0.22
Range check 1 0.0/s 0.00
Full rng join 28 0.0/s 0.00
Sort scan 446.70k 0.7/s
Sort range 262.06k 0.4/s
Sort mrg pass 519 0.0/s

__ Query Cache __________________________________________________ _______
Memory usage 93.43M of 256.00M %Used: 36.50
Block Fragmnt 5.30%
Hits 6.88M 10.6/s
Inserts 1.75M 2.7/s
Insrtrune 1.75M:1 2.7/s
Hit:Insert 3.93:1

__ Table Locks __________________________________________________ _______
Waited 6.50k 0.0/s %Total: 0.13
Immediate 5.01M 7.7/s

__ Tables __________________________________________________ ____________
Open 1024 of 1024 %Cache: 100.00
Opened 3.07k 0.0/s

__ Connections __________________________________________________ _______
Max used 66 of 500 %Max: 13.20
Total 375.57k 0.6/s

__ Created Temp __________________________________________________ ______
Disk table 43.15k 0.1/s
Table 336.48k 0.5/s Size: 32.0M
File 1.04k 0.0/s

__ Threads __________________________________________________ ___________
Running 1 of 1
Cached 65 of 128 %Hit: 99.98
Created 66 0.0/s
Slow 0 0/s

__ Aborted __________________________________________________ ___________
Clients 1.32k 0.0/s
Connects 75 0.0/s

__ Bytes __________________________________________________ _____________
Sent 914.84M 1.4k/s
Received 1.43G 2.2k/s
  #2 (permalink)  
Antiguo 02/01/2009, 06:00
 
Fecha de Ingreso: diciembre-2006
Mensajes: 21
Antigüedad: 17 años, 5 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

Un 'top':

Cita:
top - 18:44:52 up 8 days, 4:56, 1 user, load average: 0.29, 0.20, 0.18
Tasks: 73 total, 1 running, 70 sleeping, 0 stopped, 2 zombie
Cpu(s): 1.8% us, 1.2% sy, 0.0% ni, 97.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 921600k total, 742484k used, 179116k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14011 nobody 15 0 24764 15m 3144 S 17 1.7 0:26.20 httpd
31772 mysql 16 0 325m 175m 4188 S 7 19.5 911:29.98 mysqld
15819 root 16 0 2116 1056 828 R 0 0.1 0:00.05 top
1 root 16 0 1980 656 568 S 0 0.1 0:03.19 init
30597 root 16 0 1644 568 480 S 0 0.1 0:05.37 syslogd
30602 root 20 0 1588 400 336 S 0 0.0 0:00.00 klogd
30651 root 21 0 1568 420 356 S 0 0.0 0:00.00 courierlogger
30652 root 15 0 1928 624 520 S 0 0.1 0:00.03 authdaemond
30659 root 16 0 1928 380 264 S 0 0.0 0:01.24 authdaemond
30660 root 16 0 1928 380 264 S 0 0.0 0:01.28 authdaemond
30672 root 16 0 6960 1048 668 S 0 0.1 0:00.01 sshd
30699 root 18 0 2636 864 700 S 0 0.1 0:00.00 xinetd
30712 root 17 0 2368 1152 996 S 0 0.1 0:00.02 mysqld_safe
31791 root 20 0 1572 344 288 S 0 0.0 0:00.00 courierlogger
31792 root 18 0 1680 516 440 S 0 0.1 0:00.01 couriertcpd
31802 root 18 0 1572 344 288 S 0 0.0 0:00.00 courierlogger
31803 root 19 0 1680 516 440 S 0 0.1 0:00.01 couriertcpd
31808 root 15 0 1572 424 356 S 0 0.0 0:02.37 courierlogger
31809 root 15 0 1680 536 460 S 0 0.1 0:02.33 couriertcpd
31815 root 18 0 1572 344 288 S 0 0.0 0:00.00 courierlogger
31816 root 22 0 1680 516 440 S 0 0.1 0:00.01 couriertcpd
31882 root 16 0 18268 9996 4104 S 0 1.1 0:24.05 httpd
31891 root 15 0 5076 1512 1180 S 0 0.2 0:00.31 pure-ftpd
31895 root 16 0 4804 1092 860 S 0 0.1 0:00.07 pure-authd
31905 root 15 0 3204 1112 576 S 0 0.1 0:04.63 crond
31951 xfs 16 0 3220 1152 740 S 0 0.1 0:00.01 xfs
32204 root 23 0 5396 700 436 S 0 0.1 0:00.00 saslauthd
32208 root 23 0 5396 428 164 S 0 0.0 0:00.00 saslauthd
32246 root 18 0 1600 428 348 S 0 0.0 0:00.00 portsentry
5445 mailnull 16 0 10128 2620 2128 S 0 0.3 0:18.12 exim
5453 mailnull 16 0 10124 2596 2116 S 0 0.3 0:00.13 exim
14318 named 24 0 108m 3860 2032 S 0 0.4 0:01.08 named
12048 root 15 0 18268 7012 1144 S 0 0.8 0:00.00 httpd
15504 root 34 19 3728 1756 844 S 0 0.2 0:00.62 cpanellogd
15531 root 16 0 5068 3500 1300 S 0 0.4 0:38.46 tailwatchd
15540 root 20 0 5688 3668 932 S 0 0.4 0:00.00 cphulkd.pl
15578 root 22 0 14308 7272 436 S 0 0.8 0:00.00 cpdavd
29757 root 15 0 18232 7984 1008 S 0 0.9 0:01.52 cpsrvd-ssl
5219 nobody 16 0 23684 14m 3096 S 0 1.6 0:45.42 httpd
30166 nobody 16 0 24264 15m 3156 S 0 1.7 0:49.21 httpd
32598 nobody 15 0 24456 15m 3072 S 0 1.7 0:26.36 httpd
32623 nobody 16 0 24708 15m 3156 S 0 1.7 0:32.49 httpd
32630 nobody 15 0 22872 13m 3100 S 0 1.5 0:31.78 httpd
32669 nobody 16 0 24484 15m 3116 S 0 1.7 0:38.28 httpd
29953 nobody 16 0 24164 14m 3148 S 0 1.7 0:30.20 httpd
30137 nobody 15 0 26356 16m 3080 S 0 1.9 0:30.99 httpd
14008 nobody 16 0 24560 15m 3072 S 0 1.7 0:22.08 httpd
14017 nobody 16 0 24752 15m 3072 S 0 1.7 0:20.30 httpd
14018 nobody 16 0 25056 15m 3168 S 0 1.8 0:19.29 httpd
15921 nobody 15 0 24468 15m 3088 S 0 1.7 0:22.11 httpd
30038 nobody 16 0 24816 15m 3168 S 0 1.7 0:22.33 httpd
1868 nobody 16 0 25080 15m 3136 S 0 1.8 0:22.10 httpd
1888 nobody 16 0 24212 14m 3080 S 0 1.7 0:19.27 httpd
15668 nobody 16 0 24488 15m 3124 S 0 1.7 0:20.09 httpd
Por favor, a ver si me podéis echar una mano. Cualquier cosa que podáis necesitar para comprobar más cosas decírmela y la posteo en este hilo

GRACIAS!
  #3 (permalink)  
Antiguo 02/01/2009, 07:09
 
Fecha de Ingreso: diciembre-2008
Ubicación: Ciudad Autónoma de Buenos Aires, Argentina
Mensajes: 72
Antigüedad: 15 años, 4 meses
Puntos: 1
Respuesta: Mi VPS nunca parece ser suficiente

El server load no parece estar saturado en la información que envias, pero quizás el sobre consumo se deba a acceso intensivo a otros recursos de tu VPS, como puede ser demasiado acceso al disco, entre otros aspectos que desde aquí no puedo ver.

En primera instancia, sería bueno que le consultes a tu proveedor de hosting si pueden hacer una monotorización intensiva de tu equipo durante un período de tiempo prolongado (24 hs por ejemplo), a fin de detectar donde y cuando es que se produce ese alto consumo del que el VPS te informa.

Muchas veces la cantidad de visitas no es un indicador exacto para saber los recursos que consume un sitio. Es necesario conocer el site, saber que hace y como lo hace para llegar a una conclusión mas certera. Al menos, en casos como éste, donde la cantidad de visitas no son un indicio de que por ahí puede estar la causa del alto consumo.
  #4 (permalink)  
Antiguo 02/01/2009, 12:38
Avatar de cincinnati  
Fecha de Ingreso: noviembre-2002
Ubicación: Cerca, muy cerca
Mensajes: 971
Antigüedad: 21 años, 5 meses
Puntos: 29
Respuesta: Mi VPS nunca parece ser suficiente

El parámetro privvmpages es relativo a la memoria garantizada. Si tienes alertas relativas a este parámetro significa que en el momento en que te aparece la alerta tu VPS está utilizando toda la memoria garantizada que tiene. No tiene nada que ver con el I/O de disco.

Para saber qué te esta consumiento esa memoria, tienes que mirar el top en el momento en que te salta la alerta.

En el top que has enviado supongo que ves dos procesos (los dos primeros, httpd y mysql) que entre los dos consumen aprox, el 35% de tu memoria disponible.

De hecho en ese top aparece:

Mem: 921600k total, 742484k used

Esto es: estás usando no sólo la memoria garantizada (512 MB) sino también la burstable, lo que provoca que tu VPS pueda no funcionar correctamente y tengas servicios que caen.

EN un VPS debes fijarte en la memoria garantizada (privmpages). Si la superas, como es tu caso, tu VPS se ha quedado corto.

En el reporte de mysql eu has enviado se ve:

MEMORY USAGE
Max Memory Ever Allocated : 640 M
Configured Max Per-thread Buffers : 2 G
Configured Max Global Buffers : 282 M
Configured Max Memory Limit : 2 G
Physical Memory : 900.00 M


Esto es: que tu MySQL está configurado en base a la memoria máxima burstable (1 GB) y no en base a la memoria garantizada que tienes (512 MB). Esto es incorrecto. Debes ajustarlo a la memoria garantizada que tienes o tendrás problemas de rendimiento.

De todas formas, me da que necesitas un VPS más grande, dado que tu MySQL ha llegado a utilizar 640 MB de RAM y si le sumas lo que utilizan los demás servicios, la suma supera con creces la memoria garantizada de tu VPS.
__________________
Be water my friend
  #5 (permalink)  
Antiguo 02/01/2009, 12:40
Avatar de cincinnati  
Fecha de Ingreso: noviembre-2002
Ubicación: Cerca, muy cerca
Mensajes: 971
Antigüedad: 21 años, 5 meses
Puntos: 29
Respuesta: Mi VPS nunca parece ser suficiente

Cita:
En primera instancia, sería bueno que le consultes a tu proveedor de hosting si pueden hacer una monotorización intensiva de tu equipo durante un período de tiempo prolongado (24 hs por ejemplo), a fin de detectar donde y cuando es que se produce ese alto consumo del que el VPS te informa.
Si tu VPS no es administrado, esta tarea la debes realizar tú, no tu proveedor. Si no sabes cómo hacerlo o no tienes los conocimientos suficientes y tu VPS no es administrado (esto es, lo administras tú) y se lo pides a tu proveedor, lo más logico es que te cobre por ese servicio, a no ser que esté desesperado y haga todo gratis.
__________________
Be water my friend
  #6 (permalink)  
Antiguo 02/01/2009, 12:49
Avatar de cincinnati  
Fecha de Ingreso: noviembre-2002
Ubicación: Cerca, muy cerca
Mensajes: 971
Antigüedad: 21 años, 5 meses
Puntos: 29
Respuesta: Mi VPS nunca parece ser suficiente

Cuando comentaba más arriba que tienes dos procesos que te consumen aprox. el 35% de memoria, me refiero al top que ha enviado y que no es sino una fotografía de ese momento.

Bien, los procesos son:

14011 nobody 15 0 24764 15m 3144 S 17 1.7 0:26.20 httpd
31772 mysql 16 0 325m 175m 4188 S 7 19.5 911:29.98 mysqld

(los dos primeros)

Sólo esos dos procesos te están consumiento un 36,5% de 921600k de memoria (512 MB garantizada y el resto la burstable). Esto es, esos dos procesos se comen ya 328 MB de RAM. Es mucho para tener sólo 512 MB garantizados.

Haz un show processlist desde mysql para ver qué procesos tienes en ese momento.
__________________
Be water my friend
  #7 (permalink)  
Antiguo 02/01/2009, 13:16
 
Fecha de Ingreso: diciembre-2008
Ubicación: Ciudad Autónoma de Buenos Aires, Argentina
Mensajes: 72
Antigüedad: 15 años, 4 meses
Puntos: 1
Respuesta: Mi VPS nunca parece ser suficiente

Lo del disco fue solo a modo de ejemplo de cuestiones del equipo que pueden estar consumiento muchos recursos sin que el usuario sepa en primera instancia el por que sucede. Ya que, de acuerdo a la primera impresión del usuario, es algo que no le debería suceder por que no tiene tantas visitas diarias.

Por eso me detuve a comentar que la cantidad de visitas no siempre es parámetro para asegurar que un sitio no debería consumir tantos recursos. Hay muchos factores, además de las visitas, que pueden ser el "culpable" de que un sitio consuma mucho o poco.

A su vez, un VPS que tira alertas sobre el alto consumo de memoria, no dejaría de revisar el uso del disco ya que es probable que lo esté usando mucho por necesidad de uso y acceso a la memoria swap.

Como bien dices, el top publicado no es mas que una foto del momento, y hay que tener cuidado con establecer síntomas con un parámetro tan acotado.

Es correcto mencionar sobre el tipo de soporte que el usuario tenga, y sobre las solicitudes del cliente para con éste. Fue un ítem que olvidé aclarar en mi anterior mensaje.


Marchello, si tu servicio de hosting no incluye el soporte necesario para este caso, te recomiendo descargar el MySQL GUI Tools. Éste incluye una utilidad llamada MySQL Administrator, que te muestra la cantidad de consultas que se van generando en tu site en tiempo real..
Vos sabes que secciones de tu site pueden generar muchas consultas, por lo cual fijate si podes optimizarlas o disminuirlas.
A medida que avances con la optimización de tu site, podes ir viendo si esto repercute en la cantidad de consultas que se van desplegando en el MySQL Administrator, y también en los consumos de tu VPS.

Por otro lado, revisa a través de la opción "Show MySQL Processes" del WHM, si se generan muchas consultas que traben tu base de datos estableciendo como estado "locked" una o mas tablas. Cuando una tabla se "lockea" durante muchos segundos, hace que el motor de base de datos vaya colocando en cola a todas las consultas generadas posteriormente, las cuales permanecen allí hasta tanto no se destrabe la tabla lockeada en un principio. Todo este proceso hace levantar mucho el consumo de tu equipo, y si se produce de forma repetida, tantísimo mas.

Estas son cosas relativamente sencillas de revisar y que te puede llegar a orientar por donde vienen esos altos consumos, si es que se producen efectivamente desde el consumo de RAM desde la MySQL.

Y por último, también te recomiendo plantearte que tipo de servicio de soporte necesitas para tu VPS.

Saludos y no dejes de contarnos como avanzas sobre este tema.


Saludos!

Última edición por EmiSaez; 02/01/2009 a las 14:04
  #8 (permalink)  
Antiguo 02/01/2009, 14:11
 
Fecha de Ingreso: diciembre-2006
Mensajes: 21
Antigüedad: 17 años, 5 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

Cita:
Iniciado por cincinnati Ver Mensaje
Haz un show processlist desde mysql para ver qué procesos tienes en ese momento.
Haciendolo desde WHM solo consigo ver tres; El de la propia consulta, el de la base de datos de la web y el de la base de datos del foro, estos dos ultimos en 'sleep'... ¿Debo mirarlo de alguna otra manera?

Tengo el VPS Administrado y ya he contactado con ellos pidiendo que hagan la monitorización asi que espero que me manden los datos mañana.

Obviamente tengo acceso a la máquina asi que si necesitaís otros análisis para poder verlo mejor no dudéis en pedirmelo

Y mil gracias de nuevo!

P.D. Si los resultados no son concluyentes mañana monto lo de MySQL GUI Tools que recomendó EmiSaez
  #9 (permalink)  
Antiguo 02/01/2009, 16:57
 
Fecha de Ingreso: diciembre-2008
Ubicación: Ciudad Autónoma de Buenos Aires, Argentina
Mensajes: 72
Antigüedad: 15 años, 4 meses
Puntos: 1
Respuesta: Mi VPS nunca parece ser suficiente

Cita:
Iniciado por Marchello Ver Mensaje
P.D. Si los resultados no son concluyentes mañana monto lo de MySQL GUI Tools que recomendó EmiSaez
Es una gran herramienta. A nosotros nos ayudó mucho a la hora de optimizar el funcionamiento y consumo de recursos de algunos sites.
Es probable incluso que adquiera la versión paga para sumar las utilidades que dicha versión incluye.

Mucha suerte con tu caso, espero que el soporte contratado pueda resolverlo, o al menos orientarte por que lado está el alto consumo en tu VPS.
  #10 (permalink)  
Antiguo 02/01/2009, 22:22
Avatar de sebasnob  
Fecha de Ingreso: enero-2008
Ubicación: Rosario
Mensajes: 27
Antigüedad: 16 años, 4 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

no se q tipo de aplicaciones tenes ejecutandose en el vps, pero hay muchas q te consumen una cantidad enorme de recursos, por ejemplo joomla hace un uso excesivo de mysql q muchas veces te puede tirar abajo el vps, si son aplicaciones programadas por vos te recomiendo q intentes optimizar las consultas a la base de datos, yo por ejemplo me fijo en la pagina oficial de mysql q tiene algunas funciones muy interesantes para esto:

http://dev.mysql.com/doc/refman/5.0/es/mysql-optimization.html

espero q te sirva.

Saludos!
  #11 (permalink)  
Antiguo 04/01/2009, 04:55
 
Fecha de Ingreso: diciembre-2006
Mensajes: 21
Antigüedad: 17 años, 5 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

¿Qué tal? Os comento las novedades...

A ver, los problemas nos vienen de una web desarrollada bajo Joomla y con unos foros Phpbb. Sí, sé que generan mucha carga por experiencias anteriores pero para eso contraté un VPS (que es administrado) contando con tan pocas visitas; obviamente si crece la web tendre que aumentar la capacidad....

Estamos hablando con el servicio técnico. Primero nos dijeron que los problemas venian de los foros por lo que desactivamos las búsquedas y optimizamos las tablas para reducir el espacio en disco de dicha base de datos. Les pedimos más detalles para seguir trabajando y nos han enviado un 'proc stat' que si queréis os copio pero creo que la última línea será más útil:

Cita:
Uptime: 973315 Threads: 56 Questions: 15210251 Slow queries: 31 Opens: 4591 Flush tables: 1 Open tables: 1024 Queries per second avg: 15.627
Nos sugirieron entonces activar las long_query y eso hemos hecho, pero sigo sin estar convencido de que ahí esté el problema. Además ahora sí que nos confirman que los recursos los 'chupa' la bd principal de la web.

El parámetro 'privvmpages' (cuyo límites son 230,400/256,000) ronda con un tráfico medio los 178,000 y sube hacia los 200,000 con un tráfico moderadamente alto.

¿Qué más puedo hacer? ¿Qué datos os puedo dar?

Gracias de nuevo chicos, a ver si consigo quitarme esto de la cabeza puesto que me quita tiempo de todos lados
  #12 (permalink)  
Antiguo 05/01/2009, 17:05
(Desactivado)
 
Fecha de Ingreso: julio-2008
Ubicación: Muchas noches sin dormir
Mensajes: 211
Antigüedad: 15 años, 10 meses
Puntos: 7
Respuesta: Mi VPS nunca parece ser suficiente

Creo que la respuesta es bastante fácil, podrías realizar una optimización de MySQL más Apache y optimizar el foro.

http://dev.mysql.com/doc/refman/5.0/...imization.html

http://islaserver.com/articulos/sist...ysqltuner.html

http://sigt.net/archivo/como-optimiz...ordpress.xhtml

http://www.ibm.com/developerworks/we...3.html?ca=drs-

En Google puedes encontrar mucha documentación al respecto.

Saludos,
  #13 (permalink)  
Antiguo 06/01/2009, 11:59
Avatar de sebasnob  
Fecha de Ingreso: enero-2008
Ubicación: Rosario
Mensajes: 27
Antigüedad: 16 años, 4 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

Si optimizando la base de datos no es suficiente, en una de las paginas de joomla hay una serie de tips para optimizarlo q capaz te pueden ayudar:

http://www.joomlaos.net/optimizacion-del-rendimiento-y-velocidad-de-joomla-2.php

Saludos.
  #14 (permalink)  
Antiguo 16/01/2009, 04:41
 
Fecha de Ingreso: agosto-2008
Mensajes: 17
Antigüedad: 15 años, 8 meses
Puntos: 0
Respuesta: Mi VPS nunca parece ser suficiente

Optimizar el consumo de recursos está muy bien aunque ya visto que vas tan justito yo miraría otro server en el que puedas habitar un poquito mas holgado.
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 09:12.