Newsgroup: it.comp.os.linux.sys
Titolo: Linux Centos 5.1 non usa Swap

Ciao a tutti,
ho un Server CentOS 5.1 che ha la partizone di swap /dev/sda2 definita ed 
attivata (ho anche fatto swapoff e swapon e mkswap /dev/sda2).
Su questa macchina gira qmail toaster e gli utenti usano pesantemente (oltre 
30Gb di mail store) courier Imap.
Ho 4 Giga di RAM; quando gli utenti entrano tutti Courier IMAP aumenta 
l'allocazione di RAM e arriviamo ben presto al fondo!
Il problema è che l'utilizzo della swap, partizione di 8 Gb, non viene 
assolutamente iniziato, e rimane 0 usati di Swap.
Ho rifatto nuovamente:
swapoff /dev/sda2
mkswap /dev/sda2
swapon /dev/sda2
ma nulla... come potrei fare per mettere in funzione quella Swap?
Grazie, ciaooo!
Francesco

 assolutamente iniziato, e rimane 0 usati di Swap.
Magari i 4Gb sono sufficienti e basta? :)
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

> Il che significa che la ram e' sufficiente.
Però quando arrivo a cirac 100Mb liberi di memoria RAM fisica Courier imap 
si impalla ed è strano... non vorrei andare offtopic su questo NG però 
segnalo soltanto che quando tutti gli utenti ci lavorano pesantemente e la 
RAM libera arriva a 100/150 MB tutto diventa estremamente lento.
Se digito da consolle telnet localhost 143, aizichè aprirsi subito il banner 
come fa a sistema scarico, il cursore rimane stallato per anche 30/40 
secondi e poi arriva il banner.
Dai Client di posta la situazione è disastrosa.
Ecco perchè ho pensato alla swap e alla RAM... grazie!
Ciao,
Francesco 

 Ecco perchè ho pensato alla swap e alla RAM... grazie!
hai il kernel con le estensioni PAE?

Andrea B. wrote:

4GB e ancora coi 32 bit?????

 ed attivata (ho anche fatto swapoff e swapon e mkswap /dev/sda2).
L'hai anche definita in fstab, vero? Postalo.

 4GB e ancora coi 32 bit?????
Dipende da cosa ci devi fare.
Se hai applicazioni che usano dati a 32 bit, usare OS a 64bit può 
significare ritrovarsi con metà della memoria inutilizzabile per via del 
padding...

 Se hai applicazioni che usano dati a 32 bit, 
Tipo?

 Tipo?
Il primo esempio che mi viene (perchè c'ho a che fare tutti i giorni) è 
"tanti IP", nel mio caso un DNS.
Passare il server da 32 a 64 bit ha il risultato di raddoppiare il 
memory-footprint della zona...

 "tanti IP", nel mio caso un DNS.
Bind cioe' usa il doppio della memoria che nel caso precedente? E sarebbe?

 Bind cioe' usa il doppio della memoria che nel caso precedente? E sarebbe?
Ho detto che è DNS, non che è bind. Nello specifico di quel caso, se 
vuoi dettaglio, rbldnsd.
Ma penso che si trattasse di bind non cambierebbe assolutamente nulla 
(ma facessi fare lo stesso lavoro a bind, dovrei almeno quintuplicare la 
memoria che riservo a quelle macchine).
Comunque il senso voleva essere: per utilizzi "generici", probabilmente, 
la differenza di occupazione di memoria è scarsamente percepibile o 
"calmierata" da altri vantaggi. Per alcuni utilizzi specifici, comunque, 
usare i 64 bit è uno svantaggio, ed è preferibile rimanere sui 32.
Non sempre "di più" è necessariamente meglio.

 usare i 64 bit è uno svantaggio, ed è preferibile rimanere sui 32.
D'accordo, ma io vorrei i hard numbers. Cosi' mi sembrano solo chiacchiere 
di sensazioni a pelle che lasciano davvero il tempo che trovano.
Fai le misure e postale che saranno sicuramente utili ad altri.
P.S. dov'e' l'op?

 Fai le misure e postale che saranno sicuramente utili ad altri.
Non sono "a pelle": le misure le ho già fatte "a suo tempo", quando 
dovevo decidere se eseguire quei ruoli suarchitettura Alpha o x86 (era 
il 2005 credo, forse prima).
All'epoca, il memory-footprint era di 523 MB su 64bit e di 285 su 32bit.

 4GB e ancora coi 32 bit?????
Con 4GB siamo ancora nei limiti dei 32 bit
Enrico

 il 2005 credo, forse prima).
