PDA

Ver la Versión Completa: Resuelto Necesita ayuda para reducir la carga del servidor



Simon Lloyd
26-05-11, 08:40
Hola, Tengo problemas con mi carga del servidor, i ya se han trasladado a la dedicada a tratar de curar esto, pero aún así obtener altas cargas de servidor, si puedo desactivar VBET cae la carga del servidor.

¿Puede alguien ayudarme?

@ Kamil, que ya tiene todos los detalles de acceso que le envíen en PM si usted desea comprobar.

kamilkurczak
26-05-11, 20:57
hola,
Aquí tienes una lista de sugerencias VBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html

Recuerde - si usted tiene todos los idiomas habilitados - que tienen un contenido de 53 más (hilos, etc mensajes) en su foro, y el foro, por supuesto, de alto tráfico.

Puede desactivar algunas lenguas y esperar cuando la caché de idioma habilitado estará lleno, después de eso - se puede activar la siguiente parte de las traducciones.

En segundo lugar, en este relase tenemos una gran mejora (muy grande) - este es el sistema de memoria caché (4 opciones diferentes). Se puede comprobar en su AdminCP-> Caché VBET. (Recuerde - debe integrar el servidor para que utilice este tipo de memoria caché)

:)

Simon Lloyd
26-05-11, 22:15
Me han puesto en práctica todo lo que pueda de las recomendaciones de su rendimiento, también he tenido todos los idiomas habilitados (más bien), ya que la compra de VBET alrededor de 6 meses, la carga es siempre alta todo el tiempo. En cuanto a la memoria caché (beta) i no creo que tenga acelerador caché en mi servidor, pero evrything más se ajusta de acuerdo a sus instrucciones.

kamilkurczak
26-05-11, 22:19
desde nuestra última relase hemos trabajado en este sistema de memoria caché - esto debe ser la más grande en el rendimiento. Es necesario tener configurado el servidor con este sistema de caché (tal vez usted ya tiene - pregunte a su soporte para el servidor)

Simon Lloyd
26-05-11, 22:31
Hola Kamil, Acabo de comprobar php info y yo no lo tengo, pero voy a llegar a instalar XCache o algo así

vBET
26-05-11, 22:59
Hola. ¿Por qué tienes problemas con la carga del servidor? Puedo ver su foro se está traduciendo realmente rápido, así que ¿dónde está el problema?

Tenga en cuenta que las traducciones son hechas por los servicios externos de Google. Esto significa que cuando ocurre la traducción de las discusiones están a la espera de la respuesta de Google. Y es por eso que la carga del servidor es más grande, pero no influye en el sistema, porque los hilos esperando tomar sin CPU ni memoria adicional (sólo utilizado ya). Así que es por eso que siempre tendrá una mayor carga de servidores con VBET habilitada (discapacitados sin hilo está a la espera de los resultados de Google) y en el mismo tiempo para probar el foro seguirá trabajando rápido, porque los hilos esperando no tomar ninguna CPU.

Entonces, ¿qué es realmente necesaria para tomar amante de carga del servidor es asegurar que las discusiones no van a esperar a los resultados de Google, pero desafortunadamente Google permite almacenar en caché sus resultados sólo por 15 días. Puede hacerlo por uno mismo - si se deshabilita la caché, o simplemente hacer su tiempo de vida más pequeña que se carga en sí del servidor cada vez mayor - ya que menos resultados se almacenan en caché y más solicitudes en espera de respuestas de Google. No hay magia - traducciones viene de alguna parte y se necesita tiempo para llegar desde Google.

El uso de la memoria caché puede ayudar de alguna manera. Subprocesos en espera de los resultados de Google aún se espera (que no lo pasan hasta que se haya almacenado en caché todas las traducciones, y no porque se limpia de acuerdo con TOS de Google). Resultados aún almacenado en caché se genera más rápido, por lo que pide no esperar a que las traducciones se vaya más rápido de la cola de peticiones.

