Newsgroup: it.comp.os.linux.sys
Titolo: Risorse di un server

Hola, ieri ho contattato un fornitore per una proposta di housing virtuale.
Chiaccherando sul dimensionamento � rimasto stupito dei 32 gb richiesti dal 
server di posta..
 
Attualmente detto server ha assegnati 32 gb da xen e ha i dati su san in 
fibra.
Con 16 gb il sistema si siedeva clamorosamente (con log e servizi bloccati 
per minuti mentre gli altri server appoggiati alla stessa san erano li che 
andavano tranquilli), con 32 manco riesco a leggere i log con tail -f perch� 
son troppo veloci.
Attualmente ho poco meno di 1000 caselle (pop3) con postfix/dovecot, una 
webmail (openwebmail da sostituire presto), un paio di milter come filtro il 
tutto appoggiato su postgres per utenti e caselle.
 
 
dettagli di pflogsumm per la settimana pscorsa:
Grand Totals
------------
messages
 
  99345   received
 126489   delivered
     18   forwarded
   1051   deferred  (14001  deferrals)
   1631   bounced
  35516   rejected (21%)
   3256   reject warnings
      0   held
      0   discarded (0%)
 
  18258m  bytes received
  29151m  bytes delivered
  22346   senders
   9121   sending hosts/domains
  17690   recipients
   6442   recipient hosts/domains
 
smtpd
 
  138660   connections
   16375   hosts/domains
 
 
C'� qualcosa che non va o ha torto il fornitore (che mi parlava di 10.000 
caselle gestite da un singolo server con 16 gb di ram?)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

son troppo veloci.
 
Un lavoro cosi' lo fa un blocco dvro sull'I/O. Ma la RAM non ti aiuta molto
sul sustained in un caso del genere... a meno che ti eviti lo swap. E cioe'
potrebbe essere stato un caso di threshing.
 
Bisognerebbe vedere chi e' che si mangia la memoria in quel sistema, e poi,
perche'.
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 caselle gestite da un singolo server con 16 gb di ram?)
 
Per la sola componente pop/imap e relativo local delivery una macchina
con un paio di GB di RAM per 1K utenti basta e avanza, I/O sui dischi
permettendo, dato che è lì dove i problemi stanno veramente, e al
riguardo non fornisci alcun dettaglio.
 
Se sulla stessa macchina girano poi anche le componenti di filtraggio (a
partire da spamassassin), queste ovviamente richiedono risorse
aggiuntive che van messe nel conto, ma anche con quelle 32GB occupati
son davvero tanti.
 
 
Innanzitutto dovresti fare un po' di profiling per capire cosa si mangia
le risorse, sennò si parla di aria fritta.
 

 le risorse, senn� si parla di aria fritta.
 
In tutti i casi la memoria era per la maggior parte segnata come cached.
Anche adesso ho una situazione di questo tipo:
 root@mx:~# free
             total       used       free     shared    buffers     cached
Mem:      31470488   30622388     848100          0     333756   28657416
-/+ buffers/cache:    1631216   29839272
Swap:     13260792          0   13260792
 
quando si bloccava il load saliva a livelli alti e avevo n processi in D, un 
sync poteva bloccare tutto per qualche minuto.
Lo stesso un riavvio del server, in quelle condizioni c'� stato fino a 10 
minuti fermo sul postfix start (ho provato a mettere un log pi� 
particolareggiato ma non � uscito un granch�).
 
Davo la colpa alla SAN ma gli altri vhost erano li tranquilli che giravano 
(se era la SAN ad avere problemi avrebbe bloccato anche gli altri).
Non c'� spamassassin, c'� clamd (invocato da milter-clamc) e milter-link.
Le rbl pi� invocato son su dns locale.


 particolareggiato ma non è uscito un granché).
 
Se t'aspetti di riuscire ad identificare problemi di 'sto genere
partendo dai log, sei molto ottimista :-D
Più o meno come pianificare di diventare milionario iniziando a cercare
per terra un biglietto vincente caduto a qualcuno ;-)
 
