Necessita ajuda per reduir la càrrega del servidor

[Simon Lloyd]

Hola, Tinc problemes amb el meu càrrega del servidor, i ja s'han traslladat a la dedicada a tractar de guarir això, però tot i així obtenir altes càrregues de servidor, si puc desactivar VBET cau la càrrega del servidor.

Pot algú ajudar?

@ Kamil, que ja té tots els detalls d'accés que li lliurin en PM si vol comprovar.

[kamilkurczak]

hola,
Aquí tens una llista de suggeriments VBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html

Recordi - si vostè té tots els idiomes habilitats - que tenen un contingut de 53 més (fils, etc missatges) en el seu fòrum, i el fòrum, és clar, d'alt trànsit.

Pot desactivar algunes llengües i esperar quan la memòria cau d'idioma habilitat estarà ple, després d'això - es pot activar la següent part de les traduccions.

En segon lloc, en aquest relase tenim una gran millora (molt gran) - aquest és el sistema de memòria cau (4 opcions diferents). Es pot comprovar en la seva AdminCP-> Memòria cau VBET. (Recordeu - ha d'integrar el servidor per utilitzar aquest tipus de memòria cau)

:)

[Simon Lloyd]

M'han posat en pràctica tot el que pugui de les recomanacions del seu rendiment, també he tingut tots els idiomes habilitats (més bé), ja que la compra de VBET al voltant de 6 mesos, la càrrega és sempre alta tot el temps. Quant a la memòria cau (beta) i no crec que tingui accelerador memòria cau en el meu servidor, però evrything més s'ajusta d'acord a les seves instruccions.

[kamilkurczak]

des de la nostra darrera relase hem treballat en aquest sistema de memòria cau - això ha de ser la més gran en el rendiment. Cal tenir configurat el servidor amb aquest sistema de memòria cau (que per tant ja té - pregunti al seu suport per al servidor)

[Simon Lloyd]

Hola Kamil, Acabo de comprovar php info i jo no el tinc, però vaig a arribar a instal lar XCache o alguna cosa així

[vBET]

Hola. Per què tens problemes amb la càrrega del servidor? Puc veure el seu fòrum s'està traduint realment ràpid, així que on és el problema?

Tingueu en compte que les traduccions són fetes pels serveis externs de Google. Això vol dir que quan passa la traducció de les discussions estan a l'espera de la resposta de Google. I és per això que la càrrega del servidor és més gran, però no influeix en el sistema, perquè els fils esperant prendre sense CPU ni memòria addicional (només utilitzat ja). Així que és per això que sempre tindrà una major càrrega de servidors amb VBET habilitada (discapacitats sense fil està a l'espera dels resultats de Google) i en el mateix temps per provar el fòrum seguirà treballant ràpid, perquè els fils esperant no prendre cap CPU.

Llavors, què és realment necessària per prendre amant de càrrega del servidor és assegurar que les discussions no van a esperar els resultats de Google, però malauradament Google permet emmagatzemar en memòria cau seus resultats només per 15 dies. Pot fer-ho per un mateix - si està desactivada la memòria cau, o simplement fer el seu temps de vida més petita que es carrega en si del servidor cada vegada més gran - ja que menys resultats s'emmagatzemen a la memòria cau i més sol.licituds en espera de respostes de Google. No hi ha màgia - traduccions ve d'alguna part i es necessita temps per arribar des de Google.

L'ús de la memòria cau pot ajudar d'alguna manera. Subprocessos en espera dels resultats de Google encara s'espera (que no ho passen fins que s'hagi emmagatzemat en memòria cau totes les traduccions, i no perquè es neteja d'acord amb TOS de Google). Resultats encara emmagatzemat en memòria cau es genera més ràpid, pel que demana no esperar que les traduccions es vagi més ràpid de la cua de peticions.

