Picchi 100% mSQL con SMF

[aga21]

Ciao, siamo passati a una VPS decisamente più performante visto che Hostgator ci mandava offline spesso.

Il problema è relativo all'utilizzo di mysql, allego una schermata di htop









Come posso risolvere?

[emanuele]

Premesso che purtroppo non sono un grande esperto di server.

Questi picchi durano a lungo?
Il "load average" non sembra particolarmente alto.
Ho chiesto ieri sera su IRC SleePy ha suggerito che potrebbe essere un problema di configurazione di MySQL, ma non è entrato nei dettagli (è andato via poco dopo).
Se puoi, prova a postare i paramentri di configurazione di MySQL.

[aga21]

Pronti:

http://www.basketforum.it/status.php

e visto che ci sono, dove posso trovare sphinx per smf 2.04?

[emanuele]

Una cosa che mi è venuta in mente ora e che posso suggerirti è: innodb.

Ti conviene convertire almeno:
* smf_messages
* smf_topics
per iniziare.

Questo aiuta ad evitare che le tabelle vengano bloccate in attesa di completare la precedente operazione.

Per sphinx dammi qualche minuto che lo cerco.

[Tanakino]

Vi seguo da vicino perchè ho avuto gli stessi guai con Hostgator e anche io sto passando ad un VPS .. però non capisco un acca di quello che dite/fate ..


T.

[aga21]

Una cosa che mi è venuta in mente ora e che posso suggerirti è: innodb.

Ti conviene convertire almeno:
* smf_messages
* smf_topics
per iniziare.

Questo aiuta ad evitare che le tabelle vengano bloccate in attesa di completare la precedente operazione.

ok, cosa uso per la conversione?

Code Select Expand

ALTER TABLE nome tabella ENGINE=InnoDB;

[emanuele]

