Kolejna ³ata.

[Marcin Dalecki]

Tomasz K³oczko wrote:
> 
> On Tue, 23 Feb 1999, Marcin Dalecki wrote:
> [..]
> > > W porzadku, ksh moze byc szybszy w configure, niech sobie bedzie.
> > > sktypty startowe nie maja tak duzo przetwazania natomiast uruchamiaja sie
> > > nawzajem na prawo i lewo.
> > > Dla mnie wazne jest ze 2 uruchomione bashe zajmuja mniej pamieci niz
> >
> > MYLISZ SIE KOLEGO, ALBO UMY¦LNIE K£AMIESZ. ZERKNIJ:
> >
> >   PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
> >                  0   0   964  964   772 S       0  0.0  2.0   0:00 bash
> >   208 root       0   0   952  952   768 S       0  0.0  2.0   0:00 bash
> >   215 root       0   0   488  488   408 S       0  0.0  1.0   0:00 ksh
> 
> Nigdy do tych liczb nie przywi±zywa³em wielkiej wagi i dlatego nie
> zabardzo wiem co poszczególne liczby tak napradê w powyzszym oznaczaj±.
> Zajrza³em sobie do ps(1) ¿eby siê nieco douczyæ ale te¿ to jako¶ tak nie
> za bardzo do mnie dociera. No dobra czyli z mana:

Sprobuje wiec wyjasnic jak interpretowac powyzsze liczby.

Po pierwsze wszystkie sa wziete ze swiezo odpalonych programow.
To widac w polu TIME. Nie skonsumowalu one jak do tej pory jeszcze nawet
pelnej
sekundy CPU.
Po drugie bylem nawet nieco niefair dla ksh bo moj bash to 1.14.7 a nie
2.02, ktory jest jeszcze wiekszy!

A teraz do poszczegolych pol.

>        SIZE Virtual image size; size of text+data+stack.

Tak jak widzisz to pelna wielosc zajmowanej wirtualnej przestrzeni
adresowej
przez dany program

>        RSS  Resident set size; kilobytes of program in memory.

To ilosc bajtow zajmowanych w faktycznej pamieci przez dany program.

>        SHARE
>             Shared memory.

To ilosc pamieci wspoldzielonej z innymi przez dany program.
W tym wypadku widzimy wiec, ze bash zajmuje tuz po odpaleniu
jakies 970kbajtow a ksh tylko 488.

Gdy programu UNIX-owe pracuja to rezerwuja dodatkowo pamiec ale
*nigdy* (no prawie nigdy) jej nie zwalniaja spowrotem do systemu. 
Wieloksc programow wiec w zasadzie tylko moze rosnac. 
Stad te dziwne sizey u Ciebie. Nie sa one wiec miarodajne co do
faktycznego aktualnego spozycia pamieci. Nalezy tak jak ja to zrobilem
w pierwszej kolejnosci porownywac programy tuz po odpaleniu, aby sie
przekonac, ile wspoldziela i ile danych niewspoldzielych potrzebuja.

Powrocmy wiec do moich danych.

RSS i SHARED basha wynosi raz 964 i 772 lub 952 i 768. Czyli 
niewspoldzieli, no jakies 192/184k bajtow. Tyle mniej wiecej  
bash po odpaleniu potrzebuje pamieci dla samego siebie. I ja 
tu mowie o bash-u 1.14! bash-2.02 potrzebuje jeszcze wiecej miejsca!

Prosze rowniez pamietac ze te 772/768 jest w pewnym stopniu 
wspoldzielone pomiedzy tymi dwoma bash-ami z tego pewie jakies 400k 
odpada na libc. Tak wiec faktyczne spozycie pamieci przez bash-a 
wynosi ca 190 + 770 - 400 - 200= 360 k bajtow. (odjalem 200 
zakladajac ze bash owiele wiecej funkcji a libc wykozystuje.)

Natomiast ksh siedzi 488 bajtami i jest tam w calosci (RSS=SIZE)
bo ja mam dosc pamieci w mojej maszynce. Czyli jego pelna wielkosc
liczac kod i wszystkie przezen zarezerwowane domyslnie dane to TYLKO
POLOWA, powtarzam POLOWA tego co potrzebuje bash.
Z tego wszystkiego wspoldzieli on 408. Poniewaz ni widu ni slychu 
po drugim ksh na tym systemie bylo te 408k bajtow to w wiekszosci
wspoldzielone z biblioteka libc. Sam wiec ksh potrzebuje wlasnej 
niepodzielnej pamieci zaledwie 80k na dane. Sklamalem wiec 
powyzej dla uproszczenia dydaktycznego mowiac o polowie potrzeben 
pamieci. To sie w rzeczywistosci ma jak 80k do 360k bajtow!!!

> i za bardzo nadal nie wiem jak to interpretowaæ .. jak kalkulowaæ ile
> zajmie kolena instacja tej samej binarki.
> Po za tym .. Marcin czy ty maszh jeszcze basha 1.4.x ?
> Bo mi podobny eksperyment pokazuje znacznie wiêksze liczby:
> 
> USER       PID %CPU %MEM  SIZE   RSS TTY STAT START   TIME COMMAND
> kloczek    352  0.0  0.8  2384  1148   1 S    19:41   0:00 -bash
> kloczek   2854  0.0  0.9  2444  1180  p0 S    21:54   0:00 -bash
> kloczek  15018  0.5  0.3  1272   492  p0 S    08:28   0:00 ksh
> 
> Wiem .. niedouczony jestem i dlatego pro¶ba o pomoc w interpretacji
> powy¿szych przyk³adów. No i z czego wynikaæ mog± tak du¿e ró¿nice w
> kolumnach RSS, SIZE (?).

No mam nadzieje ze co nieco wyjasnilem na sniadanie...

I wyjasnia to chyba rowniez moje dosc intensywne reakcje na tych
co to bez namyslu, rozeznania i zielonego pojecia twierdza,
ze dwa bash-e tak piknie sie wspoldziela, ze nie warto startowac 
czegokolwiek innego. W rzeczywistosci: Gowno! To sam jeden bash 
tak pamiec zre, ze trodno mu czymkolwiek innym dorownac w 
kategorii shellow. A dzielic sie ma czym i dzieli sie sporo, 
tylko tyle jeszcze rezerwuje sam dla siebie ze lzy w oczach
staja...
 
> I jeszcze jedno co mi przychodzi na my¶³ to to czy przypadkiem ksh nie
> nadawa³by siê na kandydata na statycznie skompilowanego shella. Bo mi siê
> wydaje ¿e by³oby to dobre ze wzglêdu na jego rozmiary.

Tak owszem.

> Do tego mam jeszcze pytanie odno¶nie u¿ywania samego ksh .. czy da³oby siê
> go jaki¶ skonfigurowaæ/przerobiæ ¿eby historiê poleceñ i same poprzenie
> polecenia mo¿na by³o przegl±daæ i nawigowaæ po nich za pomoc± kursorów ?

Nie jestem pewny ale chyba da sie go tak nawet skofiguraowac.
Jesli nie to lata powinna byc latwa do zrobienia :-).
To jest wlasciwie rowniez u mnie jedynym powodem dlaczego
uzywam bash-a nadal jako shella interakcyjnego i chyba sie tez od
tego wyzwole... dzis wieczorem.

--Marcin