Necesita axuda reducindo a carga do servidor

[Simon Lloyd]

Ola, estou tendo problemas coa miña carga do servidor, i xa se mudaron para dedicado a intentar curar iso, pero aínda recibir carga de servidores de alto, se eu desactivar pingas de carga vbet o servidor.

Alguén pode axudar?

@ Kamil, xa ten detalles pleno acceso que lle foi enviado en AM se queres comprobar.

[kamilkurczak]

Ola,
aquí tes unha lista de consellos vBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html

Lembre-se - se ten todos os idiomas habilitados - ten contido máis 53 (threads, etc artigos) no seu foro e, por suposto, o tráfico de alta foro.

Pode desactivar algunhas linguas e esperar cando de caché para a linguaxe activa será cuberto, despois de que - vostede pode activar a próxima parte de traducións.

En segundo lugar, neste relase temos unha gran mellora (un grande) - este é o sistema de caché (4 opcións diferentes). Podes comprobar-lo no seu caché-AdminCP> vBET. (Teña en conta que - ten que integrar o seu servidor para usar este tipo de caché)

:)

[Simon Lloyd]

Eu apliquei todo o que podo de recomendacións do seu desempeño, i tamén tiveron todas as linguas habilitado (a maioría tamén) dende a compra de vbet preto de 6 meses, a carga é sempre elevado o tempo. Como para o caché de memoria (beta) eu non creo que eu teño ningún acelerador de caché no meu servidor, pero evrything outra é definida de acordo coas súas instrucións.

[kamilkurczak]

da nosa última relase traballamos no sistema de caché de memoria - este debe ser o único gran no desempeño. Debe ter o teu servidor configurado con este sistema de caché (se cadra xa ten - pregunta ó seu apoio ao servidor)

[Simon Lloyd]

Ola Kamil, eu verifiquei só php info e eu non teño, pero vou leva-los a instalar xcache ou algo así

[vBET]

Oi Por que ten problemas coa carga do servidor? Eu vexo o seu foro é traducir moi rápido, entón onde está o problema?

Ten en conta que as traducións son feitas por servizos externos de Google. Isto significa que cando ocorre a súa tradución segmentos están agardando resposta de Google. E é por iso que o teu servidor de carga é maior, pero non afectan o sistema, porque os segmentos de espera non tomar ningunha CPU nin memoria adicional (só xa utilizado). É por iso que sempre terá maior carga Server con vBET habilitado (cando desactivado ningún segmento está á espera de resultados de Google) e na mesma hora o seu foro aínda está a traballar rápido, porque os segmentos de espera non tomar ningunha CPU.

Así que se trata de precisaba tomar mozo Carga Server é para garantir que threads non esperará a resultados de Google pero, desgraciadamente, Google permite a caché teus resultados só para 15 días. Podes probar por si mesmo - se desactivar caché, ou só facer o seu tempo de vida menor, entón vai se Carga do servidor crecente - porque os resultados serán menos caché e máis peticións en espera de respostas de Google. Non hai máxica - traducións vén dalgún lugar e leva tempo para obtelo de Google.

Usando caché de memoria pode axudar dalgunha forma. Threads que esperan por resultados de Google aínda vai estar esperando (non vai pasalo ata que teña gardada todas as traducións, e non vai, porque é limpo de acordo co CHOS de Google). Resultados aínda almacenados en memoria serán xerados máis rápido, así o solicite, non esperando por traducións vai ir máis rápido da cola de solicitudes.

