slacky.eu down .....

[zoros]

in "annunci" non ci è permesso di replicare ... sono ormai tanti giorni di slacky down, pensavo ai consigli del buon vecchio Mario ... sicuramente avete pulito la cache, comunque la dir è accessibile cache/ mentre .htaccess dovrebbe impedirlo ... ma forse non serve, il problema sembra grave ed interessa a quanto pare tutte le aree del server

[tgmx]

Questa mattina sembra andare meglio.
Riesco anche a connettermi via https mentre ieri sera non riuscivo.

[conraid]

C'è un problema con il database, ogni volta viene riavviato con un backup e dopo poco torna a rallentare e tabelle che si corrompono. Stiamo cercando di capire il problema (se qualcuno ha idee bene vengano).
Abbiamo notato anche noi la storia di "annunci", così come altre cose, però purtroppo dovendo ogni volta mettere i backup aspettiamo che la situazioni torni regolare per sistemare tutto.
Anche nel wiki purtroppo si sono perse modifiche che erano costate ore di lavoro.
Dai log non si riesce (noi) a capire cosa sia successo, sembra tutto regolare, ma ogni volta mysql "consuma" molta cpu, blocca tutto, e le tabelle si corrompono.
Inoltre potete anche vedere in alcuni momenti, https che non va, il wiki fermo, il forum fermo, etc... magari solo perché vengono fatte delle prove, backup, restore, etc...
Ci stiamo ritagliando spazi di tempo per lavorarci su, ma non ne abbiamo molto, e forse ci capiamo poco

[miklos]

dico una fesseria... puo' essere che sia 'semplicemente' arrivato il limite per quanto riguarda la potenza della macchina dove è hostato slacky!?!??!?!

[joe]

Però abbiamo perso una settimana di discussioni... dico bene?
Non è un po' troppo?
Personalmente non mi intendo di sicurezza server ecc quindi non so aiutarvi nello specifico, ma volevo solo osservare che forse con backup più frequenti si sarebbe persa meno roba... Diciamo che forse sarebbe stata recuperata la situazione a Venerdì/Sabato scorsi... Invece una discussione cui stavo partecipando è tornata a Mercoledì 18 Aprile...
Con che frequenza viene backuppata la faccenda?

[zoros]

il sistema continua ad impallarsi ogni tanto (intendo risposta lenta) ... il sistema è ora in chroot, l'unica cosa che mi viene in mente è la mancanza di qualche settaggio nelle variabili di ambiente ... temporaneamente è possibile accedere ad un mysql all'esterno del chroot? ...

@joe: credo che non possono fare continui backup del database, visto che si corrompe in continuazione ...

[lablinux]

potreste allegare i log, magari tra noi esiste un esperto (anche più di uno) che ha la soluzione al problema.
La sparo, trojan? Dischi corrotti?

[ZeroUno]

rm -rf /var/lib/mysq
e ricreazione da zero.

Quanto è grande il db?

[rik70]

RAM???

La butto lì cosi - non capendone nulla - ma solo per dire che qui il forum carica molto lentamente.

In bocca al lupo ^_^

[conraid]

Cerco di rispondere a tutte le domande.
- Mysql è solo in chroot, così come apache
- i backup sono giornalieri, ma sono stati ricaricati quelli sicuramente non "corrotti"
- la directory mysql è 1.7gb, i db sono

Codice: Seleziona tutto

# du -h
688K    ./asche
548K    ./asche64
4,1M    ./joomla
5,5M    ./mysql
576M    ./phpBB3
101M    ./wiki
1,7G    .

- il tutto è così da mesi, quindi variabili d'ambiente tenderei ad escluderle. L'unica novità è l'aggiornamento del wiki, ma il "problema" si è verificato da sabato, wiki era già su da un po'
- per problemi hardware o trojan. Tutto è possibile purtroppo, stiamo cercando di capire. Appena posso posto qualche log

[ZeroUno]

ls -la

fai un backup con l'export. resetta tutto e rifai l'import (magari prova su un pc) e vedi quanto è grande il risultato.

Le tabelle sono MyISAM (o come si chiamano) o InnoDB?

Io ho trovato difficoltà con l'InnoDB per grandi dimensioni. Molto spesso il kill non andava, serviva il kill -9, ma al restart di mysql faceva il resume e si impallava.
Il restore da directory non aiuta.

