Het jy hulp nodig by die bediener belasting te verminder

[Simon Lloyd]

Hi, Ek het probleme met my server load, ek het reeds verskuif toegewyde om te probeer om dit te genees nie, maar nog steeds 'n groot bediener vragte, as ek vbet die bediener lading druppels afskakel.

Kan iemand help?

@ Kamil, jy het reeds volle toegang besonderhede aan u gestuur word in 'n PM as jy wil gaan.

[kamilkurczak]

Hallo,
Hier het jy 'n vBET lys van wenke: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html

Onthou - as jy al die tale in staat gestel - jy het 53 meer inhoud (drade, poste, ens.) op jou forum, en natuurlik baie verkeer forum.

Jy kan afskakel sommige tale en wag wanneer die kas vir die enabled taal sal gevul word, daarna - jy kan die volgende deel van die vertalings in staat stel.

In die tweede plek, In hierdie Communique ons het 'n groot verbetering van (baie groot een) - dit is' n geheue kas stelsel (4 verskillende opsies). Jy kan dit besigtig in jou admincp-> vBET Cache. (Onthou - jy moet jou bediener te integreer om hierdie soort kas te gebruik)

:)

[Simon Lloyd]

Ek het almal geïmplementeer wat ek kan van jou prestasie aanbevelings, ek ook het al die tale in staat gestel (asook die meeste) sedert die koop vbet ongeveer 6 maande gelede, het die vrag is konsekwent hoë al die tyd. Soos vir die geheue kas (beta) Ek dink nie ek het enige kas versneller op my server, maar evrything anders is soos per jou instruksies nie.

[kamilkurczak]

van ons laaste Communique het ons gewerk het op hierdie geheue kas - Dit moet die groot een in die prestasie. Jy moet jou bediener ingestel met hierdie kas (miskien het jy reeds het - vra jou bediener ondersteuning)

[Simon Lloyd]

Hi Kamil, ek het net nagegaan PHP Info en ek het dit nie doen nie, maar Ek sal hulle xcache of iets soos dit te installeer

[vBET]

Hi. Hoekom het jy moeilikheid met jou server load? Ek sien jou forum is regtig vinnig vertaling, so waar is die probleem?

Neem asseblief kennis dat vertalings gemaak word deur eksterne dienste van Google word. Dit beteken dat wanneer die vertaling gebeur jou drade wag vir reaksie van Google. En dit is waarom jou server load is groter, maar dit beteken nie die stelsel beïnvloed, omdat wag drade geen SVE of addisionele geheue (net reeds gebruik). So dit is hoekom jy altyd 'n hoër server load met vBET aangeskakel (as die afgeskakel geen draad is wag vir die resultate van Google) en in dieselfde tyd sal jou forum werk nog steeds vinnig, want wag drade neem nie CPU.

So, wat is regtig nodig is om die server load minnaar te neem, is om te verseker dat die drade nie wag vir die resultate van Google, maar Google kan ongelukkig sy resultate te kas net vir 15 dae. Jy kan probeer om dit self - as jy dit afskakel kas, of net maak sy tyd om te lewe kleiner, dan sal jy se server load groei - omdat minder resultate sal Cached en meer versoeke wag vir Google antwoorde. Daar is geen magic - vertalings van êrens kom, en dit neem tyd om dit te kry van Google.

Die gebruik van geheue kas kan help in die een of ander manier. Threads wag vir die Google-resultate sal wag nog steeds (jy sal dit nie slaag nie, totdat jy Cached alle vertalings, en jy sal nie, want dit is skoongemaak volgens Google TOS). Tog Cached resultate vinniger gegenereer word, sodat versoeke nie wag vir vertalings gaan vinniger van versoeke queue.

