OVH Community, your new community space.

Server lentissimo - Ticket senza risposta da giorni!


bago
02.04.2009, 09.48
Citazione Originariamente Scritto da Lord B. Brummell
La porta 80 va gi su entrambi contemporaneamente. Uno CentOS, l'altro Ubuntu. Quindi credo che il problema non sia nei containers ma nel server fisico. Solo, ripeto, il problema si presenta per 10 minuti 1-2 volte al giorno... qualcosa riguardante una qualche cache...?
mi sembra strano che una cache possa creare questo problema.

Piuttosto tu dici che alla shell riesci ad accedere: la shell del server o quella dei container? Puoi provare ad entrare anche nei container?

Se provavi dalla shell del server una prova utile potrebbe essere quella di entrare direttamente nella shell del container e fare la propria wget/lynx da l. Purtroppo non conosco il funzionamento di Virtuozzo quindi vado un po' alla cieca. Se non hai ancora provato a esporre il problema su un forum di esperti di Virtuozzo ti consiglio di farlo: magari un problema noto?

Lord B. Brummell
02.04.2009, 09.32
Riavviando il container ci sono dei problemi su arpsend:

http://img18.imageshack.us/img18/5568/arp.png

Lord B. Brummell
02.04.2009, 07.30
Citazione Originariamente Scritto da bago
Hai detto che hai pi container: si bloccano tutti o uno solo?
La porta 80 va gi su entrambi contemporaneamente. Uno CentOS, l'altro Ubuntu. Quindi credo che il problema non sia nei containers ma nel server fisico. Solo, ripeto, il problema si presenta per 10 minuti 1-2 volte al giorno... qualcosa riguardante una qualche cache...?

bago
01.04.2009, 22.56
Quindi a questo punto il problema virtuozzo o qualcosa che non va all'interno di virtuozzo.
Hai detto che hai pi container: si bloccano tutti o uno solo?

Lord B. Brummell
01.04.2009, 21.02
Citazione Originariamente Scritto da bago
se provi a chiedere le pagine che non vanno con un wget dalla macchina stessa (o con lynx se preferisci) arrivano veloci o va tutto lento?
Poco fa andato gi nuovamente e dunque ho ricevuto il solito Alert OVH per email... la shell era per come sempre accessibile e questa volta ho fatto in tempo a fare un wget... e non andato!
Codice:
HTTP request sent, awaiting response...

ibanez89
01.04.2009, 12.51
Si ma questi grafici oltre a non avere una cronologia, cio vedere che succede durante il gg senza avere un pannello, non mostra l'utilizzo della banda internet, delle i/o disco ecc

vedi qui

http://db.opensim.icestream.it/munin/

Lord B. Brummell
01.04.2009, 12.41
Citazione Originariamente Scritto da ibanez89
Prova a metterci munin, un grafico che fa da monitor di processi, uso disco, ram ecc in modo da vere se un problema di configurazione o insufficienti risorse hardware in un dato momento "e poi diagnosticare la causa"
Grazie... comunque il Manager di Virtuozzo non segnala nulla di strano:

- Server:

http://img21.imageshack.us/img21/2814/virtuozzo1.png

http://img23.imageshack.us/img23/8383/virtuozzo3.png

- Containers:

http://img23.imageshack.us/img23/3956/virtuozzo2.png

ibanez89
01.04.2009, 12.20
Prova a metterci munin, un grafico che fa da monitor di processi, uso disco, ram ecc in modo da vere se un problema di configurazione o insufficienti risorse hardware in un dato momento "e poi diagnosticare la causa"

bago
01.04.2009, 11.17
Purtroppo non conosco virtuozzo, ma direi che il problema probabilmente l.

Io usavo Virtuozzo qualche anno fa e mi sono trovato malissimo perch gli utenti si rubavano cpu/disco tra loro e non c'era modo di garantire un po' di equilibrio d'uso nelle risorse e quindi sono passato a vmware.

Forse ti conviene cercare su qualche forum/lista dove c' gente che conosce Virtuozzo per bene..

Lord B. Brummell
01.04.2009, 10.53
Citazione Originariamente Scritto da bago
@Lord: se l'alert ti viene mandato da OVH stesso dubito fortemente che sia un problema di routing da telecom. Se poi l'SSH funziona e l'HTTP no non possibile nuovamente che sia un problema di routing. Entrambi usano TCP e il routing dipendente solo dall'IP e non dalla protocollo.
Esatto...