Aquí usted puede encontrar exactamente lo que la carga del servidor es: la carga del servidor (http://whreviews.com/server-load.htm) y descubrir que todo el tiempo que tienen la carga del servidor sin recursos no es un problema.

Saber cuál es el valor de la carga del servidor no es muy importante, sin embargo. Saber interpretar el valor es lo que cuenta.

recordar la definición: la carga del servidor representa el número de procesos en espera para acceder a la CPU. Pero no todos los procesos son los mismos! Si los procesos son de baja prioridad, cuando una solicitud de nuevo servidor (solicitud de la página) aparece, todavía puede ser manejado casi al instante.

Por no hablar de que la carga del servidor es sólo un factor de muchos otros (uso de memoria, uso de CPU, tamaño de archivo de intercambio)

Como de costumbre, y como muchas personas directamente implicadas en el negocio de hosting decir, todo se reduce a la vida real el comportamiento. Son las páginas de carga rápida? ¿Tiene un proceso como la búsqueda a través de una base de datos de tomar un tiempo razonable? Entonces usted realmente no tiene un problema, sea cual sea la carga del servidor es

Por lo tanto, la prueba definitiva es la forma en que se comporta el servidor. Si el servidor es rápido, un número, incluso si se le llama "la carga del servidor", en realidad no significa mucho

Así que ya que su servidor es rápido y puedo ver sus respuestas foro rápido, el problema es sólo virtual - no hay ningún problema real. La carga del servidor es el valor que le da ninguna información sobre el desempeño real, sólo sirve para indicar si usted sabe cómo interpretarlo (es decir, si el servidor está funcionando bien con la carga del servidor X, entonces se puede empezar a comprobar lo que está pasando, si es que crece rápidamente a 2X o algo así). Sólo número estático que no da nada, mejor control de la CPU y la memoria para asegurarse de que este valor es correcto para su servidor y si está bien, entonces no importa qué servidor es el valor de carga.

Sin embargo, si usted quiere algunos consejos adicionales:
- Hacer más grande caché TTL Si la ha cambiado para bajar (por defecto es el máximo permitido por la TOS de Google).
- Si usted no tiene problemas de espacio en disco duro apagar las tareas cron para la limpieza de caché de invitados - que no tiene que ser limpiado del todo, ya que actualiza los resultados según sea necesario, aún mucho de la eliminación de los archivos antiguos pueden tener realmente mucho tiempo para php.
- El uso de la memoria caché
- Al final (pero realmente no veo sentido de que, debido a que no tienen problema de rendimiento) comienzan desactivar idiomas que le da menos tráfico

Por cierto - lo que es la carga del servidor, media de CPU y memoria, y qué hardware tiene usted (el número de CPU, memoria)? ¿Tiene el archivo de intercambio se utiliza?

Simon Lloyd
27-05-11, 08:34
A continuación se presentan los detalles de acuerdo a sus preguntas
1) Carga del servidor
*********************
08:22:53 hasta 44 días, 13:31, 1 usuario, load average: 4.07, 5.09, 5.26
TTY USUARIO DE LOGIN @ IDLE PCPU JCPU QUÉ
raíz pts / 2 08:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2) uso de CPU y memoria
********************
total utilizado buffers compartidos en caché libre
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) cómo muchas CPU
3

EDIT: acaba de tomar una instantánea aquí http://www.thecodecage.com/forumz/server.png mi servidor es así todo el tiempo, la instantánea se Después de habilitar memcahce.

Simon Lloyd
27-05-11, 17:19
Como información añadida aquí está el registro de los procesos principales:
xxxx 93,0% / usr / bin / php / home / xxxx / public_html / forumz / vbenterprisetranslator_seo.php
xxxx 83,0% / usr / bin / php / home / xxxx / public_html / forumz / vbenterprisetranslator_seo.php
xxxx 75,0% / usr / bin / php / home / xxxx / public_html / forumz / vbenterprisetranslator_seo.php
MySQL 6.8% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- cierre
MySQL 6.7% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- cierre
MySQL 6.6% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- cierre
raíz de un 6,0% / bin / sh / usr / local / bin / rkhunter-c - cronjob

vBET
29-05-11, 20:52
A continuación se presentan los detalles de acuerdo a sus preguntas
1) Carga del servidor
*********************
08:22:53 hasta 44 días, 13:31, 1 usuario, load average: 4.07, 5.09, 5.26
TTY USUARIO DE LOGIN @ IDLE PCPU JCPU QUÉ
raíz pts / 2 08:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2) uso de CPU y memoria
********************
total utilizado buffers compartidos en caché libre
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) cómo muchas CPU
3