Hier kan jy vind uit wat presies server load: server load (http://whreviews.com/server-load.htm) en vind uit dat so lank as wat jy het vrye bronne server load nie 'n kwessie.

Weet wat die waarde van die server load nie al is baie belangrik. Weet hoe om die waarde te interpreteer is wat tel.

onthou die definisie: die bediener belasting verteenwoordig die aantal prosesse wat wag om toegang te verkry tot die SVE. Maar nie al die prosesse is dieselfde! As die prosesse is lae prioriteit, wanneer 'n nuwe bediener versoek (bladsy versoek) verskyn, kan dit nog hanteer word byna dadelik.

Nie te praat van dat die server load is net een faktor van baie ander (geheue gebruik, CPU gebruik, die grootte van swap file)

Soos gewoonlik, en soos baie mense wat direk betrokke is by die aanbieding besigheid sê, dit kom alles neer op die werklike lewe gedrag. Is die bladsye laai vinnig? Is 'n proses soos deur' n databasis 'n redelike tyd neem te soek? Dan is jy regtig nie 'n probleem het, ongeag die server load

So, die uiteindelike toets is die manier waarop die bediener optree. Indien die bediener is vinnig, 'n nommer, selfs al is dit bekend as "server load", regtig nie veel beteken nie

Omdat jou bediener is vinnig en ek kan sien jou forum antwoorde vinnig nie, jou probleem is net virtuele - daar is geen werklike probleem. Server load waarde wat jy gee geen inligting oor die werklike prestasie, net wenke as jy weet hoe om dit te interpreteer (dws as bediener is goed met die bediener vrag X, dan kan jy begin nagaan wat aangaan, indien dit vinnig groei tot 2x of so iets). Net statiese nommer kry jy niks beter check jou geheue en verwerker prosesse om seker te wees dat hierdie waarde OK is vir jou bediener en as dit OK dan nie saak watter server load waarde is.

Tog as jy wil 'n paar ekstra wenke:
- Maak groter kas TTL indien u dit te verlaag (standaard is die maksimum wat toegelaat word deur Google TOS).
- As jy geen HDD ruimte kwessies af cron taak vir die skoonmaak van gas kas - dit hoef nie skoongemaak moet word op alle nie, omdat dit bygewerk resultate as dit nodig is, nog steeds die verwydering van baie van die ou lêers kan baie lang tyd neem vir PHP.
- Gebruik geheue kas
- Aan die einde (maar ek sien geen sin van dit, omdat jy nie ding probleem het) begin aanskakel tale wat gee jou minder verkeer

By the way - Wat is jou server load, gemiddelde CPU en geheue gebruik, en watter hardeware het jy (hoeveel CPU, geheue) nie? Is swap file gebruik word?

[Simon Lloyd]

Volgende is die besonderhede soos per jou vrae
1) server load
*********************
08:22:53 tot 44 dae, 13:31, 1 gebruiker, vrag gemiddeld: 4,07, 5,09, 5,26
USER TTY van LOGIN @ ledig JCPU PCPU WAT
wortel-punte / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) SVE en geheue gebruik
********************
totale gebruik gratis gedeel buffers Cached
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) hoe baie CPUs
3

EDIT: net 'n momentopname hier http://www.thecodecage.com/forumz/server.png my bediener het, is soos dit al die tyd hierdie momentopname is na' n staat te stel memcahce.

[Simon Lloyd]

Soos bygevoeg inligting hier is die Top prosesse log:
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-eksterne- locking
mysql 6,7% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-eksterne locking
mysql 6,6% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-eksterne- locking
wortel 6,0% / bin / sh / usr / local / bin / rkhunter-C - cronjob

[vBET]

Volgende is die besonderhede soos per jou vrae
1) server load
*********************
08:22:53 tot 44 dae, 13:31, 1 gebruiker, vrag gemiddeld: 4,07, 5,09, 5,26
USER TTY van LOGIN @ ledig JCPU PCPU WAT
wortel-punte / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) SVE en geheue gebruik
********************
totale gebruik gratis gedeel buffers Cached
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) hoe baie CPUs
3

EDIT: net 'n momentopname hier http://www.thecodecage.com/forumz/server.png my bediener het, is soos dit al die tyd hierdie momentopname is na' n staat te stel memcahce.

