Facendo un confronto far i log e l'orario dei picchi ho notato che l'utilizzo di una pagina in particolare, che tra le altre cose utilizza una funzione jquery per la gallery. Ora mi chiedo se potrebbe essere quella funzione a rallentare il sistema. In particolare lo script è la gallery highslide. Questa pagina è stata controllata e non mi risultano connessioni appese. Tra l'altro questa è la pagina + visitata e ciò mi porta a credere che sia qui il problema. Come potrei fare un log degli eventi generati della stessa?

L'unico modo è modificare il codice dello script.

Ho verificato tutti gli script, modificandoli all'occorrenza. Ma il risultato non è cambiato. Ho anche provato a lanciarele pagine visualizzate nel fase del blocco come da log, ma nessuna di queste pagine ha fatto impennare l'uso della CPU. Cosa molto strana è che la memoria è come se rimanesse bloccata per un arco di tempo che varia da secondi ad alcuni minuti per poi azzerarsi dopo un po.

Potrebbe essere un problema di server o di banda?

Ciao Salentu.com,
e se fosse semplicemente che la pagina riceve più accessi negli ultimi tempi, magari per un riposizionamento nella serp di google?

Si sa che gli script più o meno preconfezionati mangiano risorse...

Perché non verifichi il numero di accessi giornalieri alla pagina prima e dopo il problema?

Le pagine sono state create da me stesso, e ho verificato il tutto nei minimi particolari, compresa la chiusura di tutte le connessioni. é possibile che il problema sia dovuto al numero di accessi, ma ho verificato il numero di accessi sulle singole pagine nell'istante in cui si verifica il problema e al max ho registrato 10 accessi contemporanei sulla pagina. Ho fatto dei test per verificare anche il consumo nell'istante in cui apro le pagine e ogni pagina appena completato il caricamento svuota la memoria.

Come detto prima l'aumento può essere quantificato in un 10%, ma non +.

Il massimo che puoi fare è appunto verificare gli accessi e controllare la correttezza del codice.

Se il problema persiste ci sono dei memory leakage in IIS. In questo caso purtroppo puoi farci ben poco.

L'ultima cosa che potresti fare è modificare lo script incriminato e aggiungere un pò più di verbosità. Gli fai scrivere in un file la ram consumata in un dato momento, registri il timestamp delle visite, gli fai tracciare una mappa delle varie variabili allocate e del loro consumo di memoria. Di più non puoi fare.

Eccomi di nuovi qui, con il solito problema. Vi aggiorno un po sulla situazione. Il problema è dovuto al traffico generato da un sito in particolare, ma credo che il problema fondamentale sia dovuto a mysql

In pratica da quello che ho capito quando ci sono molti accessi questi congelano la memoria e quindi l'intero server, che poi riprende a funzionare quando questa si sblocca. In pratica le pagine si aprono ma a volte impiagano anche 1 minuto.

Ho visto che mysql ha dei picchi di traffico di 35 mb (questo l'ho verificato dal pannello di mysql administrator) anche se la webfarm dove risiede il server mi dice che il picco massimo di banda utilizzata è di 7mb.

Il server risiede su una linea a 10mb dedicati,

qui di seguito riporto la mia configurazione mysql, magari ci sono degli errori nella stessa che portano a ciò.

 
[client]
port=3306
[mysql]
default-character-set=latin1
 
[mysqld]
port=3306
 
default-character-set=latin1
default-storage-engine=myisam
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
 
max_connections=200
 
query_cache_size=0
 
table_cache=64
 
tmp_table_size=100M
 
thread_cache_size=8
#*** MyISAM Specific options
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
 
myisam_sort_buffer_size=199M
 
key_buffer_size=256M
 
read_buffer_size=64K
read_rnd_buffer_size=256K
 
sort_buffer_size=256K
 
#*** INNODB Specific options ***
 
innodb_additional_mem_pool_size=7M
innodb_flush_log_at_trx_commit=1
 
innodb_log_buffer_size=4M
innodb_buffer_pool_size=328M
 
innodb_log_file_size=164M
 
innodb_thread_concurrency=8
wait_timeout=20
 

Come potete vedere ho impostato il valore wait_timeout a 20 secondo, in modo da svuotare eventuali connessioni rimaste aperte o bloccate.

Quello che ho notato e che da quando si è verificato il problema la connessione ftp si disconnette o si congela prima del timeout impostato da sistema. Altra cosa anomala, pur avendo questi disservizi le visite sono aumentate in questi giorni.

35 MB non mi sembrano incredibili per mysql, anzi sono pochini.

Se c'è un problema del genere vuol dire che asp mantiene le vecchie connessioni aperte invece di chiuderle, per cui ovviamente mysql è costretto a gestire sempre più connessioni e consuma sempre più memoria.

Avevo pensato la stessa cosa e ho controllato le connessioni una ad una ma vengono tutte chiuse. inoltre guardando dal pannello di mysql il limite max raggiunto di connessioni aperte è stato di 64, che non mi sembra eccessivo.

Dico una banalità probabilmente: hai verificato se c'è qualche query in particolare che crea problemi? Magari effettuata su qualche campo non indicizzato?

Quindi si tratta proprio di traffico. Addirittura siamo a 64 connessioni aperte, ben al di sotto del limite impostato nel file di configurazione.

E consuma 35 MB di memoria che francamente sono un'inezia.

Effettivamente il problema e sorto nelle ultime 2 settimane, con l'aumento delle visite. Sul sito sono presenti 150 siti che in questo periodo generano un traffico di 25000 accessi.

Potrebbe essere un problema di processore, che non riesce a gestire tutto questo traffico. Il processore è un intel E6600 2,4 ghz.

Il processore non è certo un mostro e ovviamente tutto dipende dal carico a cui è sottoposto.

Puoi monitorare l'attività della cpu e vedere come si comporta. Però 150 siti e 25000 unici metterebbero ko chiunque.