Sì, dovrebbe essere quello il comando:
http://dev.mysql.com/doc/refman/5.5/en/converting-tables-to-innodb.html
(quelle poche volte che l'ho fatto ho usato phpMyAdmin, e non mi ricordo la sintassi )

[aga21]

Il carico sembra essere diminuito, vedo ancora dei picchi ma sporadici.

[aga21]

Penso fosse proprio quello il problema, grazie.

Segno il topic come risolto.

P.S. Per il resto ti ho mandato un mp.

[aga21]

Purtroppo si sono ripresentati

[aga21]

Controllando i LOG ho notato che il problema era nella temporary table e allora in my.cnf ho inserito dei valori piuttosto alti:

Code Select Expand


tmp_table_size = 128M
max_heap_table_size = 128M
key_buffer_size = 64M


ora sembra andare

[emanuele]

Quali tabelle hai convertito a innodb?

Sei sicuro dei 64M del key_buffer_size?
Mi sembrano un po' tanti...

[aga21]

Quali tabelle hai convertito a innodb?

Le due che mi hai suggerito

Sei sicuro dei 64M del key_buffer_size?
Mi sembrano un po' tanti...

per ora sembra andare bene, magari lo riduco poi, ho un giga di ram.

[emanuele]

Altre che puoi convertire sono:
* smf_log_boards
* smf_log_mark_read
* smf_log_topics
Queste dovrebbero essere quelle che si allungano di più e che quindi traggono maggior vantaggio dall'usare innobd.
Tieni conto che più usi innodb, più RAM usi.

[aga21]

Il grafico mi sembra chiaro:

[aga21]

non riesco proprio a capire

guardando status.php ci sono un sacco di messaggi come questo

Code Select Expand



Copying to tmp table 131s

SELECT m.id_msg
FROM smf_messages AS m
INNER JOIN smf_boards AS b ON (b.id_board = m.id_board)
INNER JOIN smf_topics AS t ON (t.id_topic = m.id_topic)
WHERE (FIND_IN_SET(-1, b.member_groups) != 0)
AND m.id_msg <= b.id_last_msg
ORDER BY m.id_msg DESC
LIMIT 5



e ovviamente la cpu al 100 per 100

[emanuele]

Cosa c'è di diverso dopo circa le 4 e mezza quando i "picchi" smettono?

[aga21]

Avevo modificato i valori nella configurazione di mysql.

per un po' è andato bene, poi ricomincia.

sono costretto a killare i processi o far ripartire mysql per evitare che rimanga piantato

[aga21]

Ho rimesso dei valori più alti per

Code Select Expand


tmp_table_size
max_heap_table_size
key_buffer_size


e adesso non va più al 100 per 100, spero non ricominci

[aga21]

Ovviamente ricomincia.

MA questa query cosa fa?

Code Select Expand

SELECT m.id_msg
FROM smf_messages AS m
INNER JOIN smf_boards AS b ON (b.id_board = m.id_board)
INNER JOIN smf_topics AS t ON (t.id_topic = m.id_topic)
WHERE (FIND_IN_SET(-1, b.member_groups) != 0)
AND m.id_msg <= b.id_last_msg
ORDER BY m.id_msg DESC
LIMIT 5

[emanuele]

Quella non è la query che stai cercando.
Comunque è utilizzata per:
http://www.simplemachines.org/community/index.php?action=.xml;sa=recent

Allora, proviamo una cosa che ha funzionato altrove, allegami Recent.php.

Intanto che ci sei, se non l'hai già fatto, dato che ora hai una VPS, disabilita il "Utilizza sessioni con il supporto del database" (almeno un paio di query in meno a page load ).

[aga21]

Eccolo

http://37.139.12.127/varie/Recent.zip

[emanuele]

Da quel che vedo al momento sembra tranquillo.

Altra domanda prima di proporti il cambio che ho in mente: hai abilitato il bilanciamento del carico? Portebbe aiutare.

Sono indeciso, ma proviamo ugualmente...
Ha funzionato in un carto contesto, che però non son sicuro sia questo: c'erano delle query che impiegavano molto tempo ad essere completatale, queste rallentavano così tanto il sistema che forzavano le altra in code e le query si accumulavano fino a diventare un numero ingestibile ed il processo doveva essere killato.
Il motivo per cui le query rallentavano era per via della creazione di tabelle temporanee durante la visualizzazione degli "unread" e "unreadreplies".
La soluzione (o forse sarebbe meglio dire il workaround) è stato di forzare SMF a non ricorrere alle tabelle temporanee.

Che è quello che ho fatto nel file allegato (....a dir la verità mi chiedo perché te l'ho fatto allegare... sorry, sono un po' fuori in questi giorni... xD) cerca i due "false &&" per vedere le modifiche.

[aga21]

L'unica modifica che ho fatto per ora è quella di eliminare tutti i temi tranne quello di default, pensavo che la query fosse legata alla visualizzazione di qualche blocco con gli ultimi post

[aga21]

e infatti:

[emanuele]

Il grafico cosa vuol dire?
Che hai killato il processo? Ma quando? Alle 6 ieri seta o alle 8 o...

[aga21]

Il grafico cosa vuol dire?
Che hai killato il processo? Ma quando? Alle 6 ieri seta o alle 8 o...

Da quando ho eliminato gli altri template e riavviato mysql il problema non si è più verificato

[emanuele]

Hai *solo* eliminato dei temi?
Non hai caricato il file che ho postato, non hai modificato altri settaggi?
Quanto è lunga la tabella smf_themes?

[aga21]

Non ho fatto altre modifiche se non mettere forzatamente a tutti gli utenti il tema di default.

[aga21]

mi fa impazzire. improvvisamente verso le 14 solito processo che inchioda tutto ed è così da 2 ore, ora provo a sostituire quel file.

[aga21]

Niente da fare, ha ricominciato con gli stessi problemi.

Si può sapere cosa è questa query e perchè ci sta così tanto?

Code Select Expand

SELECT m.id_msg
FROM smf_messages AS m
INNER JOIN smf_boards AS b ON (b.id_board = m.id_board)
INNER JOIN smf_topics AS t ON (t.id_topic = m.id_topic)
WHERE (FIND_IN_SET(-1, b.member_groups) != 0)
AND m.id_msg <= b.id_last_msg
ORDER BY m.id_msg DESC
LIMIT 5

[emanuele]

Si può sapere cosa è questa query e perchè ci sta così tanto?

Te l'ho scritto qualche post fa.

[aga21]

Si può sapere cosa è questa query e perchè ci sta così tanto?

Te l'ho scritto qualche post fa.

Scusami, non ci avevo fatto caso. E' il feed RSS? Non posso eliminarla?

[emanuele]

Come ho scritto in precedenza, quella non è il tuo problema.

La schermata in allegato è molto più significativa: se vedi sono tutti waiting for "table level lock", questo significa che una tabella è bloccata da un processo.
Qual'è la tabella comune a tutte quelle query?
smf_board
Prova a convertirala a innodb.

[emanuele]

Ohhh.... LOL
Quella è *anche* il tuo problema.

Tu hai un setup abbastanza inusuale: hai tutte le board nascoste.
Cosa succede: siccome quella query va a cercare i primi 5 topic che un visitatore può vedere, fa la scansione di *tutti* i topic del database in tutte le board, ecc.
Quindi è una query che ci impiega una vita nel tuo specifico caso.

Ora, domanda: perché non hai semplicemente disabilitato l'accesso al forum ai visitatori?

[aga21]

Ohhh.... LOL
Quella è *anche* il tuo problema.

Tu hai un setup abbastanza inusuale: hai tutte le board nascoste.
Cosa succede: siccome quella query va a cercare i primi 5 topic che un visitatore può vedere, fa la scansione di *tutti* i topic del database in tutte le board, ecc.
Quindi è una query che ci impiega una vita nel tuo specifico caso.

Ora, domanda: perché non hai semplicemente disabilitato l'accesso al forum ai visitatori?

Il forum era su IPB e ha ereditato tutti questi settaggi. Quindi devo rendere "pubbliche" tutte le board e poi disabilitare l'accesso ai visitatori?

[emanuele]

O puoi anche disabilitare l'accesso ai visitatori e basta.
E disabilitare i feed xml (admin > principale > news e newsletter > impostazioni), non c'è motivo per averli attivi se i visitatori non possono accedere forum.

[aga21]

O puoi anche disabilitare l'accesso ai visitatori e basta.
E disabilitare i feed xml (admin > principale > news e newsletter > impostazioni), non c'è motivo per averli attivi se i visitatori non possono accedere forum.

Fatto tutte e due le cose

(admin > configurazione > funzioni ed opzioni > generale e togli la spunta a "Permetti ai visitatori di navigare sul forum")
Admin -> News and Newsletters -> Settings Check the box next to "Enable XML/RSS News".

Da dove vedo se le board sono nascoste come mi hai detto tu?

[emanuele]

admin > forum > sezioni
Clicca sul "modifica" di fianco ad ogni board e vedrai che l'accesso ai visitatori è disabilitato.

[aga21]

incrociamo le dita

[aga21]

Due giorni senza nessun problema, penso di aver risolto. Grazie per l'indispensabile aiuto.