Ek is nie seker hoe om jou metings te interpreteer. As ek sien jou CPU gebruik word in so 'n 185% ... So of daar is iets warm reg in meting of dit van toepassing op 1 CPU is - as jy 3 dan kan jy 300% gebruik. As dit is regte manier dan beteken dit dat jy nog steeds het baie van die vrye SVE hulpbronne. Indien dit nie die korrekte my en vertel hoe om die resultate te interpreteer.

Ek is ook nie seker hoe om jou server load data te interpreteer:

Gemiddeld: 4,07, 5,09, 5,26 laai
Is daardie 3 verskillende in die tyd metings, of elke een is vir 'n aparte CPU nie? Wat is die krag van jou CPU?

PS. Cache moet tyd te vul.

[Simon Lloyd]

Migal, dankie vir die antwoord van die vrag gemiddelde wat jy sien (en in die momentopname) verander elke keer as jy verfris weer, dit is as jy wys 'n sybmolic nommer, wanneer die las gemiddeldes getoon is daar ongeveer 6 of 7 dan die site is stadig maar die meeste van die tyd reageer nie, wat op sy beurt gee 'n fout.

Hier is die SVE data wat jy gevra het vir
Verwerkingseenheid # 1
Vendor
GenuineIntel
Naam
Intel (R) Xeon (R) CPU X3430@2.40GHz
Spoed
2394.030 MHz
Cache
8192 KB

Wanneer ek kyk in WHM Ek het 1 quad core CPU, terwyl die bediener sê mense vir my ek het 3 CPU's???

