[Gnoll]

se vuoi aumentare di velocità il tutto ti consiglio di installare lighttpd al posto di apache, è molto piu performante.

[Ego-Ale-Sum]

uhm... cioè, l'aver cambiato 2 valori ha ridotto il carico così tanto? wow...

[Pid]

Questo è il nuovo conf:

[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
#skip-innodb
skip-bdb
max_connections = 2000
query_cache_min_res_unit = 16K
key_buffer = 64M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 512
table_cache = 1024
thread_concurrency = 8
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 80M
tmp_table_size = 128M
max_heap_table_size = 32M
innodb_buffer_pool_size = 128M
join_buffer_size = 1M

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Il vecchio è qualche pagina indietro.

[MnEm0nIc]

cosa hai cambiato?

[Pid]

Ragazzi tutto risolto, grazie a MySQL Tuner (che vi consiglio), mi ha suggerito cosa regolare nel my.cnf per ottimizzare mysql e ora con binlog attivato sembra tutto ok.. speriamo bene!!!
PS: grazie a tutti

[MnEm0nIc]

n-mila richieste le fa per forza visti gli n-mila utenti online contemporaneamente, dove possibile ho usato memcached e in ogni caso fino a qualche giorno fa mysql usava il 70-80% della cpu.

Che guaio

per n-mila richieste intendo richieste inutili che aumentano il carico sul db...

e l'indicizzazione? l'hai fatta?

[Ego-Ale-Sum]

a questo punto, direi anche io che è un problema col codice.

posta la struttura del tuo database. magari c'è un errore lì dentro.
questa volta ti "obbligo" ad usare un db non relazionale

PS: se la tua è un'applicazione Facebook, suppongo che tu chiami spesso le API remote via REST. hai pensato di mettere qualche cache (su memcached o file) anche lì dentro?

PS2: domanda stupida, ma... quando ti connetti a mysql, usi le connessioni persistenti?

[Pid]

n-mila richieste le fa per forza visti gli n-mila utenti online contemporaneamente, dove possibile ho usato memcached e in ogni caso fino a qualche giorno fa mysql usava il 70-80% della cpu.

Che guaio

[MnEm0nIc]

Fatto tolto il vecchio messo il nuovo e non ho dovuto usare il backup.
MA il problema è rimasto :S

hai provato ad indicizzare il database? non e' che ci sono problemi nel codice php (o quel che sia) che fa n-mila richieste al db?

[Pid]

Fatto tolto il vecchio messo il nuovo e non ho dovuto usare il backup.
MA il problema è rimasto :S

[MnEm0nIc]

E come torno alla versione vecchia in modo indolore ?

dovresti poterlo fare con yum-allowdowngrade che e' un plugin per yum..

oppure come ha detto Ego-Ale-Sum...

[Pid]

giusto -.-

[Ego-Ale-Sum]

è in linea con tutto il discorso fatto finora, con il bug di mysql 5.0.84..

[Pid]

Allora mi conviene farlo in nottata, un altra cosa strana è che adesso mysql carica un pò troppo:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6851 mysql 20 0 195m 42m 4608 S 205.7 0.5 5:46.24 mysqld

quel 205 a %CPU non è esagerato? (scusate tutte le domande ma sto imparando )

[Ego-Ale-Sum]

non so dirti i comandi esatti per centos, però l'idea è questa:
1. metti offline il sito per qualche minuto
2. fai un dump del database
3. rimuovi MySQL
4. rimuovi il repository "incriminato"
5. install la versione "stabile" di MySQL
6. ricarichi le tabelle dal dump..

direi che è la via più sicura e "indolore" (a parte un piccolo downtime)

[Pid]

E come torno alla versione vecchia in modo indolore ?

[MnEm0nIc]

Si, il pacchetto è preso da una repo ufficiosa, in ogni caso il carico si presentava anche con MyISAM infatti è da poco che sono passato a InnoDB.

non e' consigliabile utilizzare pacchetti da repo ufficiosi, a meno di esigenze particolari (tipo avere php 5.2 invece che il 5.1.x etc etc). solitamente quando distribuzioni come redhat (che ci fanno business con gnu/linux) non aggiornano ad una determinata versione e' perche' non e' ancora ben testato e quindi e' sconsigliato usare versioni successive. con questo non voglio dire assolutamente che bisogna prendere per oro colato quello che fanno, ma che vedrei con un occhio particolare determinate scelte.

il consiglio, a questo punto, e' quello di fare un rollback alla versione presente su centos 5.4 e vedere cosi' come funziona.

non ho mai usato pgsql... che vantaggi porta rispetto a MySQL?
in ogni caso, postgree è sempre un database relazionale: ultimamente sento il bisogno di convertirmi (ove possibile) a database non relazionali... ho notato molti miglioramenti...

beh diciamo che postgresql e' piu' robusto di mysql anche per le repliche, per esempio... oppure per l'I/O asincrono.
postgresql scala molto bene in "altezza", ovvero con un'alta concorrenza sulla stessa macchina, oltre ad avere una migliore indicizzazione con forti risparmi di tempi per le query.
le considerazioni su quale e' migliore, poi, dipendono dalle varie esigenze e di confronti ce ne sono vari in rete, anche se qualcuno e' datato.

ciao

[Pid]

Si, il pacchetto è preso da una repo ufficiosa, in ogni caso il carico si presentava anche con MyISAM infatti è da poco che sono passato a InnoDB.

[Ego-Ale-Sum]

in ultimo, un consiglio non richiesto: per il futuro prova ad usare postgresql che e' meno giocattoloso di mysql..

non ho mai usato pgsql... che vantaggi porta rispetto a MySQL?
in ogni caso, postgree è sempre un database relazionale: ultimamente sento il bisogno di convertirmi (ove possibile) a database non relazionali... ho notato molti miglioramenti...

[MnEm0nIc]

uhm... ti dirò: non ho mai usato redhat (centos?), quindi non saprei aiutarti di preciso... mi sembra comunque una versione recente, del ramo 5.0...

ciao, da una rapida ricerca su google, ho trovato un bug per la release di mysql che usi attualmente che porta all'innalzamento del carico con InnoDB in determinate condizioni.
prova a riutilizzare MyISAM indicizzando quanto piu' possibile le tabelle.

non so quanto possa funzionare ma a questo punto non resta che provare o cambiare versione di mysql.

tra l'altro su una mia macchina dove c'e' centos 5.4 (aggiornata meno di una settimana fa) la versione di mysql e' la 5.0.77 . non e' che hai preso questo pacchetto da un repository non ufficiale?

[root@fserv03 ~]# cat /etc/redhat-release
CentOS release 5.4 (Final)
[root@fserv03 ~]# yum info mysql.i386 | grep Version
Version    : 5.0.77

in ultimo, un consiglio non richiesto: per il futuro prova ad usare postgresql che e' meno giocattoloso di mysql..

my 2 cents

[Ego-Ale-Sum]

uhm... ti dirò: non ho mai usato redhat (centos?), quindi non saprei aiutarti di preciso... mi sembra comunque una versione recente, del ramo 5.0...

[Pid]

mysql Ver 14.12 Distrib 5.0.86, for redhat-linux-gnu (i686) using readline 5.1

5.0.86

PS: ti va di aggiungermi su msn (se lo usi) e darmi una mano lì?

[Ego-Ale-Sum]

incredibile...
ma che versione di MySQL usi? non ho mai notato cose simili.

[Pid]

Riattivato Binary Log con Indici, in 1 minito il load è schizzato da 1.5 a 17.47 e continua a salire...

[Ego-Ale-Sum]

forse la ragione è proprio questa del load enorme... non hai creato indici guarda: potrebbe cambiare tutto completamente!

comunque, puoi aggiungere indici a tabelle già esistenti: verranno creati al momento (ovviamente questo richiederà un po': il tempo dipende dalla dimensione della tabella)

[Pid]

Eheh grazie della bella spiegazione, in ogni caso strano ma è così senza binary log carico a 2.00, con 200.00 (domani riprovo ad abilitarlo, chi lo sa O.o).
Bella anche la dritta degli indici ora ci lavoro, non si finisce mai di imparare
Grazie ancora eh

Però domanda se già ho una tabella piena e setto un campo come index, non è che ci sono problemi?

[Ego-Ale-Sum]

uhm.... non te lo consiglio.
oltretutto: http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

Running the server with the binary log enabled makes performance about 1% slower. However, the benefits of the binary log for restore operations and in allowing you to set up replication generally outweigh this minor performance decrement.

mi sembra strano che sia solo il binary log a fare questo carico...

per quanto riguarda la query... sintatticamente, è corretta. ma è veramente sconsigliata.
un po' di teoria, prima: come funziona MySQL...

supponiamo di avere una tabella con delle righe, ciascuna delle quali ha un id.
ora voglio eseguire la query:
SELECT * FROM tabella WHERE id = 10
I dati sono salvati su file, ma quasi sempre sono in disordine totale. Quindi, il problema ora è: come trovo la riga con id = 10?
La soluzione più semplice e immediata è: passo le righe una ad una finchè non trovo quella con id 10, e la restituisco. Questo funzionerebbe perfettamente, se non fosse che la sua complessità media, in una tabella di N righe, è O(N/2). Questa notazione, se non l'hai mai vista, significa che sono eseguite *in media* N/2 operazioni (in questo caso, accessi al file). dico in media perché, essendo i dati sparsi, potrebbero essere all'inizio della lista come anche alla fine. la media, comunque, è la metà.
significa che se la tua tabella ha 1.000.000 di righe, ogni volta che selezioni un record devi fare in media 500.000 letture!!! è inaccettabile!!

Per questo, quindi, MySQL (e ogni altro database) utilizza gli indici.
I dati in memoria vengono salvati in un BTREE (Binary Tree o Albero Binario; se sei curioso su come funzionano: http://en.wikipedia.org/wiki/B-tree ). In questo modo, la ricerca di un record è ESTREMAMENTE più veloce: O(log2(N)) (con log2 intendo logaritmo in base 2). tornando all'esempio di prima (tabella con 1.000.000 di righe), la ricerca di un record richiederà SOLAMENTE 20 accessi!!! (log2(1000000) è circa 20). Rispetto a 500.000, la differenza è enorme.

Ora, detto questo...
Quando tu fai una query come quella che ho messo, in cui metti una funzione (ad esempio md5, ma anche operazioni algebriche ecc) dentro un campo, non puoi usare gli indici, e la complessità della query resta sempre O(N/2).
quindi, se devi fare una ricerca con un valore md5, la soluzione è quella di creare un'altra colonna in cui salvi già il valore md5 della stringa.

PS: altra conseguenza di tutto questo discorso, a cui non avevo pensato... ricordati di mettere gli indici alla tabella vanno messi in ogni campo che usi con frequenza nelle clausule WHERE. un indice occupa spazio (anche molto: ho tabelle in cui gli indici soli occupano il 50% dello spazio totale della tabella), ma quando esegui il codice è molto, molto più veloce, soprattutto al crescere della dimensione della tabella. ripasso di matematica: confronta le due funzioni... http://img402.imageshack.us/img402/11/immagine3f.png

[Pid]

Ho disattivato il "Binary Log" di mysql è il carico sul server sembra sparito, ora il load si aggira su 2.5-3 invece di 200 (anche con il KeepAlive abilitato o.o)

PS: che c'è di sbagliato nella query?

[Ego-Ale-Sum]

ah, poi... dimenticavo

è ESTREMAMENTE importante anche il modo in cui scrivi le query... ci sono molti "errori" possibili, che possono degradare di molto le performance.

ad esempio:
SELECT * FROM tabella WHERE MD5(uncampo) = '6e6bc4e49dd477ebc98ef4046c067b5f'
cosa c'è di sbagliato in questa query?

[Ego-Ale-Sum]

hai convertito tutto in InnoDB?

in ogni caso, InnoDB è vantaggioso soprattutto quando lo usi bene... ad esempio, se devi inserire molti dati contemporaneamente (molte query), ha le transazioni: la avvii prima di eseguire le query e fai un commit alla fine. non solo questo fa in modo che l'operazione sia atomica (quindi non hai mai problemi di concorrenza), ma risparmi moltissime risorse.
InnoDB è comodo anche perchè i lock sono implementati a livello di riga e non di tabella: difficilmente, quindi, la tabella sarà bloccata interamente.
i vantaggi sono anche nell'integrità del database: in caso di crash, InnoDB recupera i dati molto più velocemente di MyISAM.
se fai delle ricerche, comunque, trovi molte informazioni a riguardo: google -> "innodb vs myisam"
ad esempio: http://www.mysqlperformanceblog.com/...hmarks-part-1/

comunque il punto resta sempre uno: usa MySQL il meno possibile.
usa sempre più database "alternativi", come memcached (la cui utilità migliora con l'aumentare del rapporto read/write delle query: se hai più query in lettura che scrittura, l'aumento di performance è più elevato) o database non relazionali.
(in effetti, il vantaggio/problema principale di MySQL è proprio il fatto che sia relazionale)

[Pid]

l'ho convertita ora spero si noti qualche differenza, a me sembrano peggiorate le performance. :S

[Ego-Ale-Sum]

tutte sono convertibili in innodb, tranne quando usi indici fulltext (ma qui non ne vedo).

[Pid]

CREATE TABLE `pers_stats` (
`id` bigint(20) NOT NULL,
`usi` int(9) NOT NULL,
`thumb` varchar(255) character set latin1 NOT NULL,
`nome` varchar(255) character set latin1 NOT NULL,
`picture` text character set latin1 NOT NULL,
`frasi` text character set latin1 NOT NULL,
`approvato` tinyint(1) NOT NULL,
`autore` bigint(20) NOT NULL,
`tipo` int(2) NOT NULL,
`data_cr` date NOT NULL,
`voti` int(6) NOT NULL default '0',
`nome_autore` text character set latin1 NOT NULL,
`u_voti` text character set latin1 NOT NULL,
`n_voti` int(10) NOT NULL,
`modificabile` tinyint(1) NOT NULL default '1',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

ad esempio, questa tabella non è convertibile in InnoDB giusto?

[Ego-Ale-Sum]

per MySQL...
la configurazione di default direi che non è malvagia.

intanto, ti consiglio di usare InnoDB sempre. è molto più performante di MyISAM.
se hai bisogno di fare delle fulltext, questo diventa un po' un problema, però: in tal caso, o usi MyISAM per quella tabella, o (forse meglio) usi Sphinx http://www.sphinxsearch.com/
considera anche, eventualmente, l'utilizzo di google perftools per MySQL: http://www.dotdeb.org/2008/08/25/usi...-mysql-server/ questo sito distribuisce pacchetti DEB che contengono, tra le altre cose, anche MySQL e PHP aggiornati. li uso da tempo e mi sono sempre trovato bene.

comunque...mysql resta sempre un problema il trucco è cercare di utilizzarlo il meno possibile: usare molto sistemi come memcached, e quando non hai bisogno di un database relazionale, usare CouchDB o MongoDB o simili.
spostare il mysql su un altro server potrebbe aiutare molto, poi.

[Pid]

Sisi, lo so

Ora rimane solo mysql da regolare, dritte?

Visto che a quanto pare è pesantuccio

[Ego-Ale-Sum]

Grazie delle dritte, ho installato APC e Memcache e sembra essere migliorato.

prego.

solo una piccola precisazione, che mi fai venire un dubbio... APC si è sufficiente installarlo... Memcache invece devi usarlo memcache è una cache in memoria: devi essere tu ad inserire e togliere i dati...
usando PHP, comunque, è abbastanza semplice: www.php.net/memcached (questa è l'estensione migliore, ma è solo in PECL) o www.php.net/memcache (quella più vecchia, che però spesso trovi anche in apt già pacchettizzata).
inserisci nella cache usando $cache->set() e leggi usando $cache->get(). se usi le sessioni di php, poi, puoi anche impostare che vengano salvate nella cache invece che su file.

[Pid]

non è che per caso il problema non sia specifico alla configurazione di Apache/MySQL, ma sia più generico?? nel senso, che tu abbia bisogno di ricorrere a qualche misura per rendere più scalabile il tutto

ad esempio...
1. se non l'hai già fatto, installa il modulo APC di PHP, che evita che gli script siano ricompilati ogni volta
2. considera di aggiungere memcache in alcuni punti: potrebbe essere necessario fare modifiche ai tuoi script
3. dove non strettamente necessario, considera il passaggio a database non relazionali. il problema più grande di MySQL è proprio il suo essere un database relazionale. aggiungere, dove possibile, altri strumenti come CouchDB, MongoDB ecc.

se questo non basta... passiamo ai livelli successivi
1. considera di sostituire apache con lighttpd o nginx.
2. sposta il MySQL su un server dedicato solo a lui
3. considera l'aggiunta di un altro server (magari meno potente) per gestire i file statici, serviti da nginx.
4. considera l'aggiunta di un altro server e di bilanciare il carico tra i due.

Grazie delle dritte, ho installato APC e Memcache e sembra essere migliorato.

[Ego-Ale-Sum]

non è che per caso il problema non sia specifico alla configurazione di Apache/MySQL, ma sia più generico?? nel senso, che tu abbia bisogno di ricorrere a qualche misura per rendere più scalabile il tutto

ad esempio...
1. se non l'hai già fatto, installa il modulo APC di PHP, che evita che gli script siano ricompilati ogni volta
2. considera di aggiungere memcache in alcuni punti: potrebbe essere necessario fare modifiche ai tuoi script
3. dove non strettamente necessario, considera il passaggio a database non relazionali. il problema più grande di MySQL è proprio il suo essere un database relazionale. aggiungere, dove possibile, altri strumenti come CouchDB, MongoDB ecc.

se questo non basta... passiamo ai livelli successivi
1. considera di sostituire apache con lighttpd o nginx.
2. sposta il MySQL su un server dedicato solo a lui
3. considera l'aggiunta di un altro server (magari meno potente) per gestire i file statici, serviti da nginx.
4. considera l'aggiunta di un altro server e di bilanciare il carico tra i due.

[vhs]

Si,

attualente è ok

[Pid]

http://apps.facebook.com/sentichiparla/
Ma ora va abbastanza bene, è da verificare nelle ora di punta (12-13, 20-21-22)

[vhs]

solo pe info puoi postare l'indirizzo del sito?

[Pid]

Magari fosse un problema mio, putroppo è generalizzato.

[vhs]

allora credo che non sia quello il problema....erò il keepalive devi lascairlo su off non è che magari ha un qualche problema con l'adsl? prova ad usare host tracker e vedi in quanto tempo carica la pagina

[Pid]

max request child settato a 6.000 è ancora lento (prima era 3.000)

[Pid]

MYSQL:

[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
#skip-innodb
skip-bdb
max_connections = 10000
query_cache_min_res_unit = 8K
key_buffer = 256M
max_allowed_packet = 16M
thread_stack = 256K
thread_cache_size = 512
table_cache = 1024
thread_concurrency = 8
query_cache_type = 1
query_cache_limit = 16M
query_cache_size = 64M

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[vhs]

prova allora a rialzare il max request child oppure metttilo a 0 ........e vediamo come va per il mysql non mi prende il file con ie

[Pid]

Ciao,
ho seguito le tue indicazione ed effettivamente il server non va più in sovraccarico, c'è però da dire che il caricamento del pagine e mooolto più lento, anche troppo... :S

[vhs]

Ciao,

disattiva innanzitutto il keepalive e mettilo su off

MaxRequestChild metti un valore molto piu basso di almeno 1/4 di quello che hai messo

Fammi sapere

Ciao

PS ServerSignature On mettilo su off per una tua maggiore sicurezza

[Pid]

Salve a tutti,
ho acquistato da poco un EG BestOF perchè ho la necessità di hostare una applicazione facebook.
Però ho alcuni problemi, il server va facilmente in sovraccarico.
L'applicazione ha una media di 1.500-2.000 utenti connessi e circa 100.000 accessi unici giornalieri.

PS: con sovraccarico intendo valori di load mostruosi:

top - 15:33:11 up  3:11,  1 user,  load average: 333.31, 618.42, 836.42
Tasks: 2063 total, 1887 running, 176 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.5%us,  2.4%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   8251544k total,  6508948k used,  1742596k free,    99836k buffers
Swap:  1051376k total,        0k used,  1051376k free,  1865924k cached

Per caso sbaglio qualcosa nella configurazione?
Apache: http://www.cdevlab.eu/apache.conf
MySQL: http://www.cdevlab.eu/mysql.cnf

Grazie in anticipo.