Visualizza la versione completa: Risolto Hai bisogno di aiuto riducendo il carico del server
Simon Lloyd
26-05-11, 08:40
Salve, Ho problemi con il mio carico del server, ho già trasferito a dedicato a cercare di curare questo, ma ancora ottenere elevati carichi del server, se i disabilitare vbet gocce di carico del server.
Qualcuno può aiutare?
@ Kamil, hai già dati di accesso completo inviato a te in PM, se si desidera controllare.
kamilkurczak
26-05-11, 20:57
ciao,
Qui avete un elenco di suggerimenti vBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html
Ricordo - se si dispone di tutte le lingue attivate - si dispone di contenuto più 53 (discussioni, messaggi, ecc) sul vostro forum, e, naturalmente, ad alto traffico forum.
È possibile disattivare alcune lingue e aspettare quando la cache di lingua abilitata sarà riempito, dopo che - è possibile attivare la parte successiva delle traduzioni.
In secondo luogo, in questa relase abbiamo un grande miglioramento (molto grande) - questa è la memoria cache di sistema (4 diverse opzioni). Puoi controllare nel pannello admin-> Cache vBET. (Si ricordi - è necessario integrare il vostro server per utilizzare questo tipo di cache)
:)
Simon Lloyd
26-05-11, 22:15
Mi hanno messo in atto tutto ciò che posso della vostra raccomandazioni prestazioni, ho anche avuto tutte le lingue abilitato (ben più) in quanto l'acquisto vbet circa 6 mesi fa, il carico è costantemente alta per tutto il tempo. Per quanto riguarda la cache di memoria (beta) io non credo di avere un acceleratore di cache sul mio server ma evrything il resto è impostato secondo le vostre istruzioni.
kamilkurczak
26-05-11, 22:19
dalla nostra ultima relase abbiamo lavorato su questo sistema di memoria cache - questo dovrebbe essere il grande nelle prestazioni. È necessario avere il vostro server configurato con questo sistema di cache (forse avete già - chiedete al vostro sostegno server)
Simon Lloyd
26-05-11, 22:31
Ciao Kamil, ho appena controllato php info e io non ce l'hanno, ma io li get per installare XCache o qualcosa del genere
Ciao. Perché avete problemi con il carico del server? Vedo il tuo forum è tradurre veramente veloce, quindi dove è il problema?
Si prega di notare che le traduzioni sono fatte da servizi esterni da parte di Google. Questo significa che quando la traduzione succede le discussioni che sono in attesa di risposta da Google. Ed è per questo che il carico del server è più grande, ma non influenzare il sistema, perché i thread in attesa non prendere CPU né memoria aggiuntiva (solo già utilizzato). Ecco perché avrete sempre Server Load superiore con vBET abilitato (quando è disabilitato nessun thread è in attesa di risultati di Google) e nello stesso tempo il vostro forum sarà ancora lavorando velocemente, perché non prendere thread in attesa della CPU.
Quindi, ciò che è veramente necessario per prendere carico amante Server è quello di assicurare che le discussioni non attendere i risultati di Google, ma purtroppo Google consente di memorizzare nella cache i risultati solo per 15 giorni. Potete provare voi stessi - se si disattiva la cache, o semplicemente fare il suo tempo di vivere più piccolo allora si avrà Server Load se in crescita - perché meno risultati saranno memorizzati nella cache e più richieste in attesa delle risposte di Google. Non c'è magia - traduzioni proviene da qualche parte e ci vuole tempo per ottenere da Google.
Utilizzando la cache di memoria può aiutare in qualche modo. Thread in attesa di risultati di Google sarà ancora in attesa (non lo passano prima di aver memorizzato nella cache tutte le traduzioni, e non sarà, perché è pulito secondo Google TOS). Risultati ancora nella cache verrà generato più veloce, ne faccia richiesta senza aspettare le traduzioni più veloce dalla coda di richieste.
Qui potete scoprire che cosa è esattamente il carico del server: il carico del server (http://whreviews.com/server-load.htm) e scoprire che finché si dispone di risorse liberi Server Load non è un problema.
Conoscere ciò che il valore del carico del server non è molto importante però. Saper interpretare il valore è ciò che conta.
ricordare la definizione: il carico del server rappresenta il numero di processi in attesa di accedere alla CPU. Ma non tutti i processi sono uguali! Se i processi a bassa priorità, quando una richiesta di nuovo server (richiesta di pagina) appare, si può comunque gestita quasi istantaneamente.
Senza contare che il carico del server è solo uno dei fattori di molti altri (utilizzo della memoria, l'utilizzo della CPU, la dimensione del file di swap)
Come al solito, e come molte persone direttamente implicate nel commercio di hosting dire, tutto si riduce alla vita reale comportamento. Sono le pagine caricamento veloce? Fa un processo come la ricerca attraverso un database prendere un periodo di tempo ragionevole? Allora non hanno davvero un problema, qualunque sia il carico del server è
Così, l'ultima prova è il modo che il server si comporta. Se il server è veloce, un numero, anche se si chiama "il carico del server", in realtà non significa molto
Perché il server è veloce e riesco a vedere le vostre risposte nel forum veloce, il problema è solo virtuale - non c'è problema reale. Carico del server è il valore che ti dà nessuna informazione sulle prestazioni reali, suggerimenti solo se si sa come interpretarlo (cioè se il server è in esecuzione bene con il carico del server X, allora si può iniziare a controllare cosa sta succedendo, se cresce rapidamente a 2X o qualcosa del genere). Solo numero statico ti dà niente, meglio controllare la CPU e la memoria per essere sicuri che questo valore è OK per il server e se è OK, quindi non importa quale Server valore di carico è.
Comunque se volete alcuni suggerimenti aggiuntivi:
- Rendere più grande la cache TTL se è stata modificata per abbassare (di default è il massimo consentito dalla TOS di Google).
- Se non avete problemi di spazio su HDD spegnere compito cron per la pulizia della cache ospite - che non devono essere puliti a tutti, perché rinfresca i risultati, se necessario, ancora molta la rimozione di vecchi file può richiedere molto tempo davvero lungo per php.
- L'uso della cache di memoria
- Alla fine (ma davvero non vedo il senso di essa, perché non avete problemi di prestazioni) iniziano invalidante lingue che ti dà meno traffico
Tra l'altro - che cosa è il vostro carico del server, medio della CPU e della memoria, e quale hardware hai (quante CPU, memoria)? Il file di swap viene utilizzato?
Simon Lloyd
27-05-11, 08:34
Di seguito sono riportati i dettagli come per le vostre domande
1) Server Load
*********************
08:22:53 fino 44 giorni, 13:31, 1 user, load average: 4.07, 5.09, 5,26
USER TTY FROM LOGIN @ IDLE JCPU PCPU COSA
radice pts / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) CPU e della memoria
********************
totale utilizzata nella cache buffer libero condiviso
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) il numero di CPU
3
EDIT: appena preso una fotografia qui http://www.thecodecage.com/forumz/server.png il mio server è in questo modo tutto il tempo, questa istantanea è dopo l'abilitazione memcahce.
Simon Lloyd
27-05-11, 17:19
Informazioni come aggiunto ecco il log Top Processi:
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-esterno- bloccaggio
mysql 6,7% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-esterno- bloccaggio
mysql 6,6% / usr / sbin / mysqld - basedir / --datadir/var/lib/mysql - usermysql --pid-file/var/lib/mysql/xxxx.thecodecage.com.pid - skip-esterno- bloccaggio
radice 6,0% / bin / sh / usr / local / bin / rkhunter-c - cronjob
Di seguito sono riportati i dettagli come per le vostre domande
1) Server Load
*********************
08:22:53 fino 44 giorni, 13:31, 1 user, load average: 4.07, 5.09, 5,26
USER TTY FROM LOGIN @ IDLE JCPU PCPU COSA
radice pts / 2 datacenter1.supp 08:17 0.00s 1.53s 0.00sw
****************
2) CPU e della memoria
********************
totale utilizzata nella cache buffer libero condiviso
Mem: 4040 3616 424 0 256 2809
- / + Buffers / cache: 550 3490
Swap: 8001 24 7976
*********************************
3) il numero di CPU
3
EDIT: appena preso una fotografia qui http://www.thecodecage.com/forumz/server.png il mio server è in questo modo tutto il tempo, questa istantanea è dopo l'abilitazione memcahce.
Non so come interpretare le misure. Come vedo il tuo CPU è utilizzato in circa il 185% ... Quindi, o c'è qualcosa di giusto caldo in misura o si applica a 1 CPU - se hai 3 allora si può utilizzare al 300%. Se questo è il modo corretto allora vuol dire che hai ancora molte risorse di CPU libera. Se non per favore correggetemi e dire come interpretare i risultati.
Sono, inoltre, non sicuro di come interpretare i dati di carico del server:
carico medio: 4,07, 5,09, 5,26
Sono quelli in 3 diverse misure di tempo, oppure ognuno è per CPU separate? Qual è la potenza della CPU?
PS. Cache bisogno di tempo per riempire pollici
Simon Lloyd
29-05-11, 21:54
Michal, ancora una volta grazie per la risposta il carico medio si vede (e nello snapshot) cambia ogni volta che si aggiorna, è come fai notare un numero sybmolic, quando il carico medio indicato ci sono circa 6 o 7 allora il sito è lento ma il più delle volte non risponde che a sua volta dà un errore.
Ecco i dati di cpu che hai chiesto
Processore # 1
Venditore
GenuineIntel
Nome
Intel (R) Xeon (R) CPU X3430@2.40GHz
Velocità
2394.030 MHz
Cache
8192 KB
Quando i check-in WHM ho 1 cpu quad core, mentre la gente del server mi dicono che hanno 3 CPU??
Non so o fingere di sapere come il carico medio server è elaborato (ultimamente, nel corso degli ultimi 2 giorni è stato in giro:
Medie di carico: 4,49 4,04 3,95
Il forum è di velocità media e non sembra essere la causa di un problema in questo momento, anche se il traffico è di circa:
271 (3 membri e 120 ospiti e 148 spider)
Dove la figura in alto è normalmente intorno ai 500 - 600, ma poi è così fine settimana il traffico è minore.
Ho chiesto circa la velocità della CPU, perché, come abbiamo già detto a carico del server è solo un valore virtuale, così per un veloce carico al processore del server stesso vorrà dire qualcosa che non sia per CPU lenta (veloce si farà il suo lavoro veloce, quindi anche se ci sono altre operazioni in attesa in coda quelle saranno gestite velocemente).
Informazioni sul numero di CPU - in questo momento io sono perso come te. E 'il server e io non vi aiuterà a determinare avete 1 o 3 CPU. Posso dirvi che per i server è meglio avere più quantità di CPU più lente rispetto alle piccole quantità di più veloce. 2 +2 = 5 vuol dire che 2 processori con potenza 2 farà meglio lavoro di 1 processore con potenza 4, perché server hanno molti compiti piccoli, e con processore a 1 non è possibile farlo via parallela.
Il carico del server avrà anche significato diverso a seconda del numero di processori. Se davvero si hanno 3 processori veloci allora il carico del server 6 (totale non per CPU) va bene anche senza ulteriori controlli. Se si dispone di processore a 1 allora si dovrebbe inoltre controllare in tempo reale di risposta per la nostra fogna. Come hai scritto hai già fatto ed è OK.
Per volta che vedete il carico del server è più grande e più lento pagina (una cache - ricordate che per non cache il tempo di risposta reale non è fino al server a tutti, ma fino al tempo di risposta di Google), vi preghiamo di verificare perché è più grande traffico , o forse è a causa di alcune operazioni in background (come cron jobs vBulletin, o anche il sistema operativo proprio - come attività di aggiornamento automatico o qualcosa di simile).
Secondo la risposta ultima - se non c'è vero problema - non avete bisogno di assistenza futuro in questo argomento in questo momento?
Simon Lloyd
04-06-11, 08:46
Michal, grazie per la risposta dettagliata, che è di 4 cpu, la mia unica preoccupazione è la quantità di% di cpu che vBET consuma, mentre sto scrivendo questo ci are3 processi indicati nella TOP per vBET al 55%, 52% e utilizzo della CPU del 48% e questi processi sono tutti per il file / vbenterprisetranslator_seo.php, se non c'è nulla di più si può suggerire allora vi ringrazio per i vostri commenti e dovranno convivere con essa, come sicuramente non possono permettersi un altro passo server o aggiornamento, sono andato da avere vps ad una macchina virtuale in cloud hosting dedicato al fine di mantenere vBET corsa, il salto successivo al quad core dual (8 CPU) è fuori dalla mia portata.
Si prega di notare che ciò che ou lo vedo non è il consumo di CPU VBT ma il consumo forum intero. vbenterprisetranslator_seo.php non fa nulla - imposta solo alcune variabili e fatto reindirizzamento interno di file molto richiesto - si tratta solo di front controller. Tutte le richieste va a vbenterprisetranslator_seo.php - avete impostato nel file htaccess..
Quindi questo non è il consumo di vBET - questo è il consumo forum intero. Per le pagine normali vBET non fa nulla - aggiunge solo bandiere. Per le pagine tradotte intero processo di traduzione avviene così il consumo di CPU sarà sempre più grande per la pagina normale, perché avviene dopo pagina normale viene generato. Quindi prima generazione normale succede e poi risultato si traduce - quindi non c'è possibilità di averlo withour costo aggiuntivo. Oppure ... Noi abbiamo la soluzione per questa formica è chiamato Cache del cliente - per gli ospiti intere pagine vengono memorizzate nella cache e non traduzione avviene finché la cache non è scaduto. Quindi, se si sta già utilizzando cache Ospite poi vBET non hanno soluzioni di più per rendere traduzioni utilizzando meno risorse. Si possono disattivare alcune traduzioni - si avrà allora meno traffico di pagine tradotte in modo meno consumo di risorse per le traduzioni.
Abbiamo fatto molti sforzi per vBET profilazione, cambiando algoritmi, l'aggiunta di ulteriori miglioramenti delle prestazioni. E non abbiamo mai trattare questo problema come chiuso. Sempre in questo momento anche con diversi strati di cache, stiamo lavorando con l'applicazione che hanno molti cambiamenti e contenuti diversi per lo stesso URL in base all'elenco dei Gruppi di utenti, o addirittura per ogni utente (se alcuni plugin aggiunge cose del genere) e questo richiede ritradurre for ogni richiesta dell'utente connesso. Per gli utenti logger possiamo solo cache di traduzioni frase, ma le pagine non intero come per gli utenti. Si prega di notare che vBET sta aggiungendo il miglioramento delle prestazioni sempre più - ancora non avrai mai traduzioni magico, senza consumo di risorse. Funzionalità aggiuntive significa sempre un ulteriore consumo di risorse.
Abbiamo controllato il tempo di risposta del forum ed è davvero buono. Quindi non pensare di passare a un altro server in questo momento. Proprio come hai scritto - è ancora la metà delle risorse gratuite. Si paga per questo le risorse in modo non c'è nulla di male ad usarlo. E voi siete ancora in zona sicura - così anche quando il traffico aumenta il vostro forum sarà risposta in tempo opportuno. Per la luce prima CPU è al 70% di utilizzo medio (non solo in qualche momento - media). Questo è primo accenno di preoccuparsi risorse. Se si ignora questo allora 90% del consumo medio della CPU significa leggere la luce, allarme, e ha bisogno immediato di aggiornare - altrimenti anche poco traffico può fare di più drastico degrado delle prestazioni. Per la memoria è diverso e dipende dalle impostazioni del sistema operativo per SWAP.
E, come PS - perche soluzioni come VPS - dove è possibile aggiungere risorse molto facile senza reinstallare:)
Se hai già daini tutte le prestazioni suggerimenti allora unica cosa che ha lasciato è quella di disabilitare alcune lingue e fatto gli aggiornamenti di vBET come quelli venire.
Automatic Translations (Powered by Google, Microsoft®,
Yandex, SDL Language Cloud, IBM Watson and Apertium):
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.