PDA

Gweld Ffurf Llawn: Datrys Angen help i leihau llwyth gweinydd



Simon Lloyd
26-05-11, 08:40
Hi, Im 'yn cael trafferth gyda fy llwyth gweinyddwr, fi eisoes wedi symud i ymrwymo i geisio gwella hyn ond yn dal i gael llwythi gweinyddwr yn uchel, os bydd yn disgyn i analluogi llwyth vbet y gweinydd.

All rhywun helpu?

@ Kamil, mae gennych eisoes manylion mynediad llawn a anfonwyd atoch yn PM os ydych am wirio.

kamilkurczak
26-05-11, 20:57
helo,
yma gennych chi restr o awgrymiadau vBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html

cofiwch - os oes gennych yr holl ieithoedd alluogi - eich bod wedi cynnwys 53 mwy (edafedd, swyddi ac ati) ar eich fforwm, ac wrth gwrs, uchel-draffig fforwm.

Gallwch analluogi rhai ieithoedd ac aros pryd y cache ar gyfer iaith galluogi i'w llenwi, ar ôl hynny - gallwch chi alluogi rhan nesaf o gyfieithiadau.

Yn ail, Yn y relase gennym mawr gwella (un fawr iawn) - mae hyn yn System cache chof (4 opsiynau gwahanol). Gallwch wirio yn eich admincp-> Cache vBET. (Cofiwch - mae'n rhaid i chi integreiddio eich gweinydd ddefnyddio'r math hwn o cache)

:)

Simon Lloyd
26-05-11, 22:15
Rwyf wedi rhoi ar waith i gyd y gall fi eich argymhellion perfformiad, fi hefyd wedi galluogi pob iaith (mae'r rhan fwyaf yn dda) ers brynu vbet tua 6 mis yn ôl, mae'r llwyth yn gyson uchel drwy'r amser. Fel ar gyfer y Cache Chof (beta) Dydw i ddim yn meddwl i chi unrhyw sbardun cache acha 'm gweinyddwr ond evrything arall wedi ei osod yn unol â'ch cyfarwyddiadau.

kamilkurczak
26-05-11, 22:19
gan ein relase diwethaf buom yn gweithio ar y cache chof system - dylai hyn fod yn un mawr mewn perfformiad. Mae angen i chi gael eich gweinydd ffurfweddu gyda'r system hon cache (efallai sydd gennych eisoes - gofynnwch i'ch cefnogi gweinyddwr)

Simon Lloyd
26-05-11, 22:31
Hi Kamil, fi jyst gwirio php gwybodaeth ac nid fi yn ei gael, ond bydd fi eu cael i osod xcache neu rywbeth tebyg

vBET
26-05-11, 22:59
Hi. Pam ydych yn cael trafferth gyda'ch llwyth gweinyddwr? Gwelaf eich fforwm yn cyfieithu mewn gwirionedd gyflym, felly os yw'r broblem?

Sylwer y cyfieithiadau yn cael eu gwneud gan wasanaethau allanol gan Google. Mae hyn yn golygu pan fydd cyfieithiad yn digwydd eich edafedd yn aros am ymateb gan Google. A dyna pam mae eich Llwyth Gweinyddwr yn fwy, ond nid yw'n dylanwadu ar y system, gan fod edafedd yn aros yn cymryd unrhyw CPU na cof ychwanegol (yn unig a ddefnyddir yn barod). Felly dyna pam y byddwch bob amser yn cael Llwytho Gweinyddwr uwch gyda vBET galluogi (pan anabl dim edau yn aros am ganlyniadau oddi wrth Google) ac mewn un pryd, bydd eich fforwm yn dal i weithio yn gyflym, gan fod edafedd yn aros yn cymryd unrhyw CPU.

Felly, beth sydd ei angen mewn gwirionedd i gymryd gariad Llwyth Gweinyddwr yw sicrhau na fydd edafedd aros am ganlyniadau oddi wrth Google, ond yn anffodus Google yn caniatáu i cache ei ganlyniadau yn unig am 15 diwrnod. Gallwch roi cynnig arni eich hun - os byddwch yn analluogi cache, neu ddim ond gwneud ei amser i fyw llai o faint, yna byddwch yn Load Gweinyddwr se tyfu - oherwydd y bydd llai o ganlyniadau cael eu cached ac yn fwy cheisiadau sy'n aros am ymatebion Google. Nid oes unrhyw hud - cyfieithiadau dod o rywle ac mae'n cymryd amser i'w gael gan Google.