Aquí pot trobar exactament el que la càrrega del servidor és: la càrrega del servidor (http://whreviews.com/server-load.htm) i descobrir que tot el temps que tenen la càrrega del servidor sense recursos no és un problema.

Saber quin és el valor de la càrrega del servidor no és molt important, però. Saber interpretar el valor és el que compta.

recordar la definició: la càrrega del servidor representa el nombre de processos en espera per accedir a la CPU. Però no tots els processos són els mateixos! Si els processos són de baixa prioritat, quan una sol licitud de nou servidor (sol.licitud de la pàgina) apareix, encara pot ser manejat gairebé a l'instant.

Per no parlar que la càrrega del servidor és només un factor de molts altres (ús de memòria, ús de CPU, mida del fitxer d'intercanvi)

Com de costum, i com moltes persones directament implicades en el negoci de hosting dir, tot es redueix a la vida real el comportament. Són les pàgines de càrrega ràpida? Té un procés com la recerca a través d'una base de dades de prendre un temps raonable? Llavors vostè realment no té un problema, sigui quina sigui la càrrega del servidor és

Per tant, la prova definitiva és la manera com es comporta el servidor. Si el servidor és ràpid, un nombre, encara que se l'anomena "la càrrega del servidor", en realitat no significa molt

Així que ja que el servidor és ràpid i puc veure les seves respostes fòrum ràpid, el problema és només virtual - no hi ha cap problema real. La càrrega del servidor és el valor que li dóna cap informació sobre l'acompliment real, només serveix per indicar si vostè sap com interpretar (és a dir, si el servidor està funcionant bé amb la càrrega del servidor X, llavors es pot començar a comprovar el que està passant, si és que creix ràpidament a 2X o alguna cosa així). Només nombre estàtic que no dóna res, millor control de la CPU i la memòria per assegurar-se que aquest valor és correcte pel vostre servidor i si està bé, llavors no importa quin servidor és el valor de càrrega.

No obstant això, si vostè vol alguns consells addicionals:
- Fer més gran memòria cau TTL Si l'ha canviat per baixar (per defecte és el màxim permès per la TOS de Google).
- Si no té problemes d'espai en disc dur apagar les tasques cron per a la neteja de memòria cau de convidats - que no ha de ser netejat del tot, ja que actualitza els resultats segons sigui necessari, encara molt de l'eliminació dels arxius antics poden tenir realment molt de temps per php.
- L'ús de la memòria cau
- Al final (però realment no veig sentit que, pel fet que no tenen problema de rendiment) comencen desactivar idiomes que li dóna menys trànsit

Per cert - el que és la càrrega del servidor, mitjana de CPU i memòria, i quin maquinari té vostè (el nombre de CPU, memòria)? Té l'arxiu d'intercanvi s'utilitza?

[Simon Lloyd]

A continuació es presenten els detalls d'acord a les seves preguntes
1) Càrrega del servidor
*********************
8:22:53 fins a 44 dies, 13:31, 1 usuari, load average: 04/07, 05/09, 26/05
TTY USUARI DE LOGIN @ IDLE PCPU JCPU QUÈ
arrel pts / 2 8:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2) ús de CPU i memòria
********************
total utilitzat buffers compartits en memòria cau lliure
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) com moltes CPU
3

EDIT: acaba de prendre una instantània aquí http://www.thecodecage.com/forumz/server.png meu servidor és així tot el temps, la instantània es Després d'habilitar memcahce.

[Simon Lloyd]

Com a informació afegida aquí hi ha el registre dels processos principals:
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- tancament
MySQL 6.7% / usr / sbin / mysqld - based / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- tancament
MySQL 6.6% / usr / sbin / mysqld - based / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-external- tancament
arran d'un 6,0% / bin / sh / usr / local / bin / rkhunter-c - cronjob

[vBET]

A continuació es presenten els detalls d'acord a les seves preguntes
1) Càrrega del servidor
*********************
8:22:53 fins a 44 dies, 13:31, 1 usuari, load average: 04/07, 05/09, 26/05
TTY USUARI DE LOGIN @ IDLE PCPU JCPU QUÈ
arrel pts / 2 8:17 0.00s 1.53s datacenter1.supp 0.00sw
****************
2) ús de CPU i memòria
********************
total utilitzat buffers compartits en memòria cau lliure
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) com moltes CPU
3

