Newsgroup: it.comp.lang.c
Titolo: Misura dello Stack...

Vi spiego il contesto :
- Applicazione "server" con codice a 32-Bit (C/C++) x Windows Server
2003/2008 32/64 Bit.
- Utilizzo di MultiThread massiccio su un singolo processo (N.Thread >
2000).
- Uso intensivo di Memoria (3 GBytes di spazio virtuale con
l'attivazione dello switch /3GB).
Il problema odierno dei 32-Bit in contesti di questo tipo è
sicuramente la scalabilità.
Nonostante si abbiano a disposizione macchine con diversi GBytes di
RAM risulta problematico utilizzarli in modo completo ed efficace
senza stravolgere l'applicazione a causa della limitazione dei 32-Bit
sull'utilizzo massimo di 2/3 Gbytes di memoria virtuale per singolo
processo.
Quali soluzioni ?
1) Passare dal MultiThread al MultiProcess, ma il porting
dell'applicazione può non essere semplice e immediato.
2) Passare da 32 a 64 Bit, ma anche in questo caso il porting
dell'applicazione può non essere semplice e immediato.
3) Provare a fare tuning dell'applicazione riducendo la memoria usata,
il numero Thread e soprattutto la quantità di spazio sprecato dello
Stack dei vari Thread.
Essendo orientati nel breve termine sulla soluzione 3 (per poi passare
probabilmente alla soluzione 2) ci stiamo scontrando però con il
problema di dover in qualche modo stimare il valore corretto di Stack
da allocare per i vari Threads (di default il compilatore piazza una
dimensione da 1 MByte che è sovradimensionata per gran parte delle
applicazioni e che noi già abbiamo ridotto a 250 KBytes).
Esiste però qualche strumento in grado di agganciarsi al processo e
misurare la quantità di Stack massima usata dai vari Threads ?
Oppure qualche libreria integrabile nel codice che consenta di
effettuare tali misurazioni ?
O tutto si riduce al *faccio una stima e vado per tentativi* ?
Grazie,
Massimo


1 - Innanzi tutto: non è un problema relativo al c. Il c non sa niente
di threads, stack, 32/64 bits.
2 - A sentire tutto questo sistema titanico mi vengono in mente solo
due situazioni: o è sbagliato il design di tutto il software oppure è
sbagliata la piattaforma (o quantomeno il linguaggio di
programmazione). E' vero che in teoria con una qualsiasi macchina e un
qualsiasi linguaggio si può fare tutto, ma in teoria è anche possibile
scavare in un muro di cemento con un cucchiaino di plastica (tm).
3 - Detto questo, in C su Windows con le API di sistema alla creazione
del thread è possibile specificare la dimensione dello stack, non c'è
bisogno di farlo fare al compilatore - per cui non ho capito bene la
vostra situazione.
4 - Non so cosa sia necessario per voi fare sullo stack, ma in
generale non è un compito *così* difficile. Se proprio è necessario
farlo con un tool direi che un qualsiasi debbugger fa al caso vostro.
Se volete farlo in codice su x86 suppongo che basti prendere la
differenza tra il valore di ESP all'entrata e nella funzione più
innestata.
Ciao!

 vostra situazione.
Tra l'altro potremmo aprire un thread sulla memoria "riservata" e la 
memoria "committed" (non saprei dirlo italiano n.d.p.) dello stack, 
perché magari basta a loro abbassare la memoria riservata lasciando 
invariata la memoria committed. Oppure si potrebbe aprire un altro 
thread sulle funzioni "naked" (nemmeno questo saprei tradurlo in 
italiano); se uno vuole farsi del male e vuole risparmiare qualche byte 
nello stack può farci un pensierino e pasare i tutti parametri 
parametri nei registri, o in aree di memoria condivise, se e quando 
serve.
Ma ha poi senso ciò? Visto che mi sembra che se la sia presa sulle 
perplessità diffusa sull'architettura, io mi limito alla risposta: "si 
può fare quello che chiedi, e questo è ampiamente documentato in MSDN"
Aggiungo poi che i 64 bit non sono la panecea che alcuni pensano. La 
risposta è sempre: dipende. Se la memoria "consumata" dai programmi non 
stanno tutti nella memoria fisica, e c'è un continuo via-e-vai tra 
memoria fisica e page file non è che i 64 bit, *in se*, ti salvino. 
Bisogna poi intendersi sulla parola "scala", magari per loro non è un 
problema.
-- 
mio figlio: 
http://it.youtube.com/davideippopotamo
doppiatori: 
http://it.youtube.com/watch?v=hPGKNWZw0c0&feature=related
Articolo 33 della Costituzione italiana: L'arte e la scienza sono 
libere e libero ne è l'insegnamento.

innestata.
Non è così semplice.
E' un applicazione molto complessa che utilizza anche componenti
esterne. Non è possibile valutare a priori quale sia la funzione più
annidata, altrimenti non sarei venuto qua :-)
Il sistema deve essere fatto "girare" per qualche ora e solo al
termine del test andrebbe valutata qual'è stato l'utilizzo massimo
degli stack.
Massimo

Aggiungo poi che i 64 bit non sono la panecea che alcuni pensano.
Nel nostro caso il problema è solo la memoria per processo
indirizzabile e quindi i 64-Bit *sono* la soluzione definitiva.
Le ottimizzazioni sui Thread sono solo una workaround per il periodo
di transizione.
Memoria fisica sui server ne abbiamo 4-8 GBytes e non abbiamo problemi
ad aumentarla quindi il problema non si pone.
Massimo

 aiutarti".
Veramente io ti ho detto cosa provare. 
Certo, non ti ho scritto *io* lo script dtrace, ne citato l'uso esatto
di getrusage.
-- 
-riko

di getrusage.
Non mi riferivo a te, non sei te che hai risposto in quel modo.
Il tuo intervento era pertinente a andava comunque nella giusta
direzione.
Massimo

 degli stack.
Potresti aggiungere una funzione all'avvio del thread che scrive la 
sequenza di interi 1,2,3,... fino a riempire lo stack (se è troppo 
dispendioso potresti scrivere solo la parte in cui pensi troverai il 
limite massimo). All'uscita dal thread rileggio lo stack e vedi da quale 
punto la sequenza è rimasta intatta.
E.


Ma allora non basta far correre il tutto creando le dimensioni di
stack per thread diverse a runtime, a scendere, e vedere a che punto
si ferma? Se tanto avete migliaia di thread in due/tre corse del test
già avete i dati esatti.

 direzione.
Ok. :)
-- 
-riko

già avete i dati esatti.
Se dovevo fare per tentativi non avevo bisogno di chiedere.
Comunque una soluzione ragionevole per fare la misurazione mi è già
stata data.
Grazie a tutti
Massimo

 Massimo
In bocca al lupo, allora!
Ciao!
P.S. (per chiunque sia o no d'accordo) Perchè più un'applicazione è
grande più si cercano soluzioni difficili?