Gall defnyddio cache chof helpu mewn rhyw ffordd. Bydd Trywyddau aros am ganlyniadau Google yn dal i fod yn aros (ni fyddwch ei drosglwyddo hyd nes eich bod wedi cached holl gyfieithiadau, ac nid ydych fydd am ei fod yn cael ei lanhau yn ôl TOS Google). Bydd y canlyniadau yn dal i gael ei gynhyrchu cached gyflymach, felly bydd ceisiadau ni aros am gyfieithiadau fynd yn gyflymach o geisiadau ciw.

Yma, gallwch gael gwybod beth yn union yw llwyth gweinydd: llwyth Server (http://whreviews.com/server-load.htm) ac yn darganfod nad yw ar yr amod eich bod wedi Load Gweinyddwr adnoddau rhad ac am ddim yn broblem.

Gwybod beth yw gwerth y llwyth gweinydd yn bwysig iawn er. Mae gwybod sut i ddehongli'r gwerth yn yr hyn sy'n cyfrif.

cofiwch y diffiniad: y llwyth gweinydd yn cynrychioli nifer o brosesau sy'n aros i gael mynediad i'r CPU. Ond nid yw pob brosesau yr un peth! Os bydd y prosesau yn flaenoriaeth isel, pan fydd cais weinydd newydd (cais tudalen) yn ymddangos, gall fod yn dal i gael ei drin bron yn syth.

Heb sôn am fod y llwyth gweinydd ond yn un ffactor y tu allan i llawer o bobl eraill (, chof chynefod defnydd CPU, maint y ffeil cyfnewid)

Fel arfer, ac fel y mae llawer o bobl yn uniongyrchol gysylltiedig yn y busnes cynnal ddweud, mae'r cyfan yn dod i lawr i fywyd go-iawn ymddygiad. A yw'r tudalennau llwytho yn gyflym? A yw proses fel chwilio drwy gronfa ddata gymryd amser rhesymol? Yna, nad ydych chi wir yn cael problem, beth bynnag yw'r llwyth gweinydd yw

Felly, mae'r prawf yn y pen draw yw'r ffordd y mae'r gweinydd yn ymddwyn. Os bydd y gweinyddwr yn gyflym, mae nifer, hyd yn oed os mai enw "llwyth gweinyddwr", mewn gwirionedd yn golygu llawer o

Felly, oherwydd bod eich gweinydd yn gyflym ac rwy'n gallu gweld eich ymatebion fforwm gyflym, eich mater yn unig rhithwir - nid oes unrhyw broblem go iawn. Llwyth Gweinydd yn werth sydd yn rhoi unrhyw wybodaeth am berfformiad go iawn, dim ond awgrymiadau os ydych yn gwybod sut i ddehongli (hy os gweinydd yn rhedeg yn dda gyda llwyth X gweinyddwr, yna gallwch ddechrau edrych ar beth sy'n digwydd, os yw'n gyflym tyfu i 2X neu rywbeth fel 'na). Dim ond nifer sefydlog yn rhoi dim byd i chi, gwiriwch eich well CPU a chof i fod yn siŵr bod y gwerth yn iawn ar gyfer eich gweinydd ac os yn iawn, yna beth bynnag Gweinyddwr Llwyth werth ei.

Yn dal os ydych am rai awgrymiadau ychwanegol:
- Gwneud mwy cache TTL os ydych wedi newid i is (diofyn yw uchafswm a ganiateir gan TOS Google).
- Os nad oes gennych faterion lle HDD diffoddwch dasg cron ar gyfer glanhau cache gwadd - nid oes raid i gael eu glanhau o gwbl, gan y gall ei adnewyddu canlyniadau yn ôl yr angen, yn dal i gael gwared llawer o hen ffeiliau yn cymryd amser hir iawn ar gyfer php.
- Defnydd storfa cof
- Ar y diwedd (ond Fi 'n sylweddol ddim yn gweld unrhyw synnwyr ohono, oherwydd nad oes gennych fater perfformiad) dechrau anablu ieithoedd sy'n rhoi llai o drafnidiaeth

Gyda llaw - beth yw eich, Load Server CPU cyfartalog a chof chynefod, a beth chaledwedd sydd gennych (faint o CPUs, cof)? A yw'r ffeil cyfnewid yn cael ei ddefnyddio?

Simon Lloyd
27-05-11, 08:34
Yn dilyn eu manylion yn unol â'ch cwestiynau
Llwyth Gweinydd 1)
*********************
08:22:53 hyd 44 diwrnod, 13:31, 1 defnyddiwr, ar gyfartaledd llwyth: 4.07, 5.09, 5.26
DEFNYDDIWR O'R TTY LOGIN @ Idle JCPU PCPU BETH
gwraidd pts / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) CPU a chof chynefod
********************
cyfanswm a ddefnyddir byfferau a rennir am ddim cached
Mem: 4040 3616 424 0 256 2809
- / + Byfferau / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) faint o CPUs
3