EDIT: acaba de prendre una instantània aquí http://www.thecodecage.com/forumz/server.png meu servidor és així tot el temps, la instantània es Després d'habilitar memcahce.

No estic segur de com interpretar les mesures. Com veig que la CPU s'utilitza en al voltant de 185% ... Així que o hi ha alguna cosa ben calent en la mesura o s'aplica a una CPU - si vostè té 3, pot utilitzar un 300%. Si aquesta és la manera correcta, llavors això vol dir que vostè té encara gran quantitat de recursos de la CPU lliure. Si no és així si us plau em corregeixin i dir com interpretar els resultats.

Tampoc estic segur de com interpretar les dades de la càrrega del servidor:

càrrega mitjana: 4,07, 5,09, 5,26
Són els tres diferents mesures de temps, o cada un és per CPU per separat? Quina és la potència de la vostra CPU?

PS. Memòria cau necessita temps per omplir polz

[Simon Lloyd]

Michal, de nou gràcies per la resposta de la càrrega mitjana que veu (i a la foto) canvia cada vegada que s'actualitza, és com vostè assenyala una sèrie sybmolic, quan la càrrega mitjana demostrat que hi ha al voltant de 6 o 7, llavors el lloc és lent però la majoria de les vegades no respon al seu torn, dóna un error.

Aquí hi ha les dades de la CPU que vostè va demanar
Processador # 1
Venedor
GenuineIntel
Nom
Intel (R) Xeon (R) CPU X3430@2.40GHz
Velocitat
2394.030 MHz
Cache
8192 KB

Quan comprovo en WHM tinc una cpu de quatre nuclis, mentre que el servidor de la gent em diu que tinc 3 CPU??

No sé ni pretenc saber com la mitjana de la càrrega del servidor és elaborat (últimament, en els últims dos dies ha estat al voltant de:
Mitjanes de càrrega: 4,49 4,04 3,95

Fòrum és de velocitat mitjana i no sembla ser la causa d'un problema en aquest moment, tot i que el trànsit és d'al voltant de:
271 (3 120 membres i convidats i aranyes 148)
On la figura superior és normalment al voltant de 500 a 600, però llavors és el cap de setmana perquè el trànsit és menor.

[vBET]

Li vaig preguntar sobre la velocitat de la CPU, ja que com hem dit ja la càrrega del servidor és el valor virtual, així que per a la càrrega del servidor CPU en mateix significa més que per la CPU lenta (ràpida que farà la seva feina ràpid, de manera que fins i tot si hi ha tasques addicionals en espera a la cua dels que seran tractats més ràpid).
Quant al nombre de CPU - en aquest moment estic perdut com tu. És el seu servidor i jo no l'ajudarà a determinar quins tens 1 o 3 CPU. Els puc dir que per als servidors que és millor tenir una quantitat més gran d'una CPU lenta que el mínim de més ràpid. 2 +2 = 5 significa que dos processadors amb força de 2 farà un millor treball que un processador amb potència de 4, perquè el servidor té moltes tasques petites, i tenir un processador que no pot fer-ho de forma paral.lela.
La càrrega del servidor també tenen un significat diferent segons el nombre de processadors. Si realment té tres processadors ràpids llavors la càrrega del servidor 6 (total no per CPU) està bé, fins i tot sense comprovació addicional. Si vostè té un processador de llavors, a més, ha de comprovar el temps de resposta real per als nostres clavegueram. Com vostè va escriure ja ho va fer i que està bé.

Pel temps a veure la càrrega del servidor és més gran i més lent pàgina (un caixet - si us plau, recordeu que perquè no cau el temps de resposta real no depèn del seu servidor en tot, però fins ara la resposta de Google), comprovi que és més gran perquè el trànsit , o potser és perquè d'algunes tasques de fons (com treballs de cron vBulletin, o fins i tot el seu propi sistema operatiu - com les tasques d'actualització automàtica, o alguna cosa així).

D'acord a la seva resposta anterior - si no hi ha un veritable problema - Necessita alguna ajuda en el futur en aquest tema en aquest moment?

[Simon Lloyd]