EDIT: acaba de tomar una instantánea aquí http://www.thecodecage.com/forumz/server.png mi servidor es así todo el tiempo, la instantánea se Después de habilitar memcahce.

No estoy seguro de cómo interpretar las mediciones. Como veo que la CPU se utiliza en alrededor de 185% ... Así que o hay algo bien caliente en la medida o se aplica a una CPU - si usted tiene 3, puede utilizar un 300%. Si ésta es la manera correcta, entonces esto significa que usted tiene todavía gran cantidad de recursos de la CPU libre. Si no es así por favor me corrijan y decir cómo interpretar los resultados.

Tampoco estoy seguro de cómo interpretar los datos de la carga del servidor:

carga media: 4,07, 5,09, 5,26
Son los tres diferentes medidas de tiempo, o cada uno es para CPU por separado? ¿Cuál es la potencia de su CPU?

PS. Caché necesita tiempo para llenar pulg

Simon Lloyd
29-05-11, 21:54
Michal, de nuevo gracias por la respuesta de la carga promedio que ve (y en la foto) cambia cada vez que se actualiza, es como usted señala una serie sybmolic, cuando la carga promedio demostrado que hay alrededor de 6 o 7, entonces el sitio es lento pero la mayoría de las veces no responde a su vez, da un error.

Aquí están los datos de la CPU que usted pidió
Procesador # 1
Vendedor
GenuineIntel
Nombre
Intel (R) Xeon (R) CPU X3430@2.40GHz
Velocidad
2394.030 MHz
Cache
8192 KB

Cuando compruebo en WHM tengo una cpu de cuatro núcleos, mientras que el servidor de la gente me dice que tengo 3 CPU??