Golygu: dim ond cymryd cipolwg yma http://www.thecodecage.com/forumz/server.png fy gweinyddwr fel hyn drwy'r amser, mae hyn yn ÔL ciplun galluogi memcahce.

Simon Lloyd
27-05-11, 17:19
Gwybodaeth ychwanegu fel yma yn y log Prosesau 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
75.0% xxxx / usr / bin / php / home / xxxx / public_html / forumz / vbenterprisetranslator_seo.php
6.8% mysql / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - sgip-allanol- cloi
6.7% mysql / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - sgip-allanol- cloi
6.6% mysql / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - sgip-allanol- cloi
gwraidd 6.0% / bin / sh / usr / local / bin / rkhunter-c - cronjob

vBET
29-05-11, 20:52
Yn dilyn eu manylion yn unol â'ch cwestiynau
Llwyth Gweinydd 1)
*********************
08:22:53 hyd 44 diwrnod, 13:31, 1 defnyddiwr, ar gyfartaledd llwyth: 4.07, 5.09, 5.26
DEFNYDDIWR O'R TTY LOGIN @ Idle JCPU PCPU BETH
gwraidd pts / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) CPU a chof chynefod
********************
cyfanswm a ddefnyddir byfferau a rennir am ddim cached
Mem: 4040 3616 424 0 256 2809
- / + Byfferau / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) faint o CPUs
3

Golygu: dim ond cymryd cipolwg yma http://www.thecodecage.com/forumz/server.png fy gweinyddwr fel hyn drwy'r amser, mae hyn yn ÔL ciplun galluogi memcahce.

Dydw i ddim yn siwr sut i ddehongli eich mesuriadau. Wrth i mi weld eich CPU yn cael ei ddefnyddio mewn tua 185% ... Felly, neu os oes rhywbeth yn iawn boeth yn mesur neu y mae'n berthnasol i 1 CPU - os oes gennych 3, yna gallwch ddefnyddio 300%. Os yw hyn yn ffordd gywir, yna mae'n golygu eich bod wedi dal i lawer o adnoddau CPU rhad ac am ddim. Os nad ydych yn gywir i mi ac yn dweud sut i ddehongli'r canlyniadau.

Dwi ddim yn siwr hefyd sut i ddehongli eich data llwyth gweinydd:

llwyth ar gyfartaledd: 4.07, 5.09, 5.26
A yw'r rhai a 3 gwahanol mewn mesuriadau amser, neu bob un ar gyfer CPU ar wahân? Beth yw nerth eich CPU?

PS. Cache angen amser i'w llenwi i mewn

Simon Lloyd
29-05-11, 21:54
Michal, unwaith eto diolch am yr ateb y cyfartaledd llwyth welwch chi (ac yn y ciplun) yn newid bob tro y byddwch yn adnewyddu, mae'n wrth i chi nodi nifer sybmolic, pan fydd y cyfartaleddau llwyth a ddangosir, mae tua 6 neu 7, yna y safle yn araf ond mae'r rhan fwyaf o'r amser beidio ag ymateb sydd yn ei dro yn rhoi camgymeriad.

Dyma y data cpu rydych chi wedi gofyn am
Prosesydd # 1
Gwerthwr
GenuineIntel
Enw
Intel (R) Xeon (R) CPU X3430@2.40GHz
Cyflymder
2394.030 MHz
Cache
8192 KB

Wrth i wirio yn WHM fi wedi 1 cwad cpu craidd, tra bod y bobl gweinydd dweud wrthyf fi wedi 3 cpu ei???

Dydw i ddim yn gwybod neu esgus wybod sut mae'r gweinydd cyfartaledd llwyth yn cael ei weithio allan (yn ddiweddar, dros y 2 diwrnod diwethaf mae wedi bod o gwmpas:
Cyfartaleddau Llwyth: 4.49 4.04 3.95

