Newsgroup: it.comp.os.linux.sys
Titolo: Server "piegato"

Salve a tutti,
ho una slackware 10.2-current installata su un sempron 2600 + hd-ide
80gb  + 512mb ram su una banda da 10mbit sul quale gira solamente un
sito dotato di cms mkportal e forum Invision Board 2.1.4. Come media di
traffico circa 300gb/mese e 100.000 visite/mese, una board abbastanza
trafficata.
Dal primo giorno che ho installato tutto, la macchina raggiungeva
carichi mostruosi freezzando praticamente il server, dmesg riportava
simili messaggi:
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
__alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Ho cercato in ogni modo di capire la causa, la memoria viene
completamente mangiata e apache + mysql spawanano processi a gogo.
Le ho provate tutte, ricompilato kernel, compilato a mano
apache+php+mysql con tutte le ottimizzazioni possibili (tutto alle
ultimissime release). Ho utilizzato strace, lsof, ps aux e analizzato i
log ma nulla di tutto ciò mi ha fatto scovare la causa.
Io credo sia una qualche funzione del forum che pieghi il server dato
che ho provato a tenere down il cms per 1 settimana, e il problema
persisteva. Oppure, possibilità dubbia secondo me, il server non riesce
davvero a reggere il carico...anche se una volta riavviato apache in
condizioni di piena utenza per un po (anche ore) non succede nulla.
L'unico modo per rendere la cosa funzionale è stato settare il KeepAlive
 di apache "off" (lo so, è una porcata ma è stata l'unica soluzione).
Ora il server non scoppia più, ma è troppo lento..e ci credo poveretto,
avra tanti di quei child da tirare su e killare :)
I timeout del php sono quelli standard, 30 secondi e il php è compilato
con il memory_limit fissato a 8mb come max.
Precedentemente il sito era in hosting presso un noto ISP low cost
italiano, insomma i classici hosting da 20 euro con tutto illimitato,
avete capito sicuramente. Il sito era veloce e non faceva crashare
nessun server, ma funzionava a metà a causa di alcune ristrettezza nei
settaggi per questo ho deciso di spostarlo su una macchina dedicata. A
questo punto mi chiedo....o usavano qualche strumento x arginare questi
 prosciugamenti di memoria oppure si tratta davvero di un problema di
carico, che ovviamente sui loro server non sussisteva causa load
balancers & co.
Avete qualche idea di come identificare il problema?
Grazie in anticipo

 
Ho trovato questo thread che, anche se vecchio, sembra fare al caso tuo:
http://lists.suse.com/archive/suse-linux-e/2003-Jul/1209.html
il mio di server raggiunge carichi più alti (una decina di volte come 
pagine/mese, vari db con pgsql, posta elettronica ecc), il traffico 
delle ultime 24h da fra ingresso e uscita da una 20a di gbyte, ma c'è 
anche un bixenon, 2 gb di ram e hd scsi con raid hardware.. E ti posso 
assicurare che ogni tanto entro via ssh ed il pargolo mi da il prompt 
dopo una decina di secondi (collegato via ethernet)
Lo swap come è messo?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Non e' che ho paura di morire.  E' che non vorrei essere li' quando
succede.
		-- Woody Allen

 trafficata.
devo farci un attimo mente locale, qualche tempo fa ho dato una
mano per problemi simili su invision board, il problema era con
mysql e non ne parli, quello l'hai controllato?

 trafficata.
Aumenta, e di brutto, la memoria di quel server.
Quello che ti consiglio è di limitare in apache il numero di child massimi
che puoi aprire.
Di default è a 150 che è un numero accettabile per la maggior parte dei
casi, ma ti bastano 50 processi che accedono a mysql per saturarti un bel
pò di memoria. Con 50 child che occupano 6 mega l'uno, sei a 300 mega.
mettici mysql, mettici il resto ed ecco che la ram l'hai saturata.
Se poi consideri che ogni child ha il rispettivo child di mysql collegato
beh, la situazione peggiora.
Ok, c'è la swap no ?
La swap in questi casi non serve a nulla.
Imposta il maxchild ad un numero "ragionevole" e vedrai che il problema si
risolve.
Devi solo fare un paio di tentativi per trovare il numero giusto.
Usa le connessioni per manenti a mysql.
Se invision ha qualcosa per chachare le pagine, abilitalo.
Max

 Lo swap come è messo?