No sé ni pretendo saber cómo el promedio de la carga del servidor es elaborado (últimamente, en los últimos dos días ha sido en torno a:
Promedios de carga: 4,49 4,04 3,95

Foro es de velocidad media y no parece ser la causa de un problema en este momento, aunque el tráfico es de alrededor de:
271 (3 120 miembros e invitados y arañas 148)
Donde la figura superior es normalmente alrededor de 500 a 600, pero entonces es el fin de semana para que el tráfico es menor.

vBET
02-06-11, 23:23
Le pregunté acerca de la velocidad de la CPU, ya que como hemos dicho ya la carga del servidor es de valor virtual, así que para la carga del servidor CPU en mismo va a significar algo más que para la CPU lenta (rápida que va a hacer su trabajo rápido, por lo que incluso si hay tareas adicionales de espera en la cola de los que serán tratados más rápido).
Acerca de su número de CPU - en este momento estoy perdido como tú. Es su servidor y yo no le ayudará a determinar qué tienes 1 o 3 CPUs. Les puedo decir que para los servidores que es mejor tener una cantidad más grande de una CPU lenta que la menor cantidad de más rápido. 2 +2 = 5 significa que dos procesadores con fuerza de 2 va a hacer un mejor trabajo que un procesador con potencia de 4, porque el servidor tiene muchas tareas pequeñas, y tener un procesador que no puede hacerlo de forma paralela.
La carga del servidor también tienen un significado diferente según el número de procesadores. Si realmente tiene tres procesadores rápidos entonces la carga del servidor 6 (total no por CPU) está bien, incluso sin comprobación adicional. Si usted tiene un procesador de entonces, además, debe comprobar el tiempo de respuesta real para nuestros alcantarillado. Como usted escribió ya lo hizo y que está bien.

Por el tiempo que ver la carga del servidor es más grande y más lento página (un caché - por favor, recuerde que para que no caché el tiempo de respuesta real no depende de su servidor en todo, pero hasta el momento la respuesta de Google), compruebe que es más grande porque el tráfico , o tal vez es porque de algunas tareas de fondo (como trabajos de cron vBulletin, o incluso su propio sistema operativo - como las tareas de actualización automática, o algo así).

De acuerdo a su respuesta anterior - si no hay un verdadero problema - ¿Necesita alguna ayuda en el futuro en este tema en este momento?

Simon Lloyd
04-06-11, 08:46
Michal, gracias por la respuesta detallada, que es de 4 cpu, mi única preocupación es la cantidad de% de cpu que VBET consume, mientras escribo esto hay son 3 procesos se muestra en la TOP de VBET el 55%, 52% y 48% de la CPU y estos procesos son para el archivo / vbenterprisetranslator_seo.php, si no hay nada más se puede sugerir entonces le doy las gracias por sus comentarios y tendrá que vivir con ella como yo sin duda no puede permitirse otro movimiento de servidor o actualizar como me pasó de tener vps a una máquina virtual en cloud hosting dedicado a fin de mantener VBET en marcha, el siguiente ir al núcleo cuádruple doble (8 CPU) está fuera de mi alcance.

vBET
04-06-11, 21:03
Tenga en cuenta que lo que ou se ve no es el consumo de CPU VBT, pero el consumo de todo el foro. vbenterprisetranslator_seo.php no hace nada - sólo establece algunas variables internas y se redirigen a archivo muy solicitado - es sólo controlador frontal. Todas las solicitudes se va a vbenterprisetranslator_seo.php - lo tienes configurado en tu archivo htaccess..

Por lo que este no es el consumo VBET - esto es el consumo de todo el foro. Para las páginas normales VBET no hace nada - sólo añade banderas. De páginas traducidas proceso de traducción ocurre lo que el consumo de CPU será siempre mayor que el de la página normal, debido a que ocurre después de una página normal se genera. Por lo tanto la generación normal de primero que pasa y entonces el resultado traducido es - lo que no hay posibilidad de tener que withour costo adicional. O ... Tenemos una solución para esta hormiga que se llama memoria caché de los clientes - para personas de páginas enteras se almacenan en caché y no pasa de traducción, siempre y cuando caché no vencido. Así que si usted ya está utilizando la caché Invitado entonces VBET no tienen soluciones más para hacer traducciones con menos recursos. Sólo se pueden desactivar algunas de las traducciones - tendrá entonces menos tráfico de páginas traducidas por lo menos el consumo de recursos para las traducciones.

Hemos hecho mucho esfuerzo para VBET perfiles, el cambio de algoritmos, añadiendo más mejoras en el rendimiento. Y nunca tratamos este tema como cerrado. Sin embargo, en este momento, incluso con varias capas de caché, estamos trabajando con la aplicación que tienen muchos cambios y distintos contenidos de la misma URL en función de los Grupos de Usuarios de usuario, o incluso para cada usuario (si algún plugin añade cosas) y esto requiere volver a traducir a cada sesión a petición del usuario. Para los usuarios registrador sólo puede almacenar en caché traducciones pena, pero las páginas no se entera como para los usuarios. Tenga en cuenta que VBET está agregando más y más mejoras en el rendimiento - todavía usted nunca tendrá traducciones mágica sin consumo de recursos. La funcionalidad adicional siempre significa el consumo de recursos adicionales.

Nos marchamos el tiempo de respuesta del foro y es realmente bueno. Así que no iba a pensar en cambiar a otro servidor en este momento. Tal y como lo escribió - todavía tiene la mitad de los recursos libres. Usted paga por estos recursos lo que no tiene nada de malo usarlo. Y aún se encuentra en zona de seguridad - por lo que incluso cuando el tráfico aumenta el foro de respuesta en un tiempo apropiado. Para la luz la primera CPU es de 70% del uso de medios (no sólo en algún momento - promedio). Esta es la primera señal de que preocuparse acerca de los recursos. Si usted ignora esto, entonces el 90% del consumo promedio de CPU significa leer la luz, alarma, y las necesidades inmediatas para mejorar - de lo contrario, incluso el tráfico poco más puede hacer que la degradación del rendimiento drásticas. Para la memoria es diferente y depende de la configuración del sistema operativo para intercambio.

Y como PS - por favor considere soluciones como VPS - donde usted puede agregar recursos muy fácil, sin volver a instalar:)

Si usted ya todos los resultados en barbecho pistas luego lo único que queda por hacer es desactivar algunos idiomas y actualizaciones de VBET como los que vienen.

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
vBET 4.10.1 gives automatic translations