Fforwm o gyflymder cyfartalog ac nid yw'n ymddangos i fod yn fater sy'n achosi hyn o bryd, er bod traffig o gwmpas:
271 (3 aelodau a gwesteion 120 a 148 pryfed cop)
Pan fydd y ffigwr uchaf fel arfer tua 500-600, ond yna mae'n penwythnos mor traffig yn is.

vBET
02-06-11, 23:23
Gofynnais am gyflymder CPU, oherwydd bod gan ein bod eisoes wedi dweud Llwyth Gweinyddwr yn unig yw gwerth rhith, felly ar gyfer llwyth gweinyddwr un CPU gyflym y bydd yn golygu rhywbeth arall nag ar gyfer CPU araf (gyflym bydd un yn gwneud ei gwaith yn gyflym, felly hyd yn oed os oes tasgau ychwanegol aros mewn ciw bydd y rhai sy'n cael eu trin yn gyflym).
Am eich nifer o CPUs - ar hyn o bryd rwy'n colli yn union fel chi. Mae'n eich gweinydd ac ni fyddaf yn eich helpu i benderfynu a oes gennych 1 neu 3 CPUs. Gallaf ddweud wrthych fod ar gyfer gweinyddion ei fod yn well cael mwy o faint CPUs arafach na swm llai o gyflymach. 2 2 = 5, mae'n golygu y bydd 2 proseswyr â phŵer 2 yn gwneud gwaith yn well na 1 processor gyda phŵer 4, oherwydd bod gweinyddwr wedi lawer o dasgau bach, ac ar ôl 1 prosesydd nad ydych yn gallu ei wneud ffordd cyfochrog.
Bydd Llwyth Gweinyddwr hefyd yn cael ystyr wahanol yn ôl nifer o broseswyr. Os ydych yn wirioneddol wedi 3 phroseswyr gyflym wedyn 6 (cyfanswm nid fesul CPU) llwyth gweinydd yn iawn hyd yn oed heb wirio ychwanegol. Os oes gennych 1 processor, yna dylech chi hefyd wirio amser ymateb gwirioneddol ar gyfer ein carthffosydd. Wrth i chi ysgrifennu eich bod eisoes yn gwneud hynny ac mae'n iawn.

Ar gyfer tro y byddwch yn gweld eich llwyth gweinydd yn fwy ac yn dudalen arafach (un cached - cofiwch am beidio cached nid yw'r amser ymateb gwirioneddol hyd at eich gweinyddwr o gwbl, ond hyd at amser ymateb Google), os gwelwch yn dda siec yn cael ei oherwydd traffig yn fwy , neu efallai ei fod oherwydd bod rhai tasgau gefndir (megis swyddi cron vBulletin, neu hyd yn oed eich system weithredu eich hun - fel tasgau diweddaru awtomatig neu rywbeth fel 'na).

Yn ôl eich ymateb olaf - os nad oes unrhyw broblem go iawn - a oes angen unrhyw gymorth yn y dyfodol yn y pwnc hwn ar hyn o bryd?

Simon Lloyd
04-06-11, 08:46
Michal, diolch am yr ymateb manwl, mae'n 4 cpu, yn fy unig bryder yw faint o% o cpu y vBET yn defnyddio, fel fi math hwn mae are3 prosesau a ddangosir yn TOP am vBET yn 55%, 52% a defnydd cpu 48% a'r prosesau hyn i gyd ar gyfer y ffeil / vbenterprisetranslator_seo.php, os nad oes unrhyw beth mwy y gallwch chi awgrymu wedyn i ddiolch i chi am eich sylwadau a bydd yn rhaid i ni fyw ag ef fel fi na all fforddio bendant yn symud weinydd arall neu uwchraddio fel ff fynd o gael VPS i VM mewn cwmwl gynnal i neilltuo er mwyn cadw vBET rhedeg, y naid nesaf i craidd quad deuol (8 cpu yn) allan o fy amrediad prisiau.

vBET
04-06-11, 21:03
Nodwch nad yw yr hyn a ou gweld ei bod yn yfed CPU vBT ond eich defnydd o fforwm cyfan. vbenterprisetranslator_seo.php yn gwneud dim - dim ond yn gosod rhai newidynnau a gwneud mewnol ailgyfeirio i ffeilio cais mewn gwirionedd - mae yr un rheolwr blaen. Pob cais yn mynd i vbenterprisetranslator_seo.php - rydych wedi eu gosod yn eich ffeil htaccess..

Felly, nid yw hyn yn ddefnydd vBET - mae hyn yn eich defnydd o fforwm cyfan. Ar gyfer tudalennau arferol vBET yn gwneud dim - dim ond yn ychwanegu baneri. Ar gyfer cyfieithu tudalennau broses gyfieithu gyfan fydd yn digwydd felly bydd defnydd CPU yn wastad yn fwy nag ar gyfer dudalen arferol, gan ei fod yn digwydd ar ôl i dudalen arferol yn cael ei gynhyrchu. Felly cenhedlaeth gyntaf arferol fydd yn digwydd ac yna canlyniad yn cael ei gyfieithu - felly nid oes unrhyw gyfle i gael ei withour gost ychwanegol. Neu ... Rydym wedi ateb ar gyfer y morgrugyn mae'n cael ei enwi Cache Guest - ar gyfer gwesteion tudalennau cyfan yn cael eu cached a dim cyfieithiad yn digwydd ar yr amod nad oedd yn dod i ben cache. Felly, os ydych eisoes yn defnyddio Cache Guest yna vBET nad oes atebion mwy i wneud cyfieithiadau gan ddefnyddio llai o adnoddau. Gallwch ond analluogi rhai cyfieithiadau - bydd yn rhaid draffig yna lai i dudalennau gyfieithu defnydd o adnoddau er mwyn llai ar gyfer cyfieithiadau.

Rydym yn gwneud llawer o ymdrech i vBET proffilio, newid algorithmau, gan ychwanegu gwelliannau perfformiad yn fwy. Byth Ac rydym yn trin y mater hwn fel gau. Yn dal ar hyn o bryd hyd yn oed gyda sawl haen o cache, rydym yn gweithio gyda'r cais sydd â llawer o newidiadau ac yn cynnwys gwahanol ar gyfer yr un URL dibynnu o Usergroups defnyddiwr, neu hyd yn oed ar gyfer pob defnyddiwr (os oes rhai plugin yn ychwanegu pethau o'r fath) ac mae hyn yn ei gwneud yn ofynnol retranslate ar gyfer pob cais wedi mewngofnodi defnyddwyr. Ar gyfer defnyddwyr cofnodydd ni allwn ond cache cyfieithiadau dedfryd, ond nid tudalennau cyfan yn hoffi i ddefnyddwyr. Nodwch fod vBET yn ychwanegu gwelliannau perfformiad yn fwy a mwy - yn dal i byth byddwch yn cael cyfieithiadau hudol gyda dim defnydd o adnoddau. Ymarferoldeb ychwanegol bob amser yn golygu defnydd o adnoddau ychwanegol.