Aquí podes atopar o que é exactamente a carga do servidor é: carga Server (http://whreviews.com/server-load.htm) e descubrir que, mentres ten carga do servidor liberar recursos non é un problema.

Sabendo que o valor da carga do servidor non é moi importante aínda. Saber como interpretar o valor é o que conta.

Lembre-se a definición: a carga do servidor representa o número de procesos esperando para acceder a CPU. Pero non todos os procesos son os mesmos! Se os procesos son de baixa prioridade, cando unha solicitude de novo servidor (solicitude de páxina) aparece, aínda pode ser tratado case instantaneamente.

Sen esquecer que a carga do servidor é só un factor entre moitos outros (uso de memoria, uso de CPU, tamaño do ficheiro de intercambio)

Como de costume, e como moitas persoas directamente implicadas na empresa de hospedaxe dicir, todo se reduce a vida real comportamento. Son as páxinas carga rápido? Será que un proceso como a investigación a través de unha base de datos de levar un tempo razoable? Entón realmente non ten un problema, sexa cal sexa a carga do servidor é

Así, o exame final é o xeito que o servidor se comporta. Se o servidor é rápido, un número, aínda que sexa coñecido como "a carga do servidor", realmente non significa moito

Entón porque o seu servidor é rápido e podo ver as respostas do seu foro rápido, o problema é só virtual - non hai ningún problema real. Carga do servidor é o valor que lle dá ningunha información sobre o desempeño real, só consellos se sabe como interpretar la (é dicir, se o servidor está funcionando ben coa carga do servidor X, entón podes comezar a comprobar o que está a suceder, se crece rapidamente para 2X ou algo así). Só o número estática dálle nada, mellor comprobar o seu CPU e memoria para estar seguro de que este valor é OK para o teu servidor e se é OK, entón non importa o valor do servidor de carga é.

Aínda así, se queres algunhas suxestións adicionais:
- Facer caché maior TTL trasladouse a abaixo (o estándar é máximo permitido por Google CHOS).
- Se non ten problemas de espazo HDD desactivar tarefa cron para a limpeza de caché invitado - non ten que ser limpo de todo, porque refresca resultados conforme a necesidade, aínda moi a eliminación dos arquivos anteriores levar moito tempo para php.
- Caché de memoria usan
- Ao final (pero realmente non vexo sentido niso, porque non hai ningún problema de rendemento) comezan a desactivar as linguas que lle dá menos tráfico

Polo camiño - cal é a súa carga do servidor, CPUs media e uso de memoria, e que hardware ten (cantos CPUs, memoria)? Fai arquivo de intercambio é usado?

[Simon Lloyd]

Abaixo amósanse os detalles como polas súas preguntas
1) Engade servidor
*********************
08:22:53 ata 44 días, 13:31, 1 usuario, load average: 4,07, 5,09, 5,26
USER TTY FROM LOGIN @ Idle JCPU PCPU QUE
raíz pts / 2 08:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2 CPU) e uso de memoria
********************
total utilizada libre buffers almacenado en memoria compartida
Mem: 4040 3616 424 0 256 2809
- / + Modos / cache: 550 3490
Intercambio: 8001 24 7976
*********************************
3) o número de CPUs
3

Edit: acaba de sacar unha instantánea aquí http://www.thecodecage.com/forumz/server.png meu servidor é así o tempo, iso é instantáneo Tras activar memcahce.

[Simon Lloyd]

Información como engadido aquí está o rexistro Procesos Top:
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 - based / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- bloqueo
mysql 6,7% / usr / sbin / mysqld - based / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- bloqueo
mysql 6,6% / usr / sbin / mysqld - based / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- bloqueo
raíz de 6,0% / bin / sh / usr / local / bin / rkhunter-c - cronjob

[vBET]

Abaixo amósanse os detalles como polas súas preguntas
1) Engade servidor
*********************
08:22:53 ata 44 días, 13:31, 1 usuario, load average: 4,07, 5,09, 5,26
USER TTY FROM LOGIN @ Idle JCPU PCPU QUE
raíz pts / 2 08:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2 CPU) e uso de memoria
********************
total utilizada libre buffers almacenado en memoria compartida
Mem: 4040 3616 424 0 256 2809
- / + Modos / cache: 550 3490
Intercambio: 8001 24 7976
*********************************
3) o número de CPUs
3

