Lentezza esecuzione di query sql su server s83

[Gianluca]

Non ci sono specifici limiti di banda/sec, andrei con ordine per vedere una cosa alla volta.

Che tipo di cache hai implementato?

Che tipo di cache hai implementato?

Ho implementato il salvataggio su file delle sitemap per evitare di far eseguire più volte quelle query con migliaia di righe...esattamente ho usato questa funzione...

function cache($url){
	$md5_url = md5($url);
	if(file_exists("./xxx/$md5_url")){
		$file = @fopen("./xxx/$md5_url", "r");
		$download_rate = 500;
		$bite=round($download_rate*1.024);
		while(!@feof($file)){
			echo @fread($file, $bite);
			flush();
			usleep(1);
		}
	}else{
		return TRUE;
	}
}

come vedi ho anche messo una specie di limite sulla velocità di trasferimento...ma questo non ha migliorato le cose...

ovviamente se restituisce true il file di cache viene creato...ma sono gia stati creati tutti quelli richiesti

[Gianluca]

Il limite sul download in realtà non serve, quello che invece può servire è un meccanismo di caching che riguarda le richieste su video.php che sembrano essere le più frequenti, implementandolo probabilmente risolverai il problema.

Il limite sul download in realtà non serve, quello che invece può servire è un meccanismo di caching che riguarda le richieste su video.php che sembrano essere le più frequenti, implementandolo probabilmente risolverai il problema.

Si ma quello che non riesco a capire è cosa succeda ogni 10 minuti che per due minuti di fila fa verificare questo problema...è un po strana come cosa...
una cache sulle query di insert o update o delete mi risulta impossibile da implementare...oltretutto le select sono query sempre differenti...si e no saranno un paio per pagina...e sono query che restituiscono al massimo 20 righe...

anzi a essere più precisi attualmente da ieri, quando si è verificato il problema di caricamento anche dei file di testo, la maggior parte delle query nello script non vengono eseguite affatto perchè le ho bloccate per mantenere il sito attivo...ma il problema è sempre presente...potete verificare in questo periodo cosa si verifica di anomalo?

[Gianluca]

Quello che intendevo sopra è un caching delle operazioni di lettura, quindi si parla di select.
Anche se il numero di righe restituito è basso il guadagno sta nel risparmiare le operazioni che servono per generarle, specialmente in una tabella grande, riducendone quindi l'impegno, anche se hai una grossa variabilità di richieste mantenerne un po' sotto forma di cache nel filesystem ed evitare proprio la connessione al database può comunque migliorare molto le performances.

Un'alternativa potrebbe anche essere lo split dei dati in più tabelle di lavoro, se ad esempio fai ordinamenti frequenti di record che mantengono comunque sempre lo stesso ordine (ad esempio per id di inserimento) la cosa probabilmente migliore è creare una tabella di lavoro (anche temporanea) con le righe già ordinate su cui poi fare le queries con i relativi offset che ti servono senza ad ogni richiesta fare l'ordinamento di milioni di record che è molto oneroso.

Capisco cosa intende...ho fatto una cache dell'unica select che veniva eseguita su video.php ...attualmente non viene eseguita nessuna select...l'unica cosa che si esegue su ogni pagina è la connessione al database per gli eventuali insert ,update e qualche delete per i quali uso la funzione mysql_unbuffered_query per evitare che lo script resti in attesa...ma il problema c'è sempre... nel log non viene segnalato nessun problema?

ho notato che diversi insert hanno un tempo di esecuzione di un paio di secondi...potrebbe essere questo a causare il problema? Ma se dovrei fare usa select prima di fare la insert andrei a peggiorare le cose...queste insert sono eseguite sull'altra tabella che ho trasformato in innodb...

[Gianluca]

Dai log pare che la situazione sia decisamente migliorata, puoi confermare? Eviterei di aprire una connessione al database ad ogni richiesta, ma solo quando necessaria, il caching dovrebbe servire anche a questo.

Si la situazione era migliorata disabilitando le query di insert e alcune select delle due tabelle principali...
credo il problema si verifichi per via delle dimensioni eccessive delle due tabelle...
il problema sta nel fatto che non saprei come dividerle considerato che mi serve verificare l'unicità di un campo specifico che condiziona l'inserimento di nuove righe
ogni pagina presenta query da eseguire evitare le connessioni è quasi impossibile mantenendo

oggi noto stranamente meno traffico del solito quindi capire se il problema persiste o meno è difficile...
tuttavia il problema si presenta immediatamente se viene eseguita una select molto grande come quelle messe in cache