Eh no no no!
Una cosa e' x86_64 vs i386, ben altra e' alpha! 
Su alpha dovevi confrontare coi 32 bit dei vax (che giravano con vms, ben 
diverso da unix fra l'altro. Non ricordo se du girasse su queste macchine, 
credo pero' di no). Da quel punto di vista il codice alpha era un vero 
disastro: gli eseguibili partivano da *minimo* un fattore 3.
Ben altro discorso con x86_64, moolto piu' efficiente (e grazie, compare 
13 anni dopo...).
Dato che ho sempre riscontrato differenze marginali di footprint su questi 
due resto alquanto stupito.

Enrico 'Henryx' Bianchi wrote:

3.5 < 4. Poi iniziano i casini.

> L'hai anche definita in fstab, vero? Postalo.
Eccoci, grazie!
Francesco
[root@mail ~]# cat /etc/fstab
LABEL=/                 /                       ext3    defaults        1 1
LABEL=/var              /var                    ext3    defaults        1 2
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/sda2                none                    swap    sw        0 0

 due resto alquanto stupito.
Io invece ho quasi sempre riscontrato occupazione di Ram sensibilmente
superiore.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.



si, ma sei al limite, e non puoi usare la swap, hai finito lo spazio di
indirizzamento...
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 ma nulla... come potrei fare per mettere in funzione quella Swap?
Che dicono:
swapon -s
cat /proc/sys/vm/swappiness


 Una cosa e' x86_64 vs i386, ben altra e' alpha! 
Bah. Il codice è codice e il kernel è il kernel.
Parliamo sempre di binario compilato per linux (debian su alpha e debian 
su x86), mica di VMS, eh...
Giusto per la cronaca, e per fugare ogni dubbio, quella roba lì ora gira 
su macchine virtuali. Potevo eseguire VM a 32 bit o VM a 64 bit, a me 
non cambiava niente. Un test empirico con una zona campione mostra 
ancora lo stesso identico overhead che riscontravo sugli Alpha, da cui 
la scelta di eseguire tutt'ora il DNS in ambiente a 32 bit.
D'altra parte, non è che ci siano alternative o spiegazioni 
"fantasiose": un IP è un dato di 32 bit. Metterlo in una word da 64 
significa buttarne via metà. Non molte vie di girarci attorno a meno di 
non fare le magie nel codice.
Se vuoi, te lo spiega Tokarev di persona:
http://www.corpit.ru/pipermail/rbldnsd/2007q4/000841.html

 non fare le magie nel codice.
E' ovvio, ma io parlavo di altro non di dns.

Francesco wrote:

Non capisco bene. La riga di swap e' solo:
/dev/sda2 none swap   sw 0 0 
e basta? Perche' la quarta colonna dovrebbe essere 
swap
non sw.

 Bah.
Bah che? Per te queste cpu sarebbero uguali?

 E' ovvio, ma io parlavo di altro non di dns.
Io no, e mi pareva di averlo detto molto chiaramente 4 o 5 post fa...
Adios.

 binario, che è sostanzialmente indipendente dall'architettura.
Quindi in sostanza:
ti ho chiesto di confrontare i footprint dei *programmi*, non dei *dati* 
che e' ovvio, del software a 32 e 64 bit di alpha. E tu non hai niente a 
riguardo.
Per quanto riguarda invece quello del codice x86_64 vs i386 il risultato 
sostanzialmente non cambia come e' ben noto, ed ho parecchia statistica a 
riguardo.
In buona sostanza tutto il thread e' inutile, in quanto io ho chiesto una 
cosa ben precisa e tu mi rispondi con un'altra.
Peccato perche' ero interessato all'argomento. Nessuno ha niente a 
riguardo?

 cosa ben precisa e tu mi rispondi con un'altra.
Direi che ti stai inventando un thread che non c'è stato:
<quote>
 > 4GB e ancora coi 32 bit?????
Dipende da cosa ci devi fare.
Se hai applicazioni che usano dati a 32 bit, usare OS a 64bit può 
significare ritrovarsi con metà della memoria inutilizzabile per via del 
padding...
</quote>
Quale parte della parola "dati" ti era sfuggita, fin dapprincipio?

 swap
Dalla man page di fstab:
The  fourth  field, (fs_mntops), describes the mount options associated
with the filesystem.
Detto questo, e leggendo la man page di swapon, l'unico argomento
associabile in quel campo di fstab, ed accettato durante il mount della
partizione di swap, e` pri=<valore>
Enrico

 partizione di swap, e` pri=<valore>