Rydym yn gwirio eich fforwm amser ymateb ac mae'n dda iawn. Felly ni fyddwn yn meddwl am newid i gweinydd eraill ar hyn o bryd. Yn union fel chi ysgrifennu - rydych yn dal i gael hanner yr adnoddau rhad ac am ddim. Rydych yn talu am hyn adnoddau fel nad oes dim o'i le i'w ddefnyddio. A ydych yn dal yn y parth diogel - felly hyd yn oed pan fydd eich traffig yn cynyddu bydd eich fforwm ymateb mewn amser priodol. Am CPU golau cyntaf yw 70% o'r defnydd cyfartalog (nid dim ond mewn rhai hyn o bryd - ar gyfartaledd). Mae hyn yn awgrym cyntaf i chi boeni am adnoddau. Os ydych yn anwybyddu hyn wedyn yn 90% o ddefnydd CPU cyfartalog yn golygu darllen ysgafn, larwm, ac mae angen ar unwaith i uwchraddio - fel arall, gall hyd yn oed ychydig mwy o draffig yn gwneud diraddio perfformiad llym. Er cof ei bod yn wahanol ac mae'n dibynnu ar leoliadau AO ar gyfer SWAP.

Ac fel PS - os gwelwch yn dda ystyried atebion fel Datganiad Personol Dioddefwr - lle gallwch ychwanegu adnoddau yn hawdd iawn heb unrhyw ailosod:)

Os ydych eisoes yn fraenar pob perfformiad awgrymiadau, yna beth yn unig y chwith i analluogi rhai ieithoedd a wneir diweddariadau o vBET fel y rhai yn dod.

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