Consiglio l'uso di qualcosa che possa monitorare e graficizzare l'uso
delle diverse risorse nel tempo (io sono affezionato a munin, ma ci sono
diverse alternative). Vedere quali sono le anomalie coincidenti ai
disservizi è molto più immediato; poi da lì si punta ai log specifici...
 
 

 disservizi � molto pi� immediato; poi da l� si punta ai log specifici...
 
C'� munin installato ma ho dovuto azzerare i dati quando ho cambiato server 
(per avere 32 gb son passato da centos 5 a 6 con reinstallazione server e 
munin non aggiornava i grafici)


 server e munin non aggiornava i grafici)
 
Debian no ? :-D
 
Comunque con un setup simile al tuo mi serve circa il 10% della tua 
memoria.
 

 memoria.
:(
 
non riesco a capire dov'è l'inghippo... al primo aggiornamento di xen (con 
conseguente riduzione di memoria per i vari vhost) guardo che succede
 
Anche se mi viene un dubbietto:
server solo web, carico abbastanza basso, centos 5.8:
 
ro...@tosnet2.tosnet.it
~# hdparm -tT /dev/xvda
 
/dev/xvda:
 Timing cached reads:   21768 MB in  1.99 seconds = 10959.43 MB/sec
 Timing buffered disk reads:   16 MB in  3.14 seconds =   5.10 MB/sec
 
 
Stessa solfa ma sul server di posta, centos 6.2:
 
root@mx:/etc/munin/plugins# hdparm -tT /dev/xvda
 
/dev/xvda:
 Timing cached reads:   12898 MB in  1.98 seconds = 6524.35 MB/sec
 Timing buffered disk reads:  994 MB in  3.01 seconds = 330.77 MB/sec
 
 
C'è una leggerissima differenza fra i 2 dati...
e altri con centos 5.8 fanno più o meno lo stesso: certo che se trasferisce 
5 mb al sec lo credo che ci sono seri problemi


 trasferisce 5 mb al sec lo credo che ci sono seri problemi
 
I/O su disco lento ti alzerebbe a palla anche il load average della 
macchina.
 
Comunque per capire cosa stia usando la memoria, riavvia un servizio alla 
volta e vedi cosa cambia.
Comincia da clamav !
 
Max

 Debian no ? :-D
 
No (e te lo dice uno a cui manca la politica di gestione dei file di 
configurazione dei web server usata in Debian) :P
 
Enrico

particolareggiato ma non è uscito un granché).
 
Scusami se insisto sullo stesso tasto: un colpetto di iotop?


 Max


 
 
sabato ho messo i vecchi 16 gb come limite di memoria:
Load sempre sotto 1, log dovecot/postfix che sembrano scritti in ram invece 
che su disco,sync che ci mette un secondo e non 5 minuti...
Sarebbe carino sapere come mai la 5.x andava così piano.


 Sarebbe carino sapere come mai la 5.x andava così piano.
 
Non ho capito la relazione tra memoria e versione del S.O.
 
Ad ogni buon conto, non è che in dovecot hai INDEX=MEMORY ??
 
Sulla ML hanno segnalato problemi simili al tuo in questi casi.

 Sulla ML hanno segnalato problemi simili al tuo in questi casi.
 
ma ora va benissimo..
e comunque vero è che hdparm non è "rilevante" ma anche su altri server 
(sempre 5.8) c'è una differenza abissale.
Quali parametri potrei mettere per un test con bonnie++?


 Quali parametri potrei mettere per un test con bonnie++?
 
Non so esserti utile per bonnie.

 Quali parametri potrei mettere per un test con bonnie++?
 
Non è che hdparm non sia rilevante, il problema è capire quale sia 
l'esatto workload IO che la macchina deve gestire. Ogni sistema storage 
ha le sue peculiarità.
 
hdparm può essere il primo tool per avere una stima indicativa, 
bonnie++ può darti qualche dettaglio in più, in quanto ti permette di 
fare dei test sia per block che per char.
 
Un altro strumento un po' più flessibile potrebbe essere iozone:
 
http://www.iozone.org/
 
 
Con le giuste opzioni potresti simulare il tuo workload (probabilmente 
un accesso in scrittura/lettura a un macello di file piccoli).
 
Fare il benchmark ragionato di sottosistemi storage non è una cosa 
banale.
 
I miei 2 cents.