Ek weet nie of voorgee om te weet hoe die server load gemiddeld uitgewerk (die afgelope tyd, oor die afgelope 2 dae dit al:
Load Gemiddeldes: 4,49 4,04 3,95

Forum is van die gemiddelde spoed en dit lyk nie te wees veroorsaak 'n probleem op die oomblik, alhoewel die verkeer rond is:
271 (3 lede en 120 gaste en 148 Spiders)
Waar die boonste syfer is gewoonlik ongeveer 500 - 600, maar dan is dit naweek so verkeer is laer.

[vBET]

Ek het gevra oor die SVE se spoed, want soos ons reeds gesê bediener belasting is net 'n virtuele waarde, so vir' n vinnige SVE dieselfde server load sal iets anders as vir die stadige CPU (vinnig een sal doen om sy werk vas, so dat selfs al is daar addisionele take wag queue dié sal vinnig hanteer word).
Oor jou nommer van SVE's - op hierdie oomblik is ek net soos jy verloor. Dit is jou bediener en ek sal nie help om jou om te bepaal doen jy het 1 of 3 CPUs nie. Ek kan jou vertel dat vir bedieners is dit beter om groter hoeveelheid stadiger CPUs as 'n kleiner bedrag van vinniger. 2 +2 = 5 dit beteken dat die 2 verwerkers met krag 2 sal beter werk as 1 verwerker met krag 4 kan doen, want die bediener het baie van die klein take en met 1 verwerker jy kan nie dit parallelle manier doen.
Server load sal ook ander betekenis volgens die aantal verwerkers. As jy regtig het 3 vinnige verwerkers, dan server load 6 (totaal nie per CPU) is OK, selfs sonder verdere kontrole. As jy het 1 verwerker, dan moet jy addisioneel check werklike reaksie tyd vir ons riool. Soos wat jy geskryf het, het jy reeds dit gedoen het en dit is OK.

Want die tyd is jy sien jou server load is groter en bladsy stadiger (Cached een - Onthou dat die werklike reaksie tyd vir nie Cached is nie tot jou bediener, maar Google reaksie tyd), kan u tjek is dit omdat groter verkeer , of miskien is dit as gevolg van 'n paar agtergrond take (soos vBulletin cron jobs, of selfs jou eie operasie stelsel - soos outomatiese update take of iets soos dit).

Volgens jou laaste antwoord - as daar geen werklike probleem - het jy nodig om enige toekomstige hulp in hierdie onderwerp nou?

[Simon Lloyd]

Migal, dankie vir die gedetailleerde reaksie, dit is 4 CPU se, my enigste bekommernis is die bedrag van% van die SVE dat vBET verbruik, as ek tik dit daar are3 prosesse wat in die top vir vBET 55%, 52% en 48% CPU gebruik. en die prosesse is al vir die lêer / vbenterprisetranslator_seo.php, as daar niks meer kan jy dan raai ek dank jou vir jou kommentaar en sal hê om daarmee saam te leef as wat ek kan beslis nie 'n ander bediener beweeg kan bekostig nie of op te gradeer, as ek gaan uit met VPS aan 'n VM in wolk hosting toegewyde in die oog te hou vBET hardloop, die volgende Spring na dual quad core (8 CPU's) is buite my prysklas.

[vBET]

Let asseblief daarop dat wat ou sien dit is nie vBT CPU verbruik, maar jou hele forum verbruik. vbenterprisetranslator_seo.php doen niks - net stelle veranderlikes en interne redirect na regtig verlangde lêer gemaak - dit is net die voorkant kontroleerder. Alle versoeke om te vbenterprisetranslator_seo.php gaan - jy het dit in jou htaccess-lêer..

Dit is dus nie vBET verbruik - dit is jou hele forum verbruik. Vir normale bladsye vBET doen niks - voeg net vlae. Vir vertaalde bladsye hele vertaling proses gebeur so CPU verbruik sal altyd groter as vir 'n normale bladsy wees, want dit gebeur na' n normale bladsy gegenereer is. So gebeur die eerste normale generasie en dan gevolg is vertaal - daar is dus geen kans om dit withour bykomende koste. Of ... Ons het die oplossing vir hierdie mier Dit is vernoem Guest Cache - vir gaste hele bladsye Cached en geen vertaling gebeur so lank as die kas het nie verstryk het nie. So as jy reeds Guest Cache gebruik dan vBET het nie meer oplossings vertalings met minder hulpbronne te maak. Jy kan slegs 'n paar vertalings wat - jy sal dan minder verkeer te vertaal bladsye dus minder hulpbron verbruik vir vertalings.

Ons het baie moeite vir die profilering vBET, die verandering van algoritmes, en voeg meer performance verbeteringe. En ons het nooit hanteer hierdie kwessie as afgehandel. Nog steeds op hierdie oomblik, selfs met verskeie lae van die kas, is ons besig met aansoek wat baie veranderinge en die verskillende inhoud vir dieselfde adres afhangende van die gebruiker Gebruikersgroepe, of selfs vir elke gebruiker (as sommige plugin voeg sulke dinge) en dit vereis weer vertaal vir elke aangemeld versoek van die gebruiker. Vir logger gebruiker kan ons net sin vertalings kas, maar nie die hele bladsye soos vir gebruikers. Neem asseblief kennis dat vBET meer en meer performance verbeteringe voeg - nog steeds sal jy nooit magiese vertalings met geen hulpbron verbruik. Bykomende funksionaliteit beteken altyd addisionele hulpbron verbruik.

Ons kyk na jou forum reaksie tyd en dit is regtig goed. Ek sou dus nie dink oor te skakel na ander bediener op hierdie oomblik. Net soos wat jy geskryf het - het jy nog die helfte van hulpbronne gratis. Jy betaal vir hierdie hulpbronne so daar is niks verkeerd om dit te gebruik. En jy is nog steeds in die veilige zone - sodat selfs wanneer jou verkeer verhoog jou forum sal antwoord op 'n gepaste tyd. Vir CPU eerste lig is 70% van die gemiddelde gebruik (nie net in sommige oomblik - gemiddeld). Dit is die eerste wenk hulpbronne te bekommer oor. As jy dit ignoreer, dan 90% van die gemiddelde CPU verbruik beteken die lig, alarm, en onmiddellike behoeftes gelees op te gradeer - anders, selfs bietjie meer verkeer kan 'n drastiese ding vermindering. Vir die geheue is dit anders, en hang af van OS instellings vir SWAP.

En as PS - regstellings soos VPS - waar jy kan byvoeg hulpbronne baie maklik sonder enige weer te installeer:)

As jy reeds braak alle prestasie wenke dan enigste ding wat dit links is sommige tale uit te skakel en updates vBET as diegene wat kom.