Intanto direi che a questo punto il rallentamento del sito ed il fatto che a volte va gi la porta 80 fanno parte di due discorsi diversi.
Quando il sito lento dipende dalla rete OVH.
Mentre quando ricevo l'Alert sulla porta 80 riguarda un problema tra Virtuozzo e i Containers: ricevo gli Alarm solo sulla porta 80 dei containers... non del server dove gira Virtuozzo! Infatti mentre non riesco a visualizzare i domini e Plesk... riesco comunque a navigare nel manager di Virtuozzo! Altra nota che Apache nei Containers rimane up e non ci sono Alert Zone nei Logs quindi escluderei un problema sul processo/i.

Quello che non mi fa capire in che direzione andare per risolvere il problema che si verifica 1-2 volte al giorno per circa 5-10 minuti per poi risolversi da solo! Ma quale razza di errore, avendo escluso i processi sul server e il routing, ha questo comportamento???

bago
01.04.2009, 10.26
@Lord: se l'alert ti viene mandato da OVH stesso dubito fortemente che sia un problema di routing da telecom. Se poi l'SSH funziona e l'HTTP no non possibile nuovamente che sia un problema di routing. Entrambi usano TCP e il routing dipendente solo dall'IP e non dalla protocollo.

Lord B. Brummell
01.04.2009, 09.57
In questo momento andato gi nuovamente per qualche minuto ed ho ricevuto l'OVH Service Monitoring [ALERT] sulla porta 80.
SSH invece era accessibile ma non ho fatto in tempo a fare altri test perch poi HTTP tornato UP.

Questo il Traceroute nel momento in cui il sito non era visualizzabile:
Codice:
 1  192.168.1.1 (192.168.1.1)  3.516 ms  1.519 ms  1.123 ms
 2  192.168.100.1 (192.168.100.1)  38.560 ms  37.580 ms  38.540 ms
 3  host145-60-static.40-88-b.business.telecomitalia.it (88.40.60.145)  38.503 ms  38.588 ms  38.113 ms
 4  r-rm225-vl14.opb.interbusiness.it (80.21.4.26)  38.343 ms  38.158 ms  38.389 ms
 5  csr-rm003-r-rm225.opb.interbusiness.it (151.99.99.89)  39.048 ms  39.068 ms  38.085 ms
 6  crs-mi003-crs-rm003.opb.interbusiness.it (151.99.98.10)  49.544 ms  49.449 ms  50.213 ms
 7  host29-8-static.20-80-b.business.telecomitalia.it (80.20.8.29)  48.392 ms  49.018 ms  47.790 ms
 8  mil53-ibs-resid-7.mil.seabone.net (195.22.192.21)  47.833 ms  48.745 ms  47.874 ms
 9  teleglobe-2-ca-fra7.fra.seabone.net (195.22.211.122)  59.019 ms  59.075 ms  60.950 ms
10  if-7-0-0.core1.FR1-Frankfurt.as6453.net (80.231.64.21)  59.085 ms  58.988 ms  59.329 ms
11  if-10-0-0.core1.PV1-Paris.as6453.net (80.231.64.34)  67.544 ms  69.096 ms  75.179 ms
12  if-6-783.har1.PV0-Paris.as6453.net (195.219.215.94)  73.362 ms  72.845 ms  72.563 ms
13  30g.teleglobe.th1-1-6k.routers.ovh.net (213.186.32.245)  76.789 ms  67.858 ms *
14  40g.vss-1-6k.routers.ovh.net (91.121.131.29)  82.206 ms  76.041 ms *
15  ns2051XX.ovh.net (94.23.21.XX)  70.203 ms  70.532 ms  69.946 ms
16  94-23-65-XX.ovh.net (94.23.65.XX)  70.010 ms  69.560 ms  70.089 ms

Lord B. Brummell
31.03.2009, 18.07
Citazione Originariamente Scritto da bago
se provi a chiedere le pagine che non vanno con un wget dalla macchina stessa (o con lynx se preferisci) arrivano veloci o va tutto lento?
La prova con lynx non l'ho fatta... prover...

