|
|
|
![]() |
|
Strumenti |
![]() |
#1 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Come permettere a un processo di sfruttare più di 4Gb di RAM in Linux 32/64 bit?
Come da oggetto.
Immaginate di avere un serverone con 16 GB di RAM, e un unico processo che occupa più di 4GB di RAM (potenzialmente arriva anche a tutti e 16 GB di RAM) A prescindere sulle considerazioni riguardo il processo (che sappiate, ha un motivo per occupare così tanta RAM), vorrei capire la fattibilità di una cosa del genere su Linux rispetto anche all'architettura hardware su cui gira. In un'architettura a 32 bit credo che questo NON si possa fare, perchè nonostante il PAE, il processore ha un limite fisico a indirizzare più di 4Gb di memoria (che poi diventano 3.2 Gb per lo split kernel space/user space) Quote:
Dalle mie ricerche, un 64 bit ha la capacità di dare a un processo un quantitativo di ram maggiore di 4 Gb, ma sinceramente sono ricerche fatte su google e quindi poco affidabili. Però chiedo anche a voi, dato che la domanda nasce dalla necessità di acquistare un server abbastanza costoso, con parecchia RAM, da usare proprio per un processo RAM-ivoro di questo tipo. Se scoprissi, ad acquisto effettuato, che i soldi per comprare 16 Gb di RAM sono stati buttati per limiti software, ciò decretebbe severe pene per il sottoscritto ![]() E comunque sia, è una curiosità che ho da tanto tempo, e che spero qualcuno sappia soddisfare definitivamente.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#3 |
Registered User
Iscritto dal: Feb 2005
Messaggi: 1856
|
hai detto bene
con un procio a 64-bit, l'os a 64-bit e l'opzione highmem del kernel le applicazioni possono sguazzare liberamente sulla ram con la sola limitazione dei 64-bit, guarda su wikipedia per vedere quali sono, ma ai giorni doggi penso siano insaziabili. azz ma che cavolo di processo devi usare |
![]() |
![]() |
![]() |
#4 |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Confortante.
E' un processo che necessita di leggere tanti (15 Gb) dati, e ne tiene in memoria una considerevole parte. La sua occupazione di memoria dipende anche dalla size che si dà agli hash che usa, e arriva rapidissimamente a >4Gb se gli hash hanno larghezza >8. Dato che sono hash deputati a contenere circa 80 elementi, la loro size ottimale sarebbe 32 o 64 (come potenze di due) e quindi è facile immaginare come mai mi serve così tanta RAM, per velocizzare il processo che ad oggi se la cava con 3 ore. Un domani lo vorremmo allargare, e per far questo abbiamo bisogno di usare altra RAM. Ecco il perchè della domanda.
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
![]() |
![]() |
![]() |
#5 |
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Più che "ne tiene in memoria" (non è necessario (e neanche sufficiente!) "caricare" tutto un file con read() per "tenerlo in memoria"!) è semmai una questione di comodità, avere tanti indirizzi virtuali per poter indirizzare tutto il file. Con 32 bit puoi comunque "tenere in memoria" tutta quella roba, ma puoi mappare solo una parte del file di volta in volta.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 |
![]() |
![]() |
![]() |
#6 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
In dettaglio stiamo parlando dell'evoluzione temporare di molte (circa 400) tabelle di routing, che devono essere "fuse" ed analizzate, e per le quali basta tenere traccia della best attuale. Per mantenerla in memoria, usiamo hash a 2 livelli (sono necessari per quel che dobbiamo sapere), e nell'ultimo livello c'è una lista. 200.000 elementi nel primo livello x 100 elementi nel secondo x 50 caratteri (char) medi di una lista = 1000 Mb. Considerando che questa è solo la lista massima, direi che rientriamo tranquillamente nelle dimensioni di cui sopra In definitiva, i 2.8 Gb attualmente occupati con una versione dell'algoritmo che ha 2 bucket ad hash (ovvero, gli hash sono praticamente liste) sono più che giustificati, anche dai soli calcoli teorici. Teniamo presente che, in generale, un hash per essere tale, deve mantenere in memoria dei puntatori che sono overhead, in questo caso NON trascurabile, sulla RAM occupata. In generale, abbiamo calcolato 800 Mb di overhead... Non ci possiamo svincolare da queste problematiche dato che la mole di dati da processare è talmente ampia (40 miliardi di righe) che l'algoritmo deve per forza avere complessità lineare. Per permettere di mantenere la complessità lineare, si deve tener traccia dei risultati intermedi delle elaborazioni, e appena si riconosce un "cambio di stato", si scrive sui file di output e si sovrascrivono le vecchie info in memoria. Vorrei evitare di installare una versione a 64 bit del sistema operativo, dato che di problemi ne ho avuti tanti, e questo tra l'altro dovrebbe essere un server su cui gira un servizio che sfrutta i dati calcolati da questo processo. Tu mi confermi che un'architettura a 32 bit, pur con il PAE, non può dare ad un processo più di 4Gb (3.2 considerando lo split) di RAM?
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#7 | ||
Senior Member
Iscritto dal: Apr 2000
Città: Roma
Messaggi: 15625
|
Quote:
Quote:
Se proprio vuoi utilizzare macchine a 32 bit, puoi usare come "ram" un grosso file (open64 + ftrunc64 + unlink) -- può essere un file su fs "normale" (la page cache provvederà a tenerlo in ram a regime; fadvise ti viene in aiuto), o su tmpfs, o - meglio ancora - su hugetlbfs. tmpfs è memoria "anonima", dello stesso identico tipo che otterresti con malloc; hugetlbfs è simile al tmpfs ma utilizza huge pages invece di pagine di 4kb. Un pò più efficiente. In tutti e tre i casi puoi "allocare" ben più di 4 GB. Il problema che devi affrontare è il seguente: deve essere compito tuo mappare (mmap64) di volta in volta, nello spazio di indirizzi del tuo programma, delle "finestre" del file/memoria su cui operare. In soldoni puoi ottenere la "memoria" che ti serve, anche con 32 bit, ma devi usare mmap per accedere a una certa regione -- non puoi "vedere" tutto il blocco in memoria contemporaneamente. Si può fare, ma ha un overhead a causa delle mmap/munmap (dipendente da quante volte devi cambiare "finestra") e varie complicazioni non simpatiche.
__________________
0: or %edi, %ecx; adc %eax, (%edx); popf; je 0b-22; pop %ebx; fadds 0x56(%ecx); lds 0x56(%ebx), %esp; mov %al, %al andeqs pc, r1, #147456; blpl 0xff8dd280; ldrgtb r4, [r6, #-472]; addgt r5, r8, r3, ror #12 Ultima modifica di ilsensine : 05-03-2007 alle 14:49. |
||
![]() |
![]() |
![]() |
#8 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
![]() Mi sembra una cosa abbastanza ardua, più che altro sovradimensionata per lo scopo (semmai la implementassi, sarebbe decisamente più interessante la struttura per gestire la memoria che il programma che la utilizza!) A questo punto, direi che l'uso di un 64 bit è l'unica soluzione, speriamo che non crei problemi negli aggiornamenti (anche se una debian con i servizi base dovrebbe essere affidabile in tal senso) Grazie dell'aiuto ![]()
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#9 | |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
Quote:
io ho una macchina biprocessore opteron con 12Gb e un cluster dove 14 nodi hanno 4 Gb.... mai avuto problemi con i 64 bit (mica ci devo andare su internet e usare i plugin flash!) ovviamente montano tutti gentoo ![]() Ciao
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
|
![]() |
![]() |
![]() |
#10 | |
Senior Member
Iscritto dal: Sep 2001
Città: Roma
Messaggi: 1944
|
Quote:
![]() Se mi dici che il tuo server (il mio sarà uno Xeon biprocessore, quindi stiamo lì) non ha mai avuto problemi con Gentoo + 64 bit, mi inviti a nozze, io sono un gentooista convinto e radicale ![]() Scherzi a parte, essendo server da mettere su per applicazioni di ricerca, la potenza di uno strumento come portage ci sarebbe spesso utile (una cazzata: compilare gnuplot con tutte le opzioni che dico io, invece di usare un precompilato di cui mi devo andare a spulciare la doc per capire che plugin grafici ha), e quindi io sarei molto contento di installare gentoo (anche perchè c'è quel delta di ottimizzazione in più dovuta al compilato che non fa mai male) Suppongo anche che un dual opteron ci metta poco a compilare cose come dbus o iptables, mentre magari impiega un quarto d'ora per gcc e glibc. Sbaglio? Avresti qualche consiglio da darmi sulla compilazione del kernel? Devo stare attento a opzioni particolari, cerco guide sulla rete, oppure procedo come per le macchine desktop? (ovviamente con le dovute variazioni di periferiche e amenità varie)
__________________
"Oggi è una di quelle giornate in cui il sole sorge veramente per umiliarti" Chuck Palahniuk Io c'ero |
|
![]() |
![]() |
![]() |
#11 | |
Senior Member
Iscritto dal: Sep 2003
Città: Bergamo
Messaggi: 1176
|
Quote:
Usa CFLAG non troppo spinte (direi un -O2 max, niente -O3 e -Os) per il resto... In bocca al lupo!
__________________
VGA? No grazie, preferisco le SERIALI! http://daniele.vigano.me | Home server HP Proliant MicroServer (Fedora 64bit) | Notebook Dell Latitude E5450 (Fedora 64bit) | Mobile Moto G3 GEM HPC Cluster Dell PowerEdge R720xd + R720 + R420 + M1000e + M915 (Ubuntu LTS 64bit) up to 1000 cores | EATON UPS |
|
![]() |
![]() |
![]() |
#12 |
Senior Member
Iscritto dal: Dec 2000
Città: Trento
Messaggi: 5917
|
infatti... puoi andare tranquillo... i problemi dei 64 bit si hanno solo in ambito desktop (flash, openoffice, varie applicazioni proprietarie)...
lato server/calcolo i problemi sono pochi... praticamente sulla macchina biprocessore opteron non ho mai avuto nessun problema, ne ho avuto qualcuno sulle macchine del cluster, che sono degli athlon 64 X2 4400 su scheda madre asus con nforce4... ma erano problemi dei primi bios delle schede madri (questo perche' le schede madri per desktop, supportano si i 64 bit, ma in verita' vedono al massimo 4 Gb, e se li hai tutti occupati dalla ram le periferiche pci non "sanno dove ficcarsi" e all'inizio quindi venivano visti solo 3 Gb o c'erano rogne con corruzioni di dati su disco o via rete... ma come gia detto, risolto tutto con aggiornamento del bios e un settaggio nello stesso... e per sicurezza ho passato al kernel iommu=force) Ciao!
__________________
Linux User #272700 >+++++++++[<+++++++++>-]<+.++.>++++[<---->-]<++.+++++++. HOWTO: SSH Firewall e DMZ ɐɹdosoʇʇos oʇuǝs ıɯ |
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 20:47.