# Xeon EM64T

## .:chrome:.

dopo la discussione sui processori in oggetto mi sono reso conto di avere in gestione due macchine in produzione che montano questi cosi.

mi stavo ponendo il problema dell'aggiornamento. come pensate che sia possibile farlo senza formare la macchina?

----------

## SilverXXX

Senza fermare minimamente? Almeno riavviare  :Very Happy: 

Scherzi a parte, quanto ti potresti permettere di fermo?

----------

## .:chrome:.

come hai detto tu... giusto il reboot, sempre che questo sia possibile.

----------

## SilverXXX

Se hai spazio libero (o un disco libero) fai tutta lì l'installazione, e ti basta cambiare solo kernel e parametri di grub prima di riavviare. E puoi anche mantenere la vecchia installazione-

----------

## xchris

se e' un server in prod io non lo convertirei onestamente.

A fronte di un guadagno (suppongo) esiguo ti imbarchi in una operazione non del tutto banale.

(anche perche' immagino che il downtime debba essere basso)

Poi.. non e' detto che sia tutto cosi' stabile come prima..

Vivi tranquillo a 32 bit.. IMHO

Ciao

----------

## lavish

Concordo con xchris. La c"conversione" non è un'operazione tanto banale, anzi. Il metodo migliore è quello già suggerito di creare il sistema in un'altra partizione. Andare a riutilizzare la stessa installazione non è cosa buona visto che dovresti ricompilare tutto con un kernel a 64bit e avresti problemi a bizzeffe con le librerie.

----------

## makoomba

concordo solo nel caso in cui non si abbia l'accesso fisico alle macchine.

scoprirsi con due 64 bit e continuare ad usarli a 32 ti procurerà fastidio, insonnia e incubi popolati da gechi incazzati perchè non hai ottimizzato.

senza contare l'invidia di chi NON ha le suddette estensioni sui propri xeon (tipo IO): cominceranno ad additarti, sibilando frasi del tipo "dio dà pane a chi non ha denti"

ho detto.

----------

## gutter

 *makoomba wrote:*   

> concordo solo nel caso in cui non si abbia l'accesso fisico alle macchine.
> 
> scoprirsi con due 64 bit e continuare ad usarli a 32 ti procurerà fastidio, insonnia e incubi popolati da gechi
> 
> 

 

Che i gechi si arrabbino pure.   :Wink: 

Un server di produzione deve essere per prima cosa stabile le performance vengono molto ma molto dopo.

----------

## makoomba

non credo che un sistema a 64 bit, se configurato correttamente, debba essere necessariamente meno stabile del suo equivalente a 32bit.

configurare un "mirror" sullo stesso server non è certo un'operazione particolarmente complessa, alcuni servizi potrebbero essere testati dal chroot senza nemmeno interrompere quelli ufficiali.

qui non si parla di CFLAGS più o meno spinte, ma di un cambio radicale di architettura: l'impatto in termini di prestazioni e/o affidabilità sarebbe valutabile solo a posteriori.

----------

## xchris

 *makoomba wrote:*   

>  l'impatto in termini di prestazioni e/o affidabilità sarebbe valutabile solo a posteriori.

 

concordo..

tutto dipende se si ha tempo e voglia di provare questa migrazione.

Tutto poi dipende dai servizi che girano.

Quanto sono "rodati" a 64bit e quanto potrebbero giovarne da un indirizzamento cosi' ampio.

Puo' essere visto tutto solo a posteriori ma IMHO non ci sara' mai un balzo tale da giustificare il cambio.

(soprattutto perche' la stabilità è una caratteristica che si evidenzia nel tempo...)

Ciao

----------

## randomaze

 *makoomba wrote:*   

> non credo che un sistema a 64 bit, se configurato correttamente, debba essere necessariamente meno stabile del suo equivalente a 32bit.

 

Penso che gutter non si riferisse alla stabilità dei programmi in se quaunto ai problemi del passare dall'uno all'altro sistema. Poi qualche differenza tra un architettura e l'altra potrebbe rivelarsi un problema, risolvibile certo, ma sarebbe pur sempre un problema aggiuntivo.

----------

## gutter

 *randomaze wrote:*   

> 
> 
> Penso che gutter non si riferisse alla stabilità dei programmi in se quaunto ai problemi del passare dall'uno all'altro sistema. Poi qualche differenza tra un architettura e l'altra potrebbe rivelarsi un problema, risolvibile certo, ma sarebbe pur sempre un problema aggiuntivo.

 

Il mio illustre collega ha colto nel segno  :Wink: 

Vediamo se riesco a spiegarmi meglio: nel 99% dei casi le performance di un server non sono considerate importanti, per contro un server deve fornire un uptime più alto possibile, dal momento che deve offrire servizi. Quindi da buon sistemista, k.gothmog dovrebbe valutare se questa migrazione può portare risultati tangibili ovvero se può fornire una qualche miglioria che valga il rischio e il tempo speso; (dal momento che in ogni caso creerà un downtime).

Vorrei solo sottolineare che la prima regola che un buon sistemista segue è quella di non toccare ciò che funziona bene.   :Very Happy: 

----------

## makoomba

 *gutter wrote:*   

> Vorrei solo sottolineare che la prima regola che un buon sistemista segue è quella di non toccare ciò che funziona bene. [/i]

 

questo non implica escludere un'alternativa che funzioni meglio.

le problematiche che esponete sono reali, ma lo sono anche le nuove architetture a 64bit; saranno anche giovani, ma non così giovani.

tentare l'eventuale migrazione subito o aspettare ? è soggettivo.

io i miei test li farei.

----------

## xchris

 *makoomba wrote:*   

> 
> 
> tentare l'eventuale migrazione subito o aspettare ? è soggettivo.
> 
> io i miei test li farei.

 

si ma i test li farei su server non vitali.

Vai poi a spiegare a chi di dovere

che il downtime di 20 minuti e' dovuto a test per passare l'architettura a 64 bit che forse da il 5% in + di velocità.

Personalmente... mi uccidono  :Smile: 

Se il server invece e' tuo e sei pronto a pagarne lo scotto...

bhe che i test abbiano inizio!!!  :Very Happy: 

Amo i test..

ma amo di piu' la mia testa  :Wink: 

----------

## makoomba

ovviamente, la proprietà del server era sottintesa.

----------

## xchris

ahem...

la macchina in questione e' in produzione ed e' affidata a k.gothmog

Se parliamo di macchine proprie sono il primo a volere testare  :Smile: 

ciao

----------

## makoomba

 *k.gothmog wrote:*   

> dopo la discussione sui processori in oggetto mi sono reso conto di avere (in gestione)* due macchine in produzione

 

/me che legge in fretta e rimuove * dalla frase ...

allora ciccia, non si cazzeggia con l'altrui proprietà.

----------

## SilverXXX

Beh, se però dosse un server dbms, in cui si ha un 25-30 percento in più di prestazioni.....

----------

## gutter

 *xchris wrote:*   

> 
> 
> Amo i test..
> 
> ma amo di piu' la mia testa 

 

Esattamente   :Laughing:   :Laughing:   :Laughing: 

----------

## .:chrome:.

 *makoomba wrote:*   

> scoprirsi con due 64 bit e continuare ad usarli a 32 ti procurerà fastidio, insonnia e incubi popolati da gechi incazzati perchè non hai ottimizzato

 

secondo me questo discorso è sbagliato. ha già risposto gutter:

 *gutter wrote:*   

> un server di produzione deve essere per prima cosa stabile le performance vengono molto ma molto dopo.

 

e poi non è vero nemmeno che i 64 bit sono più veloci. casomai il contrario: i 64 bit, a parità di architettura dovrebbero essere più lenti. in realtà mi interessavano per altri motivi.

resta da capire se i 64 bit sono effettivamente meno stabili dei 32 bit. su due piedi non ne vedo il motivo, ma non ho mai avuto in mano macchine intel a 64 bit.

mi pare di capire che l'upgrade non è fattibile on-line e decisamente pare che il gioco non valga la candela.

chiedo scusa per l'approccio molto "noob" alla faccenda, ma come ho già detto, non ho mai avuto per le mani macchine x86 a 64 bit  :Smile: 

intanto grazie a tutti per le consulenze  :Wink: 

una piccola curiosità: supponiamo che un domani abbia la possibilità di buttare giù le macchine e rifare tutto. che profilo (/etc/make.profile) si dovrebbe usare su quegli affari?

----------

## lavish

 *k.gothmog wrote:*   

> che profilo (/etc/make.profile) si dovrebbe usare su quegli affari?

 

Dovrebbe essere questo  :Wink: 

/usr/portage/profiles/default-linux/amd64/2005.1

----------

## xchris

i 64 bit possono e non possono essere + veloci dei 32..

dipende dal tipo di applicazione e da che tipi di dati gestisce.

Nel uso di tutti i giorni credo che tu abbia ragione...

motivo per cui non mi avventurerei...

Per quale motivo lo vorresti provare? (pura curiosità)

ciao

----------

## .:chrome:.

 *xchris wrote:*   

> Per quale motivo lo vorresti provare? (pura curiosità)

 

mi interessava la gestione della memoria di quei processori, che è stata riorganizzata rispetto ai 32 bit.

in particolare avevo letto che nella EM64T era stato finalmente implementato in hardware il non-executable bit, che io ho sempre emulato in software.

oltre a questo non ci sono motivi particolari. nulla di eclatante, infatti ho rinunciato  :Smile: 

----------

## FonderiaDigitale

server = disponibilita'. sempre. quindi il server deve stare su. neanche il 40% di guadagno in prestazioni giustificherebbe un downtime. sempre che sia una macchina di esercizio.

server = i/o, ovvero movimento di dati. non troveresti grosso giovamento in questo frangente dal 64bit.

vedi che la risposta vien da se.

----------

## .:chrome:.

 *FonderiaDigitale wrote:*   

> server = disponibilita'. sempre. quindi il server deve stare su. neanche il 40% di guadagno in prestazioni giustificherebbe un downtime. sempre che sia una macchina di esercizio.
> 
> server = i/o, ovvero movimento di dati. non troveresti grosso giovamento in questo frangente dal 64bit.

 

sono esattamente le considerazioni che stavo facendo.

----------

## FonderiaDigitale

ok..

..poi detto inter-nos, dal proliant che ho in ufficio non ho notato grossi incrementi. e la macchina lavora pesantemente su un db mysql.

Probabilmente su un desktop e con un kernel preeemptive sarebbe diverso, ma non e' qusto il caso a quanto mi e' dato di capire.

ciao

----------

## lavish

 *k.gothmog wrote:*   

> in particolare avevo letto che nella EM64T era stato finalmente implementato in hardware il non-executable bit, che io ho sempre emulato in software

 

Infatti, questa è una feature molto interessante

Sul mio sistema (Athlon64), la lista delle flags è la seguente:

 *Quote:*   

> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow

 

In ogni caso, che tu usi un OS a 32bit o a 64bit, potrai comunque sfruttare il supporto hardware al No eXecute

Riporto da wikipedia:

 *Quote:*   

> Linux
> 
> Linux itself supports standard hardware NX, now in 32 bit mode on 64-bit CPUs via Ingo Molnar's NX enabler patch as well as in 64 bit mode on CPUs that support it (these include current 64-bit CPUs of AMD and future CPUs announced by Intel, Transmeta and VIA). Linus Torvalds has taken an interest in the NX patch, and believes it may be wise to have NX enabled by default; thus, it has been merged in 2.6.8. This is significant on 32-bit x86 kernels, which may run on both 32-bit x86 CPUs and 64-bit x86 compatible CPUs. A 32-bit x86 kernel would not normally expect the NX bit that an AMD64 or IA-64 supplies; the NX enabler patch assures that these kernels will attempt to use the NX bit if present.
> 
> As of this patch, Linux fully utilizes the hardware NX bit in supporting CPUs from Intel, AMD, Transmeta and VIA. The NX patch was released to the Linux kernel mailing list in June, 2004.
> ...

 

http://en.wikipedia.org/wiki/NX_bit

----------

## gutter

 *k.gothmog wrote:*   

> 
> 
> sono esattamente le considerazioni che stavo facendo.

 

... e che avevo fatto io qualche post su   :Wink: 

----------

## makoomba

 *k.gothmog wrote:*   

>  *makoomba wrote:*   scoprirsi con due 64 bit e continuare ad usarli a 32 ti procurerà fastidio, insonnia e incubi popolati da gechi incazzati perchè non hai ottimizzato 
> 
> secondo me questo discorso è sbagliato. ha già risposto gutter:
> 
> 

 

secondo me, non hai capito che lì stavo scherzando.

dissento totalmente su discorsi tipo: "su un server le prestazioni non sono importanti".

rinunciare ad ottimizzazioni estreme che poterebbero ledere alla stabilità del sistema non vuol dire rinunciare a qualsiasi ottimizzazione.

qualcuno, per caso, su un server compila per i386 invece che i686 ? o sceglie 386 in processor family ?

in merito ad un possibile confronto 32 vs 64 in ambito server, c'è un articolo interessante su Anandtech in cui è testato mysql.

il succo è che, per un dual xeon, il passaggio ai 64bit si traduce in una differenza di prestazioni che varia tra +19% e -18%

per un dual opteron, lo stesso produce un guadagno tra +24% e +36%.

Il passaggio ai 64bit conviene ? dipende.

se quei test li avessi eseguiti tu con un dual xeon, saresti rimasto con i 32

ma con un dual opteron e un guadagno minimo di +24% che sfiora il 40%, in assenza di problemi di stabilità, cosa avresti fatto ?

----------

## Ic3M4n

 *makoomba wrote:*   

>  in assenza di problemi di stabilità, cosa avresti fatto ?

 

dipende da quanto mi "costa" fare l'aggiornamento sia come downtime che come consumo di risorse per dover ricompilarmi tutto il sistema. calcolando anche che l'architettura a 64bit viene utilizzata pressochè da tutti in ~arch per la difficoltà di reperire sw "datato" che compili correttamente. perciò dovresti anche calcolare di utilizzare sw dichiarato non stabile dalla distribuzione.

l'unico momento in cui potrei seguire il ragionamento e fare la conversione ai 64 bit sarebbe quando avessi la necessità di uno stoccaggio di dati in ram molto alta. fuori dal limite previsto per i 32bit, che mi sembra (ma potrei sbagliare) essere intorno ai 4Gb.

----------

## makoomba

@Ic3M4n

l'architettura a 64bit non è limitata al solo aumento dello spazio di indirizzamento.

con una corretta pianificazione, il downtime può essere minimo, anche nullo.

qualche tempo fa ho migrato tutti i miei servers a gentoo senza che nessuno degli utenti avesse il minimo disservizio.

il motivo ? ho provato gentoo, valutato pro e contro, considerato i costi e concluso che mi conveniva.

per analoghe motivazioni sono passato da qmail a postfix  e dal 2.4 al 2.6

seguirei lo stesso approccio per un'eventuale migrazione a 64bit.

"non ho il tempo", "non ho i mezzi", "i servers non sono di mia proprietà" sono ottime motivazioni per lasciare le cose come stanno.

"squadra che vince non si tocca" e "tanto le prestazioni non contano", no

my 2c.

----------

## .:chrome:.

 *makoomba wrote:*   

> secondo me, non hai capito che lì stavo scherzando.
> 
> dissento totalmente su discorsi tipo: "su un server le prestazioni non sono importanti".
> 
> rinunciare ad ottimizzazioni estreme che poterebbero ledere alla stabilità del sistema non vuol dire rinunciare a qualsiasi ottimizzazione.

 

infatti non avevo capito. chiedo scusa

 *makoomba wrote:*   

> con una corretta pianificazione, il downtime può essere minimo, anche nullo.
> 
> qualche tempo fa ho migrato tutti i miei servers a gentoo senza che nessuno degli utenti avesse il minimo disservizio.

 

ma da quello che sta emergendo pare che in questo caso non sia possibile.

se non ho capito male, è necessario ricompilare librerie di base e kernel a 64 bit, e una volta fatto questo, riavviando, non è dettoc he il resto del sistema funzioni. questo è un rischio che non voglio correre.

----------

## makoomba

@k.gothmog

considerato che i servers non sono i tuoi, non prenderei neanche in considerazione l'ipotesi

altrimenti, come prima cosa proverei a cambiare la processor family del kernel: al primo sintomo di malfunzionamento, reboot e ciao ai 64bit

se non riscontrassi problemi, duplicherei il sistema in un chroot ricompilandolo per i 64bit.

successivamente, farei partire i vari servizi dal chroot, modificando le porte e facendo tutti i test del caso.

così per un pò di tempo, valutando eventuali instabilità e qualità degli aggiornamenti.

----------

## lavish

 *makoomba wrote:*   

> se non riscontrassi problemi, duplicherei il sistema in un chroot ricompilandolo per i 64bit.
> 
> successivamente, farei partire i vari servizi dal chroot, modificando le porte e facendo tutti i test del caso.

 

Once again: per compilare a 64bit serve un kernel a 64bit. Anche se si cambia processor family rimane comunque a 32.

----------

## makoomba

 *lavish wrote:*   

> Once again: per compilare a 64bit serve un kernel a 64bit. Anche se si cambia processor family rimane comunque a 32.

 

c'è un kernel specifico ?

----------

## lavish

 *makoomba wrote:*   

> c'è un kernel specifico ?

 

Non puoi con il sistema a 32bit creare un chroot e compilare un altro sistema a 64bit perchè il kernel in uso sarà quello a 32. Non ci sono kernel specifici.

----------

## makoomba

 *lavish wrote:*   

> per compilare a 64bit serve un kernel a 64bit. Anche se si cambia processor family rimane comunque a 32.

 

come fai ad avere un kernel a 64bit ?

----------

## lavish

 *makoomba wrote:*   

> come fai ad avere un kernel a 64bit ?

 

live cd per esempio

----------

## makoomba

 *lavish wrote:*   

> live cd per esempio

 

.... a questo punto, mi chiedo 3 cose:

1) come hanno compilato il primo livecd per amd64 ?

2) mi stai facendo la "supercazzola" ?

3) considerato che NON ho al momento server a 64bit, perchè mi sono infilato in questo discorso ?

indi per cui, mi defilo da codesto 3d fischiettando con indifferenza.

fiiifuuufiifiiiii....

----------

## lavish

 *makoomba wrote:*   

> 1) come hanno compilato il primo livecd per amd64 ?

 

cross-compilazione  :Wink: 

2) e 3) seguono  :Razz: 

----------

## gutter

Moved from Italian to Off Topic.

----------