bago
31.03.2009, 18.03
sai usare la shell? se provi a chiedere le pagine che non vanno con un wget dalla macchina stessa (o con lynx se preferisci) arrivano veloci o va tutto lento?

Lord B. Brummell
31.03.2009, 17.46
Ulteriori dettagli:

Sia quando diventa lento (2-3 volte al giorno) sia quando non proprio visualizzabile (circa 1 volta al giorno) il ping sul dominio comunque normale.

La distro del Server OVH Virtuozzo 4.0 con Container CentOS 5.2 + Plesk 9.0.1. Tutto come da default, nessuna modifica/aggiunta particolare. I domini in Plesk hanno il container come NS primario e sdns1.ovh.net come NS secondario (correttamente configurato anche nel Manager OVH).

L'assistenza italiana dice che il problema potrebbe essere nel /etc/resolv.conf:
nameserver 127.0.0.1 #localhost
nameserver 213.251.188.140 #sdns1.ovh.net
nameserver 213.186.33.99 #cdns.ovh.net
search
...qualche idea?

Grazie ragazzi...

bago
30.03.2009, 18.43
Non conosco il francese ma pare che OVH abbia problemi di routing internazionale:
http://translate.google.it/translate...hl=it&ie=UTF-8

Sembra che a causa di un problema sulla linea verso francoforte (quella che viene in italia?) il traffico sia ora DTAG, che per visto il mio francese non sono sicuro di decifrare correttamente. Direi che hanno buttato del traffico su Deutsche Telekom AG perch hanno problemi sulla fibra che hanno attivato 4 giorni fa...

Tutto questo per non corrisponde con le 2 settimane di cui parli tu... quindi non vorrei che la cosa sia indipendente da questo. In fondo questi problemi a francoforte non dovrebbero assolutamente influire sul monitor ovh che invece dici che fallisce pure lui.

bago
30.03.2009, 18.33
Citazione Originariamente Scritto da gio01
0.68 x 1500user?
apriva lentissimo
sono diventati come godmt2 .-.
Dipende da cosa intendi per 1500 user. Ci sono server IMAP con 100000 utenti che non hanno bisogno di quella banda.
Dipende 1500 user che cosa fanno.
Se parli di utenti di forum 1500 indica probabilmente la totalit di IP che hanno chiesto almeno una pagina negli ultimi 30 minuti e non le connessioni contemporanee che hai.. comunque siamo OT.

bago
30.03.2009, 18.28
In generale a me in questo momento va molto male anche il solo accesso al managerv3 di ovh.

bago
30.03.2009, 18.24
In questo momento sto notando pacchetti persi sia ad arrivare ad un RPS in RBX2 che verso questo forum che verso i siti di ovh tipo http://weathermap.ovh.net/roubaix-2 .

I pacchetti persi ce li ho sia dall'ADSL che da una macchina in housing nella webfarm di INET (quasi MIX).

Effettivamente indipententemente dalla banda bastano pochi pacchetti persi per notare problemi di navigazione.

Ho guardato un po' le weathermap ma faccio fatica a decifrarle.. non mi pare ci siano problemi particolari di rotte piene, quindi forse c' qualche switch/router che perde colpi?

gio01
30.03.2009, 18.22
0.68 x 1500user?
apriva lentissimo
sono diventati come godmt2 .-.

bago
30.03.2009, 17.51
Citazione Originariamente Scritto da gio01
noto pure io un rallentamento di banda del 80% 2 gg f ero arrivato a 0.68mega/s c' incredibile
poi tutto risolto
fai cos effettua dei speedtest
li posti qui e valutiamo
Con 0.68 mega/s si naviga tranquillamente.

Lui dice che i suoi domini non sono proprio raggiungibili e addirittura il monitor OVH (che immagino faccia solo una connessione alla 80, o al massimo scarichi il solo html della home) va in errore.

camaran
30.03.2009, 17.41
beh se non rispondono c' sempre il telefono

gio01
30.03.2009, 17.27
noto pure io un rallentamento di banda del 80% 2 gg f ero arrivato a 0.68mega/s c' incredibile
poi tutto risolto
fai cos effettua dei speedtest
li posti qui e valutiamo

