Ho un server WIN2003 con queste caratteristiche:

Intel(R) Xeon(R) CPU 3040 @ 1.86GHz EM64T Family 6 Model 15 Stepping 2 ~1867MHz 2Gb RAM

Ho installato sul server un 25 domini circa.. tutte le applicazioni ivi residenti sono ASP.NET 1.1 + MYSQL 5, il sito con più accessi è circa 110utenti giornalieri il resto una ventina di media.
I database MySQL sono composti da un 30-50 tabelle (a seconda della versione) con un centinaio di record nella tabella più usata.

Per le connessioni al db uso il Connector rilasciato da MySql per .NET

Il server in alcuni orari della giornata ha alcuni picchi (per ora non frequenti nell'ordine di un paio di volte a giorno) in cui comincia a rallentare (la CPU uso 50%) per poi tornare ad 1-2% di uso CPU, ... e ora mi sto interrogando sulle cause.

Possibile che un server dedicato venga saturato da una situazione del genere? è l'accoppiata ASp.NET + MYSQL che degrata in questo modo le performance?

---

Modificato da diego78 il 24 agosto 2011 10.20 -

il server purtroppo è in modalità MANAGED per cui mi è un pò difficile fare quello che mi hai suggerito

posso accedere solo tramite il pannelo PLESK.

Nel pannello dedicato a MySQL ho trovato però delle informazioni interessanti evidenziate in rosso da phpmyadmin:che riporto:

Innodb_buffer_pool_reads: 28 k
Il numero di richieste logiche che InnoDB non può soddisfare dal buffer pool e che devono fare una lettura di una pagina singola.

Innodb_row_lock_waits: 2
Il numero di volte che un row lock ha dovuto attendere.

Handler_read_rnd: 14 k
Il numero di richieste per leggere una riga basata su una posizione fissa. Questo valore è alto se stai facendo molte richieste che richiedono un ordinamento dei risultati. Probabilmente hai molte query che che richiedono a MySQL di leggere l'intera tabella oppure ci sono dei joins che non usano le chiavi correttamente.

Handler_read_rnd_next: 790 k
Il numero di richieste per leggere la riga successiva in un file di dati. Questo valore è alto se stai facendo molte scansioni della tabella. Generalmente è un segnale che le tue tabelle non sono correttamente indicizzate, o che le query non sono state scritte per trarre vantaggi dagli indici che hai.

Created_tmp_disk_tables: 3,943
Il numero delle tabelle temporanee create automaticamente sul disco dal server mentre esegue i comandi. Se il valore Created_tmp_disk_tables è grande, potresti voler aumentare il valore tmp_table_size, per fare im modo che le tabelle temporanee siano memory-based anzichè disk-based.

Key_reads: 84
Il numero di letture fisiche dal disco di un blocco chiave. Se Key_reads è grande allora il valore key_buffer_size è probabilmente troppo piccolo. IIl rapporto di cache miss rate può essere calcolato come Key_reads/Key_read_requests.

Select_full_join 298:
Il numero di joins che non usano gli indici. (Se questo valore non è 0, dovresti controllare attentamente gli indici delle tue tabelle.)

---

Modificato da diego78 il 25 agosto 2011 15.20 -

diciamo che i 25 siti sono alla fine 3 applicazioni diverse ripartite per 25 clienti.

Ho preso in analisi le query del FRONT dell'applicazione del sito con maggiori accessi (intorno ai 100 giornalieri) e ho potuto constatare come gli indici potevano essere inseriti in quasi tutte le tabelle coinvolte nelle query più pesanti (esempio il catalogo), praticamente avevo quasi sempre solo la chiave primaria.

Da domani riporterò l'ottimizzazione sui siti più trafficati e terrò in test per qualche giorno il livello della CPU

Ora con gli indici solo sul sito più trafficato non è cambiato nulla tra le 17.45 e le 18 il livello della CPU si è alzato e i siti sono rimasti bloccati per qualche minuto... ora è ripartito tutto

diego78 ha scritto:

e la cosa che mi sta rattristendo è che sto passando tutta luglio/agosto per questo problema del cavolo..

capisco... ma è del tutto normale se non hai la possibilità di conoscere a fondo le possibili cause. Io proverei a cambiare strategia:

• Se possibile, chiedi a chi ti gestisce il server di darti un'opinione sul problema che stai riscontrando
• Predisponi un tuo PC/server quanto più simile a quello di produzione, su cui installerai tutti i siti. Poi, scarica un tool tipo WCAT per simulare molti accessi contemporanei e cercare, così, di riprodurre il problema. Usa il general_log di MySql e il Performance Monitor di Windows per capirne la fonte.

Quindi cosa significa che ho avuto 5 accessi contemporanei nello stesso secondo (360 il tempo indicato) e il db è andato in blocco?

Ma 5 accessi contemporanei sono niente per il server, ammesso che le applicazioni funzionino correttamente. Che versione di Windows server hai in produzione?

Dato che ci sono 5 connessioni in sleep da 360 secondi, per me è più probabile che sia stata l'applicazione ad aprire 5 connessioni, piuttosto che 5 utenti contemporanei. E' possibile che esista un bug nell'applicazione che gli fa aprire più di una connessione contemporaneamente?

Inolte, nelle tue connection string, per caso hai impostato un Max Pool Size=5 ?

Che succede esattamente quando i siti si bloccano? Si verifica un'eccezione oppure non succede nulla?