Edit: acaba de sacar unha instantánea aquí http://www.thecodecage.com/forumz/server.png meu servidor é así o tempo, iso é instantáneo Tras activar memcahce.

Non sei como interpretar as súas medicións. Como eu vexo o seu CPU é usado en preto de 185% ... Entón, ou hai algo certo quente na medición ou se aplica a unha CPU - se ten 3, entón podes usar 300%. Se este é o camiño correcto, entón isto significa que ten aínda moitos recursos de CPU libre. Se non é por favor me corrixan e dicir como interpretar os resultados.

Eu tampouco estou seguro como interpretar os datos de carga do servidor:

carga media: 4,07, 5,09, 5,26
Son aqueles tres diferentes medidas de tempo, ou cada un é para CPU separado? Cal é o poder do seu CPU?

PS. Cache precisa de tempo para cubrir pol

[Simon Lloyd]

Michal, unha vez máis grazas pola resposta a media de carga que aparecen (e no snapshot) cambia cada vez que actualizar, é como apuntar un número sybmolic, cando as medias de carga mostrada hai uns 6 ou 7, a continuación, o sitio é lento pero a maioría das veces sen resposta, que á súa vez dá un erro.

Aquí tes os datos que pediu CPU
Procesador # 1
Vendedor
GenuineIntel
Nome
Intel (R) Xeon (R) CPU X3430@2.40GHz
Velocidade
2394.030 MHz
Agocho
8192 KB

Cando o check-in WHM eu teño un CPU quad core, mentres a xente servidor me dicir que eu teño tres CPU é?