bago
30.03.2009, 15.50
ma spiegami una cosa, nel momento esatto in cui diventa lento riesci ad accedere in shell?

Io di solito tengo un mrtg che controlla i risultati di un ab (apache bench) che controlla sempre almeno da locale la latenza dei siti.

Prova intanto a guardare come funziona ab ed eseguirlo sia quando tutto ok che quando ti sembra rallentato...

Lord B. Brummell
30.03.2009, 15.43
Citazione Originariamente Scritto da j0t
Dove si trova il server? (armadio? datacenter?)
Datacenter: RBX-2
Armadio: 21C07
Numero: 65133

Grazie...

j0t
30.03.2009, 15.40
Dove si trova il server? (armadio? datacenter?)

Lord B. Brummell
30.03.2009, 15.36
Citazione Originariamente Scritto da Lord B. Brummell
Riferimento ultimo Ticket "Incidente":
- 87357 (2009-03-27 19:17:29)
UPDATE: Siamo scaduti nel ridicolo:
Il ticket 87357 era stato chiuso giorni fa senza aver risolto il problema per aprire un thread in "Assistenza Tecnica"... l'assistenza tecnica risponde:
Buon giorno

puo' aggiornare il ticket scrivendo che in alcune ore della giornata il suo server e' irraggiungibile.
Ed inserire maggiori inormazioni.
cos, riapro il ticket spiegando che il problema persiste ed ora viene richiuso sempre senza aver risolto il problema aprendo un ultieriore thread parallelo in "Assistenza Tecnica" e tagliando i miei ultimi aggiornamenti al ticket 87357 (censura?).
Ora in "Assistenza Tecnica" ci sono 3 thread paralleli, tutti sullo stesso argomento, dove mi vengono richieste sempre le stesse cose: ovvero di fare il Rescue Mode e di controllare i Logs, ovviamente cose gi fatte!!!
Tutti si passano la palla e nessuno risolve nulla.

Signori, ripeto, non ci siamo... forse dovreste rivedere il vostro sistema di assistenza. Forse se chiamavo il 187 risolvevano pi cose... rendiamoci conto...

@bago: grazie del consiglio... sei il primo che me ne suggerisce uno.

bago
30.03.2009, 14.07
Mi sembra che il fatto che il service alert di OVH stesso segnali problematiche dovrebbe escludere il fatto che il problema si presenti da Alice e Fastweb. Se si presenta in rete locale OVH allora o la rete locale ovh a dare i numeri (switch?) oppure il server stesso che ha problemi momentanei.

Hai provato a mettere un monitor *interno* che controlla il servizio HTTP ogni 30 secondi? Se anche quello ti segnala problemi allora il problema il tuo server e non la rete o altro...

Lord B. Brummell
30.03.2009, 11.53
In diversi momenti della giornata (circa 4-5 volte) i domini del nostro server dedicato (EG Max, SLA Premium) rallentano moltissimo e circa 2-3 volte al giorno diventano proprio non raggiungibili per un tempo di circa 10 minuti... tanto vero che riceviamo gli OVH Service Monitoring [ALERT] via email con lo status: HTTP FAILURE.

I problemi sono stati riscontrati sia attraverso connessioni Alice che Fastweb (ovviamente questo non esclude le altre).

Lato server tutto OK, software stabile, consumo CPU, RAM, SWAP nella norma, nessun alarm zone. E' stato eseguito anche il Rescue mode che comunque non ha rilevato nessun errore.

Tutto questo succede fin dall'inizio (circa 2 settimane) e attualmente ci sono 2 ticket "Assistenza Tecnica" e un Ticket "Incidente" aperti.

La cosa gravissima, oltre al problema in se, che non abbiamo ricevuto nessuna risposta concreta. Le uniche risposte ai ticket sono avvenute con diversi giorni di ritardo... e sono state risposte nelle quali si chiedevano traceroute e di fare il Rescue Mode... ma a seguito di questi dati prontamente inviati... nulla pi ed il problema persiste da ormai settimane senza soluzioni!

Riferimenti ultimi Ticket "Assistenza Tecnica":
- 2009-03-26 10:10:34
- 2009-03-19 10:14:12
Riferimento ultimo Ticket "Incidente":
- 87357 (2009-03-27 19:17:29)

Signori non ci siamo proprio...