Author Topic: Picchi 100% mSQL con SMF (Read 8150 times)

aga21 · « **on:** August 01, 2013, 02:46:05 PM »

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 · « **Reply #1 on:** August 02, 2013, 09:10:05 AM »

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 · « **Reply #2 on:** August 04, 2013, 02:31:13 PM »

Pronti:

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

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

emanuele · « **Reply #3 on:** August 04, 2013, 03:13:29 PM »

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 · « **Reply #4 on:** August 04, 2013, 05:05:02 PM »

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 · « **Reply #5 on:** August 05, 2013, 06:55:08 AM »

Quote from: emanuele on August 04, 2013, 03:13:29 PM

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]

ALTER TABLE nome tabella ENGINE=InnoDB;

emanuele · « **Reply #6 on:** August 05, 2013, 07:46:33 AM »

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 · « **Reply #7 on:** August 05, 2013, 09:02:34 AM »

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

aga21 · « **Reply #8 on:** August 06, 2013, 05:59:58 AM »

Penso fosse proprio quello il problema, grazie.

Segno il topic come risolto.

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

aga21 · « **Reply #9 on:** August 16, 2013, 03:48:49 AM »

Purtroppo si sono ripresentati

aga21 · « **Reply #10 on:** August 19, 2013, 11:01:37 AM »

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]

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

ora sembra andare

emanuele · « **Reply #11 on:** August 19, 2013, 11:37:05 AM »

Quali tabelle hai convertito a innodb?

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

aga21 · « **Reply #12 on:** August 19, 2013, 12:17:52 PM »

Quote from: emanuele on August 19, 2013, 11:37:05 AM

Quali tabelle hai convertito a innodb?

Le due che mi hai suggerito

Quote

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 · « **Reply #13 on:** August 19, 2013, 12:33:20 PM »

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 · « **Reply #14 on:** August 19, 2013, 12:44:38 PM »

Il grafico mi sembra chiaro:

aga21 · « **Reply #15 on:** August 19, 2013, 06:37:43 PM »

non riesco proprio a capire

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

Code: [Select]


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 · « **Reply #16 on:** August 20, 2013, 04:05:10 AM »

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

aga21 · « **Reply #17 on:** August 20, 2013, 10:58:41 AM »

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 · « **Reply #18 on:** August 21, 2013, 10:54:49 AM »

Ho rimesso dei valori più alti per

Code: [Select]

tmp_table_size 
max_heap_table_size 
key_buffer_size

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

aga21 · « **Reply #19 on:** August 21, 2013, 12:46:48 PM »

Ovviamente ricomincia.

MA questa query cosa fa?

Code: [Select]

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 · « **Reply #20 on:** August 21, 2013, 02:55:21 PM »

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 · « **Reply #21 on:** August 21, 2013, 04:01:06 PM »

Eccolo

http://37.139.12.127/varie/Recent.zip

emanuele · « **Reply #22 on:** August 21, 2013, 04:48:59 PM »

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 · « **Reply #23 on:** August 22, 2013, 02:17:27 AM »

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 · « **Reply #24 on:** August 22, 2013, 09:02:07 AM »

e infatti:

emanuele · « **Reply #25 on:** August 22, 2013, 09:37:17 AM »

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

aga21 · « **Reply #26 on:** August 22, 2013, 02:52:13 PM »

Quote from: emanuele on August 22, 2013, 09:37:17 AM

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 · « **Reply #27 on:** August 23, 2013, 04:59:16 AM »

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 · « **Reply #28 on:** August 23, 2013, 06:15:05 AM »

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

aga21 · « **Reply #29 on:** August 23, 2013, 09:52:51 AM »

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

aga21 · « **Reply #30 on:** August 23, 2013, 10:03:01 AM »

Niente da fare, ha ricominciato con gli stessi problemi.

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

Code: [Select]

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 · « **Reply #31 on:** August 23, 2013, 10:41:57 AM »

Quote from: aga21 on August 23, 2013, 10:03:01 AM

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

Te l'ho scritto qualche post fa.

aga21 · « **Reply #32 on:** August 23, 2013, 10:54:17 AM »

Quote from: emanuele on August 23, 2013, 10:41:57 AM

Quote from: aga21 on August 23, 2013, 10:03:01 AM
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 · « **Reply #33 on:** August 23, 2013, 10:55:08 AM »

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 · « **Reply #34 on:** August 23, 2013, 11:03:59 AM »

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 · « **Reply #35 on:** August 23, 2013, 11:11:58 AM »

Quote from: emanuele on August 23, 2013, 11:03:59 AM

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 · « **Reply #36 on:** August 23, 2013, 11:15:08 AM »

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 · « **Reply #37 on:** August 23, 2013, 11:21:42 AM »

Quote from: emanuele on August 23, 2013, 11:15:08 AM

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 · « **Reply #38 on:** August 23, 2013, 11:24:54 AM »

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

aga21 · « **Reply #39 on:** August 23, 2013, 12:02:57 PM »

incrociamo le dita

aga21 · « **Reply #40 on:** August 26, 2013, 01:27:27 AM »

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

News:

Author Topic: Picchi 100% mSQL con SMF (Read 8150 times)