Quando entra in gioco la swap (1GB)  è già troppo tardi. In condizioni
normali è libera:
             total       used       free     shared    buffers     cached
Mem:        482888     476296       6592          0       8244     249316
-/+ buffers/cache:     218736     264152
Swap:       987988       2460     985528

frick ha scritto:

Effetticamente mysql potrebbe essere la causa. Ho provato ad attivare il
metodo pconnect e sembra quasi andare meglio....sto toccando troppi
parametri per dare un parere oggettivo. Vi riporto la configurazione del
mio my.cnf, giusto i pezzi salienti.
Ho effettuato anche diverse ottimizzazioni a IPB, eliminando anche
operazioni cpu intensive.
Stato attuale con la configurazione sotto esposto:
             total       used       free     shared    buffers     cached
Mem:        482888     411200      71688          0       7364     257024
-/+ buffers/cache:     146812     336076
Swap:       987988       2460     985528
Situazione di medio carico. La memoria libera (cachata) varia anche di
100-200mb in base ai momenti.
[mysqld]
max_connections = 300
port            = 3306
socket          = /var/run/mysql/mysql.sock
skip-locking
skip-innodb
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 2048K
net_buffer_length = 8K
read_buffer_size = 512K
read_rnd_buffer_size = 1024K
myisam_sort_buffer_size = 8M
query_cache_type = 1
query_cache_size = 6M
query_cache_limit = 1M
thread_concurrency = 2
interactive_timeout = 100
wait_timeout = 1800
connect_timeout = 10
tmp_table_size = 32M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 64M
sort_buffer_size = 64M
read_buffer = 8M
write_buffer = 8M
[mysqlhotcopy]
interactive-timeout
Configurazione httpd:
KeepAlive Off (uccide la macchina in breve tempo)
MinSpareServers 10
MaxSpareServers 25
StartServers 10
MaxClients 70
MaxRequestsPerChild 100 ( se lo lascio a zero, illimitati, la macchian
tende a rallentare e comportarsi tipo keepalive on)

 Max
Ciao e grazie ancora.

Sp180MHR ha scritto:

Mica vero, dipende da cosa fa il server in quel momento.
Se lo swap ti permette di parcheggiare un processo al momento non utilizzato 
ok, certo non puoi swappare processi apache che stanno servendo un utente e 
sperare che il disco non diventi una stufetta
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
- Secondo te, Ivan, si puo' costruire il socialismo nel Liechtenstein?
- No.  E' cosi' piccolo che non lo sopporterebbe.
		-- Citata da Danilo Acquisti

 che ne pensate
Io metterei il keepalive a ON
e Maxchilds a 25.
Aumentandolo poi pian piano nelle ore di maggio carico per vedere cosa
succede.
Max

Un aggiornamento sulla questione...mi sono ahime accorto che nel cron
restartavo apache ogni 10 minuti x non fare scoppiare il server...ho
tolta questa "porcata" e il server ovviamente muore, quindi tutti i
tuning effettuati non sono mai stati veritieri, tantomeno utili :(



a meno del mio primo consiglio: "aumenta la ram" che non hai ancora
provato.
E diminuisci, ribadisco, i Maxclients a 20-25 e poi aumentali pian piano.
Max

CtRiX ha scritto:

Credo sia proprio il caso di upogradare il bidonazzo a 1gb :)
Stasera sotto carico provo con i MaxClients e vi faccio sapere.
Grazie

Sp180MHR ha scritto:

Un commento personale (anche se le macchine sono diverse):
avevo la macchina che quando arrivava ai 250 processi aveva un carico dai 30 
in su, con conseguente stonfo delle prestazioni.
Stamani ho fatto quello che viene normalmente sconsigliato (ovvero abilitare 
la cache del controller scsi da write-thru a write-back, politica di 
read-ahead aggressiva) ed il risultati non si č fatto attendere:
  Thu Jan 26 11:28:24 CET 2006 up: 04:02, 2 users, 303 procs, load=4.40
Praticamente i processi erano sempre in stato D e i dischi erano sempre a 
fare accessi, adesso lavorano in modo molto piů blando.
Fra le altre cose ho pure portato il maxclient di apache da 60 a 100
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Finalmente sono giornalista anch'io adesso, e i fatti non mi interessano
piu'.
		-- Pat Buchanan