Newsgroup: it.comp.os.linux.development
Titolo: Memoria e runlevel 3

Ciao a tutti, una domanda [forse] banale:
ho scritto un programmino in C++ minimo (senza nessuna classe) che
lancia 20 pthread ognuno dei quali utilizza std::string e
std::stringstream.
Il mio problema è che quando lo eseguo in una shell dentro il kde mi
occupa 280mb, se invece lo eseguo automaticamente al boot in runlevel 3
mi occupa circa 409mb.
Perchè ?
E' forse qualche direttiva del compilatore ?
E' forse un problema dei pthread ?
Grazie
-R-

 Perchè ?
Come misuri l'occupazione di memoria? Al 90% direi che fai un errore
qui`.
Luca
-- 
Home: 
http://kronoz.cjb.net
Quando un uomo porta dei fiori a sua moglie senza motivo, 
un motivo c'e`.

visualizzo l'occupazione di memoria virtuale usando il comando top ...
-R-

 visualizzo l'occupazione di memoria virtuale usando il comando top ...
Quella e` l'indicazione di quanta parte dell'address space e` allocata
(ma non necessariamente "commited") al processo. Un'indicazione piu`
utile e` quella di Resident Size (RSS). Il problema e` con programmi
multi-threaded alcune versione di top tendono a sommare l'uso di memoria
di tutti i thread, quando in realta` lo spazio di indirizzamento e`
condiviso.
Prova a leggere direttamente /proc/<tgid>/statm, dove tgid (thread group
id) e` in pratica il pid del processo che ha creato i threads; il campo
che ti interessa e` il primo.
Luca
-- 
Home: 
http://kronoz.cjb.net
Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus)

Mi incuriosisce il discorso...
Il diverso comportamento in console testo e in grafica come lo spieghi?
Bye,
Raktzo

Questo e' l'output del top sui due processi (il primo e' quello da
runlevel 3)
VIRT SWAP  RES DATA  CODE
410m 238m 172m 410m 20
289m 117m 172m 289m 20
questi sono i due file che mi hai indicato (il primo e' quello da
runlevel 3)
105102 44100 617 5 0 105097 0
74131 44056 617 5 0 74126 0
cmq non capisco a questo punto *anche* un'altra cosa:
man top:
[...]
q: RES  --  Resident size (kb)
          The non-swapped physical memory a task has used.
           RES = CODE + DATA.
[...]
ma i numeri non mi tornano mica ...
-R-



 visualizzo l'occupazione di memoria virtuale usando il comando top ...
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5988 news      19   4 70320  67m  776 S  2.0  6.7   0:07.00 innfeed
 6403 root      15   0  2052  872  660 R  2.0  0.1   0:00.01 top
    1 root      16   0   680  248  216 S  0.0  0.0   0:01.39 init
                       ^^^^^  ^^^  ^^^
Quale di queste usi?
Ciao,
-- 
Daniele Orlandi

Ho dato una occhiata a tutte le colonne ed in ogni caso non mi spiego
il risultato.
Alla prova pratica il mio problema e' sorto su un daemon che ho
sviluppato per gestire connessioni TCP/IP su una socket.
In fase di sviluppo ho dimensionato la macchina con 1 gb di ram poiche'
in fase di stress test (dentro la shell del kde) ho potuto verificare
che riuscivo a gestire 400/500 connessioni senza problemi.
La sorpresa e' stata quando ho avviato il pinguino in runl 3 ed il
daemon era in swap continuo con circa 300 connessioni.
A questo punto ho iniziato l'analisi del problema ed ho riprodotto il
problema sul codice minimo di cui parlavo nel mio primo post.
Ok per la mem virtuale, quella shared e magari anche quella residente,
ma la memoria dati perche' dovrebbe cambiare ? Alla fine se faccio una
malloc da 10mb non sono *sempre* 10mb ? oppure le librerie std e i
thread posix si comportano in modo diverso quando sono o non sono
dentro X ?
-R-

 dentro X ?
Non dovrebbero... l'unica differenza tra lanciare un'applicazione sotto X e
senza X è la variabile d'ambiente DISPLAY. Prova a lanciare la tua
applicazione sotto X dopo aver tolto DISPLAY e vedere se qualcosa cambia.
Ciao, 
-- 
Daniele Orlandi

Quale linguaggio e distro usi, conosco un altro con problemi simili al tuo
Bye,
Raktzo

Il tutto dovrebbe girare su una Suse 9.1 (direttamente dai CD senza
aggiornamenti)
Linux version 2.6.5-7.104-default (geeko@buildhost) (gcc version 3.3.3
(SuSE Linux))
Il codice e' scritto in C++ con il KDevelop.
-R-