VBET HØY CPU / Minnebruk grunn mysql

[magmf]

Guys,

Jeg trenger virkelig har vbet mer optimalisert for min nettside.

VBet er å få meg masse nye brukere jeg virkelig likte verktøy, men bruker for mange ressurser.


Min cpu belastning før VBET var Bellow 2 og nå er mer enn 4 all time

nå for eksempel
08:32:18 up 11 dager, 02:27, 1 bruker, last gjennomsnitt: 7,45, 8,24, 8,26

vedlagte få billetter fra før og etter vbet aktivert i min nettside


Jeg ønsker å dele deg at jeg hoppet fra 70.000 sider indeksert på google til mer enn 500.000

min rangering på alexa hoppet også
Under-linux.org - Site Info fra Alexa (http://www.alexa.com/siteinfo/under-linux.org)

og jeg får flere besøk hver dag, men jeg trenger fremdeles en bedre optimalisering av hvordan vbet håndtak med spørringer.

ta en titt på toppen min



top - 08:53:46 up 11 days, 2:49, 1 user, load average: 10.77, 9.81, 9.06
Tasks: 423 total, 5 running, 418 sleeping, 0 stopped, 0 zombie
Cpu(s): 15.7%us, 2.4%sy, 0.0%ni, 66.6%id, 9.8%wa, 0.1%hi, 5.4%si, 0.0%st
Mem: 12330536k total, 11619688k used, 710848k free, 24064k buffers
Swap: 995988k total, 994972k used, 1016k free, 2917568k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29384 mysql 20 0 5722m 2.5g 4552 S 99 20.9 3661:46 mysqld



som du kan se mysql på toppen på grunn av vbet


mysql show processlist;



mysql> show processlist;
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
| Id | User | Host | db | Command | Time | State | Info |
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
| 3102552 | underlinux | localhost:49801 | underlinux | Query | 16 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102570 | underlinux | localhost:49843 | underlinux | Query | 12 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102597 | underlinux | localhost:49901 | underlinux | Query | 9 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102600 | underlinux | localhost:49907 | underlinux | Query | 9 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102617 | underlinux | localhost:49944 | underlinux | Query | 6 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102620 | underlinux | localhost:49953 | underlinux | Query | 6 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102632 | underlinux | localhost:49986 | underlinux | Query | 3 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102633 | underlinux | localhost:49988 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102636 | underlinux | localhost:49994 | underlinux | Sleep | 1 | | NULL |
| 3102639 | underlinux | localhost:50000 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102641 | underlinux | localhost:50005 | underlinux | Query | 0 | Sending data | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102648 | underlinux | localhost:50021 | underlinux | Sleep | 1 | | NULL |
| 3102649 | underlinux | localhost:50022 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102651 | root | localhost | NULL | Query | 0 | NULL | show processlist |
| 3102652 | underlinux | localhost:50027 | underlinux | Query | 0 | statistics | SELECT translated FROM vbvbenterprisetranslator_cache_medium_vi WHERE originaltext='Cadastrar+200+cl |
| 3102660 | underlinux | localhost:50044 | underlinux | Query | 0 | statistics | SELECT translated FROM vbvbenterprisetranslator_cache_medium_fa WHERE originaltext='BackTrack+4+%28F |
| 3102661 | underlinux | localhost:50047 | underlinux | Query | 0 | statistics | SELECT cache.originaltext as originaltext, cache.translated as translated FROM vbvbenterprisetransla |
| 3102663 | underlinux | localhost:50051 | underlinux | Sleep | 1 | | NULL |
| 3102664 | underlinux | localhost:50052 | underlinux | Query | 1 | end | UPDATE vbuser SET
profilevisits = profilevisits + 1
WHERE userid = 61484 |
| 3102666 | underlinux | localhost:50056 | underlinux | Query | 0 | update | REPLACE INTO vbdatastore
(title, data, unserialize)
VALUES
('cron', '1275652500', 0) |
+********-+************+****************-+************+********-+****--+************--+****************************************************************************************************--+
20 rows in set (0.16 sec)

mysql>




mysql og CPU-bruk før og etter vbet

http://under-linux.org/wiki/images/1/14/Mysql-vbet.png

http://under-linux.org/wiki/images/f/f0/Vbetmysql2.png

http://under-linux.org/wiki/images/6/65/Vbet-cpuusage.png

[vBET]

Hallo.

Som du skrev vBET gav deg mye ny trafikk. Så sammenligner CPU og mem bruk før og etter vBET, er virkelig sammenligne CPU og mem bruk før og etter å ha større trafikk ...
Så denne sammenligningen ikke er hensiktsmessig. Det er ingen mulighet for å ha samme ressursbruk med større trafikk. Også oppmerksom på at vBET praktisk talt tar ingen ressurser for normal sider (kun genererer flagg) slik at alle dine ekstra ressursbruk kommer fra ekstra trafikk - trafikken til oversatt sider. Mer trafikk = flere ressurser som trengs

Vær oppmerksom på at vBET spørringer er optimalisert, er alle Bruke indekser og ta alle data i noen spørringer. Vennligst sjekk din treg spørsmål logg for å bestemme hva som virkelig tar det meste av din MySQL tid. Også - du kan alltid bygge indekser i tilfelle hvis noe krasjet i MySQL DB.

Fortell hva er størrelsen på cache bordene? Også må du fortelle hvilken versjon av vBET bruker dere og gi din forumet URL.

Vennligst sjekk våre prestasjoner hint: http://www.vbenterprisetranslator.com/forum/vbet4-general-discussions/408-vbet-performance.html

Selvfølgelig er vi bedre vBET kontinuerlig. I neste hovedversjon vil vi støtte file cache:) Så ytelse forbedringer vil skje:) Fremdeles vær oppmerksom på at din måte sammenligning er ikke hensiktsmessig, og viser ikke hvor mye mer ressurser tar vBET - det viser hvor mye mer ressurser ditt forum tar med større trafikk.