Salve, ....
ci risiamo... stavolta oltre il solito "MySQL server has gone away" si verifica un blocco con 144 errori di fila di questo tipo:
"User dargoole already has more than 'max_user_connections' active connections" questo dal time 1403347793 a 1403347843 per poi proseguire con i soliti "MySQL server has gone away"
precedentemente ho verificato che ultimamente le connessioni server2server sono notevolmente aumentate di durata di esecuzione, e ho pensato che fosse questo a tenere aperte troppe connessioni (anche se prima questo errore non era cosi frequente) per eliminare questo problema ho inserito

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 800); 
	curl_setopt($ch, CURLOPT_TIMEOUT, 3);

teoricamente ciò dovrebbe risolvere anche gli errori di "MySQL server has gone away" ...ma ciò non è avvenuto, a questo punto è certo al 100% che sia un problema del database e non delle lettura dei file che non dovrebbe bloccare una connessione per piu di 6 secondi
tra le query nessuna di queste dura più di 15 secondi...almeno quelle che vengono eseguite...non riesco proprio a capire quale sia il problema di questo db...in locale ovviamente non si verifica nulla di tutto ciò...

qualche suggerimento?

Adesso si è aggiunta una sfilza di "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11)" prima della sfilza max_connect con conseguente rallentamento di alcune query

[Gianluca]

Cos'hai modificato dopo il tuo ultimo post di Maggio?

Ogni connessione server2server che fai è bloccante, questo significa che se l'host remoto non risponde o risponde molto lentamente anche l'esecuzione del tuo script sarà molto lenta o andrà in timeout.

Salve, in realtà a maggio non è che il problema fosse scomprarse, quindi ho deciso di modificare lo script per tenere sotto controllo ogni query e letture server2server eseguita, e li ho capito che forse erano proprio queste a rallentare/bloccare il tutto...ho eseguito parecchie modifiche...apparte la cache a quelle query da 50000 righe...
proprio per evitare il blocco causato da server2server ho aggiunto quelle due righe alla curl ...

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 800); 
curl_setopt($ch, CURLOPT_TIMEOUT, 3);

teoricamente dovrebbe evitare che lo script si blocchi a causa della lettura file...anche se è strano che abbassando questo limite i blocchi erano piu frequenti...

ho salvato gli errori verificatisi dalle query per l'intera giornata si un file del server, adesso noto che un altro errore
"Too many connections" questi errori si stanno verificando nella mysql_connect...e non capisco come sia possibile che ci siano troppe connessioni al db, ho anche aggiunto la funzione mysql_close quando so che lo script verra eseguito per parecchi secondi senza eseguire altre query ma la situazione non è migliorata...

da precisare cmq che non c'è più la frequenza di blocco ogni 10 minuti da quanto ho preso in considerazione le connessioni server2server (anche se sono scese anche le visite nello stesso periodo)...quindi erano loro a causarlo probabilmente...
adesso succede piu raramente ma dura più tempo...per esempio oggi l'ultimo errore di mysql_connect è delle 9.51 (non ho preso in considerazione gli errori "MySQL server has gone away" altrimenti il file sarebbe diventato troppo grande)

[Gianluca]

CURLOPT_CONNECTTIMEOUT_MS in realtà non ha effetto come anche CURLOPT_TIMEOUT, di conseguenza se hai notato un cambiamento non credo sia dovuto a quello.

Nei tuoi log server2server ci sono molte connessioni e alcune arrivano a scambiare anche oltre 100k, questo è sicuramente un fattore che abbatte le performances, specialmente se il medesimo script fa molteplici connessioni in un sessione tutte in contemporanea.

Se poi lo script rimane connesso al database perché è in attesa della rete gli errori mysql "gone away" o "too many connections" sono piuttosto normali.

Il problema non è mai stato questo numero elevato,o perlomeno prima era gestito meglio, è sempre stato così, ma è sorto quando alcune di esse han cominciato a impantanarsi mettendoci anche minuti per concludersi...così ho deciso di adottare questi timeout per rimuoverli...
tant'è che ogni pagina solitamente non impiega più di 0,3 secondi al massimo per formarsi dove sono presenti più connessioni(tempo calcolato dal php) tranne quando avviene quel problema...
ora come sarebbe che i due timeout non hanno effetto? Sul manuale è spiegato chiaramente il loro utilizzo...a me interessa che nessuna di queste connessioni blocchi lo script anche a costo di troncarne qualcuna...

[Gianluca]

AlterVista ha una versione di php custom, ovvero con alcune ottimizzazioni ad hoc. Per ragioni di sicurezza il timeout non è modificabile, quindi quelle direttive sono ignorate e viene impostato un timeout fisso di 30 secondi.