Eu non sei ou finxir saber a media de carga do servidor é traballada (ultimamente, nos últimos dous días foi en torno a:
Medias de carga: 4,49 4,04 3,95

Foro é de velocidade media e non parece estar causando un problema, aínda que o tráfico é de preto de:
271 (3 membros e 120 invitados e 148 arañas)
Onde a figura máis é normalmente en torno a 500-600, pero entón é fin de semana para o tráfico é menor.

[vBET]

Eu preguntei sobre a velocidade da CPU, porque como xa dixen a carga do servidor é só o valor virtual, de xeito rápido para a carga do servidor mesmo CPU vai significar algo máis que para CPU lenta (fast un fará o seu traballo de xeito rápido, por iso mesmo se hai procesos adicionais á espera na cola estes serán tratados rápido).
Sobre o seu número de CPUs - Actualmente eu estou perdido coma ti. É o teu servidor e non vou axudar a determinar que ten 1 ou 3 CPUs. Podo dicirlle que para servidores é mellor ter maior cantidade de procesadores máis lentos do que cantidade menor de máis rápido. 2 +2 = 5, significa que 2 procesadores con poder 2 pode facer mellor traballo do que un procesador con potencia 4, xa que o servidor ten moitas pequenas tarefas, e ter un procesador que non pode facer iso forma paralela.
Carga servidor tamén terá significado distinto segundo número de procesadores. Se realmente ten 3 procesadores rápido, entón a carga do servidor 6 (total e non por CPU) é OK mesmo sen verificación adicional. Se ten un procesador, entón ten que comprobar adicionalmente tempo de resposta real para o noso sumidoiros. Como escribiu que xa fixo iso e é OK.

Para o tempo que ve a súa carga do servidor é maior e máis lento páxina (un caché - lembre que por non almacenada en caché o tempo de resposta real non é ata o servidor en todo, pero ata o tempo de resposta de Google), por favor, lea, porque é grande o tráfico , ou que sexa debido a algunhas tarefas en segundo plano (como o cron vBulletin, ou mesmo o seu propio funcionamento do sistema - como as tarefas de actualización automática ou algo así).

Segundo a súa última resposta - se non hai ningún problema real - precisa de calquera axuda futura neste tema agora?

[Simon Lloyd]

Michal, grazas pola resposta detallada, que é de 4 CPU, a miña única preocupación é a cantidade de% de CPU que vBET consome, como eu tecleo iso, hai are3 procesos descritos no TOP para vBET a 55%, 52% e uso da CPU 48% e eses procesos están todos no ficheiro / vbenterprisetranslator_seo.php, se non hai nada máis pode suxerir, entón eu agradezo polos seus comentarios e terá que vivir con el como eu sempre non poden pagar un outro movemento servidor ou actualizar como eu fun de VPS para unha máquina virtual en nube para Aloxamento dedicada, co fin de manter vBET en execución, o próximo salto quad core dual (8 CPU) é da miña franxa de prezo.

[vBET]

Ten en conta que o que UO ver que non é o consumo de CPU VBT, pero o seu consumo foro enteiro. vbenterprisetranslator_seo.php non fai nada - só define algunhas variables e fixo redirección interno para o arquivo realmente solicitada - é só controlador de fronte. Todas as solicitudes vai para vbenterprisetranslator_seo.php - tes define-lo no seu arquivo htaccess ..

Polo tanto, este non é o consumo vBET - que é o teu consumo foro enteiro. Para as páxinas normais vBET non fai nada - só engade bandeiras. Para páxinas traducidas proceso de tradución enteiro se produce así o consumo de CPU será sempre maior que a páxina normal, porque ocorre tras páxina normal é xerada. Así, a xeración normal primeiro lugar e despois resultado é traducido - por iso non hai posibilidade de te-lo withour custo adicional. Ou ... Temos solución para esta formiga chámase caché de Clientes - para os hóspedes páxinas enteiras se almacenan en memoria e ningunha tradución acontece mentres caché non caducado. Entón, se xa está usando caché Visitante vBET entón non teñen máis solucións para facer traducións utilizando menos recursos. Só se pode desactivar algunhas traducións - terá tráfico, entón menos a páxinas traducidas consumo de recursos de forma menos para as traducións.

Fixemos moito esforzo para vBET perfil, mudando algoritmos, engadindo máis melloras de rendemento. E nunca tratamos esta cuestión como pechada. Aínda así, neste momento, mesmo con varias capas de caché, estamos a traballar con aplicación que ten moitos cambios e contidos diferentes para mesma URL dependendo de Grupos de usuarios, ou mesmo para cada usuario (se algún plugin engade esas cousas) e iso require retraduzir para cada solicitude do usuario rexistrado. Para o usuario Loggia só podemos caché de traducións sentenza, pero as páxinas non todo como para os usuarios. Teña en conta que vBET está engadindo melloras de rendemento cada vez máis - aínda que nunca vai ter traducións máxica sen consumo de recursos. Funcionalidade adicional sempre significa o consumo de recursos adicionais.

Analizar o seu tempo de resposta do foro e é realmente bo. Entón, eu non pensaría en cambiar a outro servidor neste momento. Así como escribiu - aínda ten a metade dos recursos libres. Paga para iso recursos para que haxa nada de malo usalo. E aínda está na zona de seguridade - por iso mesmo cando o tráfico aumenta o seu foro de resposta en tempo axeitado. Para CPU primeira luz é do 70% de uso medio (non só nalgún momento - media). Esta primeira Consello é preocuparse dos recursos. Se ignorar isto, entón o 90% do consumo medio de CPU significa lectura lixeira, alarma, e as necesidades inmediatas para upgrade - doutro xeito, mesmo o tráfico de pouco máis pode facer a degradación do desempeño drasticamente. Para a memoria é diferente e depende de configuración mínimos para SWAP.

E como PS - por favor, considere solucións como VPS - onde podes engadir recursos moi fácil, sen reinstalar:)

Se xa pousio todo o desempeño consellos entón único que queda é desactivar algúns idiomas e fixo actualizacións de vBET como aquelas vir.