[magmf]

vBET,

filhurtigbufferen eller mysql ikke bufret søk bruker mye I / O gjør enhet belastning være høy.

Mitt forslag til deg er bruke Memcache å cache istedenfor o-fil og mysql eller koble vbet med vboptimise som allerede har støtte for mange typer cacher

eksempel på bruk vboptimise med vbet vil være noe sånt


if ($cache = vb_optimise::$cache->get('unique language key'))
{
***//use cache
}
else
{
***// get from elsewhere
***vb_optimise::$cache->set('unique language key');
}



hvorfor du ikke prøve snakke med Deceptor fra DragonByte Tech Forum - DragonByte Technologies Home (http://www.dragonbyte-tech.com/)

mitt nettsted er å spare mer enn 10 millioner søk per dag med vboptimise og hvis du arbeider med ham til bedre støtte vbet alle kan bli lykkelig

ta en titt
BB Optimaliser - Resource Statistics (http://www.dragonbyte-tech.com/vboptimisesites.php)

[vBET]

Takk for dine råd:) jeg får lagt dine siste innlegg på TODO-listen.

Vennligst svar på gitte spørsmål - hva er ditt forum URL og brukes vBET versjon. Vi vil sjekke gjøre du har riktig installasjon - forrige vBET versjoner brukes doble omdirigeringer som ikke brukes lenger, i tilfelle vBSEO det krever hensiktsmessig integrasjon.

[magmf]

webadressen min ikke er under-linux.org
vbet 4.2.2
vBulletin 4.0.3
vBSEO 3,5 finalen

[vBET]

OK - du trenger ikke doble omdirigeringer og siste vBET versjon. På dette tidspunktet kan jeg bare anbefale deg å bruke våre prestasjoner hint (link i første svaret) - spesielt blokk irrelevant innhold i robots.txt - som medlem sider, kalender, og noen andre (merk at disse sidene vil forsvinne fra indekser, men det er bra for SEO, fordi disse er stort sett ansett som innhold duplisering).

Også - hvis serveren skal varme håndtere alle 52 språk - kan du vurdere å deaktivere noen av disse. I dette øyeblikk forstår jeg at den håndterer det, du bare ville være mer fornøyd hvis med mindre ressurser;)

Vi vil også arbeide med å støtte ikke bare filhurtigbufferen, men også eksisterende cache biblioteker:) Takk igjen for tipset ditt.

[magmf]

VBET,

Jeg er bare bekymret med fremtiden. For nå mitt område kan håndtere, men siden vbet jobber jeg kan få mye av nye brukere, og dette kan gjøre min server går ned: (

også er jeg allerede blokkering irrelevant innhold i robots.txt min

[vBET]

Hawing mange nye brukere vil få deg til å tenke på skalerbarhet når du har vBET eller ikke. Vi er virkelig glad for at vBET gir deg mange nye brukere og mulige annonse inntekter:) Som jeg allerede skrev vi vil bedre caching system:)

[vBET]

Neste utgivelse vil ha full filhurtigbufferen som vil gjøre sidene dine generere raskere for gjester - også de som ikke er oversatt:)

[bhanuprasad1981]

Neste utgivelse vil ha full filhurtigbufferen som vil gjøre sidene dine generere raskere for gjester - også de som ikke er oversatt:)

håper vi får denne snart:)

[vBET]

Denne måneden for sikkert:) Full filhurtigbufferen for gjestene arbeider fint på vårt forum, bare ønsker å legge til noen andre nye funksjoner:)

[bhanuprasad1981]

noen oppdateringer:)

[vBET]

I dag skal vi få slippe for vBET3.x - for vBET4.x i første uken i neste måned:)

[bhanuprasad1981]

ohhh no 15 dager mer: (

[vBET]

Vi har mer å gjøre i tilfelle av vB4 (støtte nettadresser + flere typer oversatt linker for vBSEO). Også denne gangen vil gi oss tilbakemelding om denne nye funksjonaliteten (dvs. at vi allerede fått ideen fra én bruker til å tillate å deaktivere den for normal sider). Så det vil ta litt mer tid, men på slutten vil du få løsning som er bedre testet og med ekstra funksjoner:)