Ho ricevuto una comunicazione dal mio hosting providing in cui si dice:-"many of your databases having slow or large queries. We would ask you look into this ASAP..".
Sono andato ad analizzare le query debuggate e si tratta di query di questo tipo, + o - su tutti i DB
1 - SELECT r.nid, MATCH(r.body, r.title) AGAINST ('....qui dentro TUTTO il CONTENT in HTML.....') AS score FROM node_revisions r INNER JOIN node n ON r.nid = n.nid AND r.vid = n.vid WHERE n.status <> 0 AND r.nid <> 6039 AND n.type IN ('blog','feed_item_published','0','0') GROUP BY n.nid HAVING score > 0 ORDER BY score DESC, r.vid DESC LIMIT 0, 5;
2 - INSERT INTO cache (cid, data, created, expire, headers, serialized) VALUES ( ......TUTTI I DATI da INSERIRE ...)
3 - UPDATE feeds_schedule SET feed_nid = 6425, id = 'feed1', callback = 'import', last_executed_time = 1283277620, scheduled = 0 WHERE id = 'feed1' AND callback = 'import' AND feed_nid = 6425;
4 - SELECT n.nid FROM node n LEFT JOIN search_dataset d ON d.type = 'node' AND d.sid = n.nid WHERE d.sid IS NULL OR d.reindex <> 0 ORDER BY d.reindex ASC, n.nid ASC LIMIT 0, 100;
5 - INSERT INTO search_index (word, sid, type, score) VALUES ('parola', 5534, 'node', 62);
6 - UPDATE cache SET data = '.... TUTTI I DATI .....', created = 1283277743, expire = 0, headers = '', serialized = 1 WHERE cid = 'feeds_http_download_1835b0bf50b88ea80ffa034074ec5e33';
7 - UPDATE sessions SET uid = 0, cache = 0, hostname = '.... HOSTNAME ::::', session = 'mobile-tools-mobile-device|a:2:{s:4:"type";s:7:"desktop";s:5:"group";s:0:"";}mobile-tools-site-type|s:6:"mobile";masquerading|N;', timestamp = 1283277862 WHERE sid = 'f6c742804a439ce7d6f85b648b270dbf'
8 - SELECT SUM(score) FROM search_index WHERE word = 'parola';
9 - SELECT t.word AS realword, i.word FROM search_total t LEFT JOIN search_index i ON t.word = i.word WHERE i.word IS NULL;
10 - SELECT COUNT(*) AS count, d.tid, d.name, d.vid FROM term_data d INNER JOIN term_node n ON d.tid = n.tid WHERE d.vid IN (15) GROUP BY d.tid, d.name, d.vid ORDER BY count DESC LIMIT 0, 30;
11 - SELECT nc.nid FROM node_comment_statistics nc WHERE nc.comment_count > 0 ORDER BY nc.last_comment_timestamp DESC LIMIT 0, 10;
12 - SELECT t.tid, t.*, parent FROM term_data t INNER JOIN term_hierarchy h ON t.tid = h.tid WHERE t.vid = 15 ORDER BY weight, name;Non so se sono tutte le query ma posso garantire che il problema coinvolge tutti o quasi tutti i DB.
Ultimamente ricevevo una volta al giorno una segnalazione da un trigger che mi informava di una query che è stata killata perchè ha superato 1min circa di esecuzione. Questi messaggi si riferivano in particolar modo a query sull'indice delle tabelle search (vedi query 4 e 9).
Nell'elenco delle query debuggate vengono riportate anche query che agiscono sulle tabelle node e node_revision.
Bisogna considerare che il cron viene eseguito ogni 30min e che le tabelle indicate (le tabelle node e qualle search hanno un numero decisamente molto grande di righe che vanno dalle 20.000 alle 80.000 righe ed oltre e sono in continuo e rapido aumento.
Bisogna anche considerare che il Backup dei dati viene fatto ogni 4h perchè vengono inseriti content nuovi continuamente, in ogni momento. Il backup cmq viene fatto 1DB per volta ed una Tabella per volta, posso cmq spostarlo a 6h.
Analizzando le impostazioni di performance di uno dei siti presi a campione risconto che la Modalità di Cashing è impostata su NORMAL, che la Durata minima della cache è impostata su Nothing e che l'unico Cashing attivato è quello della pagina (no blocchi, no css, no javascript, ecc).
Mentre nei Search Settings è impostata l'indicizzazione di 100 oggetti ad ogni esecuzione del cron.
Noto anche analizzando le query, una gran rottura che già sapevo, cioè che DRUPAL riempe il DB di tanta spazzatura che poi si trascina dietro inutilmente. In particolare, quando disinstalli un modulo, restano sempre dati inutilizzati sul DB che però, in caso di cashing o altro vengono traferiti qua e la inutilmente (o qualcosa di simile). La tabella system è sempre piena di questa spazzatura.
Come devo fare a migliorare i problemi di questi LARGE DBs? ...
... la cosa può diventare preoccupante presumo.
credo che non ci sia nulla di strano, ma sicuramente è buona regola seguire alcune indicazioni quando si utilizza un qualsiasi CMS:
- Non utilizzare troppi moduli, si cerca sempre di minimizzare il loro uso attorno a quelli strettamente necessari
- Il Cron ogni 30 Min è eccessivamente "pesante" per un sito che non ha cambiamenti così veloci: per intenderci il cron esegue spesso un grande numero di operazioni se si ha molti moduli attivi, se il vostro sito non ha un "commento" ogni 30 min, oppure un nuovo contenuto ogni 30 min, l'esecuzione del cron è solo un grande spreco di risorse. Per fare un esempio Drupalitalia.org potrebbe necessitare di un Cron ogni 30Min, ma il mio blog che riceve si o no 1 commento al giorno va bene un cron ogni 12 ore ...
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
I siti web in questione pubblicano molti nodi ogni 30min x tale il cron è lanciato ogni 30min.
Per quanto riguarda i moduli, si cerca sempre di utilizzare i necessari e nulla di + e nel tempo si tende sempre a ridurli il più possibile.
Potrebbe essere che il grande numenro di nodi crei query pesanti o che richiedono un grande periodo di tempo per completarle, al fine di creare gli indici di ricerca.
Può essere che la cache adrebbe meglio gestita?
Come ottimizzo queste problematiche?
http://www.sanisapori.eu
Sei stiamo parlando di siti web con tali mole di dati dovrebbe mettere in conto il fatto che l'hosting non sia in grado di gestire una tale mole di dati. Es. Drupalitalia su un hosting di scarse risorse non starebbe in piedi 5 miunti...
- Con o senza Cache il Cron viene lanciato, e sopratutto il cron rigenera la Cache il più delle volte, in base alle impostazioni;
- La cache ottimizza in fase di "visualizzazione" evitando di effettuare Query in quel frangente...
- Se il problema riguarda il Cron le consiglio di Guardare bene cosa "gli fanno fare" i moduli al cron... magari c'è qualche modulo che si "inchioda" ed entra in un Loop
- Se l'indicizzazione di Drupal risulta troppo lunga ed onerosa da parte del hositing potrebbe utilizzare moduli alternativi come la Ricerca di Google che vede in questo forum. Al momento non ho link a portata di mano ma facendo una ricerca su drupal.org credo siano di facile reperimento
Slice2Theme Servizio per la conversione di Design in markup HTML e/o temi.
WeBrain Solution | Pillsofbits Of Bits
Ho notato che lanciando TABLE CHECK da phpMyAdming ho due righe conseguenti riferite alla stessa tabella user una con un warning ed una con ok
Se io lancio TABLE ANALYZE non ottengo nessun messaggio di errore..
Se io lancio TABLE REPAIR le tabelle vengono riparate con successo, ma se a seguire lancio di nuovo TABLE CHECK ottengo lo stesso errore.
La cosa è comune a quasi tutti i DB che ho analizzato al momento, cioè 4 su 10.
Magari questo influisce particolarmente.
http://www.sanisapori.eu