Eppure l'ho visto in diversi fstab (debian) quel sw.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 non sw.
Davvero, Valeria?
E da dove lo evinci?
Semmai, in altre notazioni, si usa
<partizione>  swap   swap   defaults   0 0
D'altra parte, non avere una partizione definita in fstab non ha mai
pregiudicato la possibilità di usarla.
-- 
AOFH

 Quale parte della parola "dati" ti era sfuggita, fin dapprincipio?
Gli è sfuggita la parte sublimale in cui gli dicevi "intervieni ad ogni
costo anche se non hai nulla da dire".
f/u


 Eppure l'ho visto in diversi fstab (debian) quel sw.
Anche nel mio fstab c'e` sw. Probabilmente serve da "riempitivo", consci
del fatto che che qualsiasi valore diverso da pri=<valore> viene ignorato
Enrico

 esplodeva come occupazione in memoria, come ti dicevo.
Premesso che mi posso certamente sbagliare: AFAIK, i processori alpha
non hanno e non hanno mai avuto una modalita' 32bit, ne' tantomeno
alcuna compatibilita' binaria con i processori vax. VMS e' stato
*portato* di sana pianta sulla nuova architettura alpha.
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 diverso da unix fra l'altro. 
Beh... *storicamente*, dec vax e' stato, dopo il pdp-11, architettura
d'elezione per bsd unix (e sviluppo di ipc e networking...). :-)


 E' ovvio, ma io parlavo di altro non di dns.
A me mica pare tanto ovvio, se uno alloca l'IP come uint32_t rimane a 
32bit anche con un processore a 64bit, se lo alloca usando in_addr_t 
(come fanno gli header standard) sara` ugualmente a 32bit, rapido test 
su una RH EL a 64bit:
#include <stdio.h>
#include <arpa/inet.h>
int main() {
     printf("Size of IP: %d long: %d int: %d\n", sizeof(in_addr_t), 
sizeof(long), sizeof(int));
}
[mct@N0611413 /tmp]$ gcc -m64 test.c
[mct@N0611413 /tmp]$ ./a.out
Size of IP: 4 long: 8 int: 4
Il memory footprint cresce su sistemi a 64bit principalmente per colpa 
dei puntatori, ma su x86_64 cresce molto meno su altre architetture (ad 
esempio l'alpha citata nel thread).
Bye,
  Gabry

 una cosa ben precisa e tu mi rispondi con un'altra.
<quote1>
Se hai applicazioni che usano dati a 32 bit, usare OS a 64bit può 
significare ritrovarsi con metà della memoria inutilizzabile per via del 
padding
</quote1>
<quote2>
Passare il server da 32 a 64 bit ha il risultato di raddoppiare il 
memory-footprint della zona...
</quote2>
Keywords: dati, zona.
Leggere, talvolta, può essere di una qualche utilità. <beg>

 padding
Scusa ma di che padding parli?
Sono programmatore prima che sistemista e so benissimo che:
struct { in_addr_t addresses[5000]; } myaddr;
Alloca 20kbyte sia su macchine a 16,32,64bit, non c'e' nessun padding, 
su x86 non ci sono restrizioni particolari su dove mettere i dati, da 
quanto mi risulta il padding a 8 byte e` obbligatorio solo sui double 
nell'architettura SPARC tra i sistemi con cui ho avuto a che fare di 
recente.
E solo su un double, quindi il tremendo padding lo hai solo se hai una 
struttura PESSIMA di questo tipo:
char
double
char
double
int
double
Che alloca 48 byte dove su una CPU a 32bit ne occuperesti solo 36.
ma gia' se hai tipo:
char
char
int
double
double
double
Il padding si riduce a 2 byte (allocazione totale 32bytes)
E' vero che se ti allochi degli array di puntatori occupi piu` memoria, 
ma l'uso dei puntatori (gli unici promossi a 64 bit) sulla percentuale 
dei dati di un'applicazione media e` limitata, l'esempio del DNS di cui 
si parlava nel thread e` sicuramente usato a sproposito se si vuole dire 
che e` meglio usare i386. Altri messaggi del thread hanno spiegato come 
su x86_64 il "bloat" dovuto ai 64bit e` minimo rispetto ad altre 
architetture risc "pure", come alpha, che hanno pure gli operandi delle 
operazioni a 64bit per rendere piu` "semplice" la gestione della pipeline.

 che e` meglio usare i386.
Eh, il problema è che proprio no... :-\
Leggi 
http://www.corpit.ru/pipermail/rbldnsd/2007q4/000841.html
Bye!