Michal, gràcies per la resposta detallada, que és de 4 cpu, la meva única preocupació és la quantitat de% de cpu que VBET consumeix, mentre escric això hi ha són 3 processos es mostra a la TOP de VBET el 55%, 52% i 48% de la CPU i aquests processos són per a l'arxiu / vbenterprisetranslator_seo.php, si no hi ha res més es pot suggerir llavors li dono les gràcies pels seus comentaris i haurà de viure amb ella com jo sens dubte no es pot permetre un altre moviment de servidor o actualitzar com em va passar de tenir vps a una màquina virtual en cloud hosting dedicat per tal de mantenir VBET en marxa, el següent anar al nucli quàdruple doble (8 CPU) està fora del meu abast.

[vBET]

Tingueu en compte que el que ou es veu no és el consum de CPU VBT, però el consum de tot el fòrum. vbenterprisetranslator_seo.php no fa res - només estableix algunes variables internes i es redirigeixen a arxiu molt demanat - és només controlador frontal. Totes les sol.licituds es va a vbenterprisetranslator_seo.php - el tens configurat al teu arxiu htaccess ..

Pel que aquest no és el consum VBET - això és el consum de tot el fòrum. Per a les pàgines normals VBET no fa res - només afegeix banderes. De pàgines traduïdes procés de traducció ocorre el que el consum de CPU serà sempre més gran que el de la pàgina normal, pel fet que passa després d'una pàgina normal es genera. Per tant la generació normal de primer que passa i llavors el resultat traduït és - el que no hi ha possibilitat d'haver de withour cost addicional. O ... Tenim una solució per a aquesta formiga que es diu memòria cau dels clients - a les persones de pàgines senceres s'emmagatzemen a la memòria cau i no passa de traducció, sempre que cau no vençut. Així que si vostè ja està utilitzant la memòria cau Convidat llavors VBET no tenen solucions més per fer traduccions amb menys recursos. Només es poden desactivar algunes de les traduccions - tindrà llavors menys trànsit de pàgines traduïdes com a mínim el consum de recursos per a les traduccions.

Hem fet molta cura a VBET perfils, el canvi d'algorismes, afegint més millores en el rendiment. I mai tractem aquest tema com tancat. No obstant això, en aquest moment, fins i tot amb diverses capes de memòria cau, estem treballant amb l'aplicació que tenen molts canvis i diferents continguts de la mateixa URL en funció dels Grups d'Usuaris d'usuari, o fins i tot per cada usuari (si algun plugin afegeix coses) i això requereix tornar a traduir a cada sessió a petició de l'usuari. Per als usuaris registrador només pot emmagatzemar en memòria cau traduccions pena, però les pàgines no s'assabenta com per als usuaris. Tingueu en compte que VBET està agregant més i més millores en el rendiment - encara vostè no haurà traduccions màgica sense consum de recursos. La funcionalitat addicional sempre significa el consum de recursos addicionals.

Vam marxar el temps de resposta del fòrum i és realment bo. Així que no havia de pensar en canviar a un altre servidor en aquest moment. Tal i com ho va escriure - encara té la meitat dels recursos lliures. Vostè paga per aquests recursos que no té res de dolent usar-lo. I encara es troba en zona de seguretat - per la qual cosa fins i tot quan el trànsit augmenta el fòrum de resposta en un temps apropiat. Per a la llum la primera CPU és de 70% de l'ús de mitjans (no només en algun moment - mitjana). Aquesta és la primera senyal que preocupar sobre dels recursos. Si vostè ignora això, llavors el 90% del consum mitjà de CPU significa llegir la llum, alarma, i les necessitats immediates per a millorar - en cas contrari, fins i tot el trànsit poc més pot fer que la degradació del rendiment dràstiques. Per a la memòria és diferent i depèn de la configuració del sistema operatiu per intercanvi.

I com PS - si us plau consideri solucions com VPS - on vostè pot afegir recursos molt fàcil, sense tornar a instal lar:)

Si vostè ia tots els resultats en guaret pistes després l'únic que queda per fer és desactivar alguns idiomes i actualitzacions de VBET com els que vénen.