Confermo la richiesta di quantità di ram, totale, usata, libera, swap???, e andamento temporale e utilizzo di cpu come picchi e medie nel tempo, utilizzo di cpu da parte di mysql in condizioni di startup, regime e crash.
v. ps -eo user,pid,pcpu,rss,resident,size,vsize,time,cmd

Puoi aiutare anche una temporanea reinstallazione di mysql in un nuovo chroot (per pulizia) o l'uso temporaneo del mysql di sistema.

[miklos]

L'unica novità è l'aggiornamento del wiki, ma il "problema" si è verificato da sabato, wiki era già su da un po'

si e no, nel senso che almeno personalmente è da un po' che ho riscontrato rallentamenti al sito in generale, ma chiaramente parlo da fruitore e non da chi gestisce il sistema

comunque i database non mi sembrano eccessivamente corposi da giustificare un mysql che non ce la fa.. considerando pure che c'e' la cache di mezzo che dovrebbe mitigare un po' gli accessi al database(fermo restando che nn conosco i volumi di traffico.. magari il sito riceve 1000 richieste al minuto e allora non ce la fa per davvero).

detto questo... per me resta comunque un problema di mysql che fa una qualche query che lo impalla.. ora che dipenda da bug di componenti nuovi, oppure no solo con qualche log si puo' capire.

p.s.: so che puo' sembrare blasfemia, ma io mi trovassi con le spalle al muro proverei ad andare per esclusione, ovvero disabilitare per esempio il wiki e vedere se il problema si ripresenta, poi asche, poi il forum.. in modo da riuscire a capire il colpevole a agire di conseguenza.

[targzeta]

In effetti è quello che pensavo anche io. C'è da dire che oggi almeno il server risponde. Io ho una pessima connessione e non riesco a capire se è il mio PC o il server.

Come ha detto Corrado, i backup sono giornalieri e possiamo anche ripristinare quello di sabato. Però come ha detto zoros, i database di sabato erano corrotti, quindi non so che senso abbia. Il problema peggiore è che sino a quando non capiamo cosa succede anche i post futuri possono andare persi.

Io potrei anche dare la colpa a problemi hardware, però il fatto è che appena ripristiniamo i database del 18 tutto sembra filare molto più liscio. Inoltre appena killiamo il server web tutto funziona bene.

Ci sono problemi su tutte le tabelle, indipendentemente dal database.

Tra i log non troviamo nulla di strano, se no una strana richiesta al forum:

Codice: Seleziona tutto

File does not exist: /var/www/htdocs/slacky.eu/forum/index.php++++++++++++++++++++++++++++++Result:+used+self-learning+system+data;+used+x_fields.txt;+unknow+type+of+text+captcha,+add+it+in+textcaptcha.txt;+chosen+nickname+"tutsoract";+registered+(registering+only+mode+is+ON);, referer: http://www.slacky.eu/forum/index.php++++++++++++++++++++++++++++++Result:+used+self-learning+system+data;+used+x_fields.txt;+unknow+type+of+text+captcha,+add+it+in+textcaptcha.txt;+chosen+nickname+%22tutsoract%22;+registered+%28registering+only+mode+is+ON%29;

non so se possa essere questo.

Purtroppo anche il tempo è quello che è, vediamo se domani che è festa riusciamo a fare qualcosa di meglio.

Per le prestazioni non sembra essere cambiato molto. Il PC non swappa quasi mai e quando tutto va bene anche l'uso della CPU è basso. Solo dopo un po' succede qualcosa e il server web così come mysql iniziano ad usare quasi il 100% della cpu. Mysql risponde molto lentamente e si raggiunge subito il limite massimo di clienti.

O siamo sotto attacco e qualcuno in questo momento se la sta ridendo, oppure non saprei cosa pensare.

Ora faccio un controllo sulle tabelle quindi butto giù il server per un po',
Emanuele

[targzeta]

P.S. Le tabelle sono MyISAM

[ZeroUno]

1) quando salgono al 100%, chi prende di più? apache,php o mysql?
2) nei log di apache (access) si registra un aumento di attività negli ultimi giorni? o exit code '206'
3) è replicabile il problema o il "dopo un po'" è una quantità abbastanza randomica?

edit:

P.S. Le tabelle sono MyISAM

Non tornano le somme dello spazio occupato da mysql, riportato qualche post fa; le directory non arrivano a 1G (se non sono cecato)... la somma non può essere 1.7G, per questo chiedevo ls -la; se c'era InnoDB si spiegava, con MyISAM no.