---

Hej alle.

Jeg må indrømme jeg er lidt rusten udi *nix meen..
Jeg har et lille legeprojekt kørende på en lille Linux server.
Jeg skulle lige se hvordan den havde det, og lavede en top.
Den giver denne her:
Mem: 39816K used, 52820K free, 0K shrd, 1040K buff, 24712K cached
Load average: 0.04 0.01 0.00
PID PPID USER STAT VSZ %MEM %CPU COMMAND
23402 1 root S 20036 22% 0% ./Monitor /WOPR/oio.ini -d
22825 1 root S 19944 21% 0% ./Monitor /WOPR/capmon.ini -d
23872 1 root S 19944 21% 0% ./Monitor /WOPR/csis.ini -d
23479 1 root S 20040 22% 0% ./Monitor /WOPR/krak.ini -d
23717 1 root S 19944 21% 0% ./Monitor /WOPR/virus112.ini -d
1095 1 root S 61372 66%
0% ./wopr_service /WOPR/wopr_service.ini
26132 1034 root S 55884 60%
0% ./wopr_webserver /WOPR/wopr_webserver.

For at sige det lige ud, så fatter jeg ikke en skid af at jeg tilsammen
bruger > 200% af memory?

Summary siger ~39 MB ud af de 96MB, der fysisk er i maskinen.
Er der nogen der kan kaste lys over hvad der egentlig står?

Det skal lige nævnes, at der er tale om daemons med NPTL threads, så det er
muligt der er ting der tæller lidt for mange gange eller hur?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Hej alle.
>
> Jeg må indrømme jeg er lidt rusten udi *nix meen..
> Jeg har et lille legeprojekt kørende på en lille Linux server.
> Jeg skulle lige se hvordan den havde det, og lavede en top.
> Den giver denne her:
> Mem: 39816K used, 52820K free, 0K shrd, 1040K buff, 24712K cached
> Load average: 0.04 0.01 0.00
> PID PPID USER STAT VSZ %MEM %CPU COMMAND
> 23402 1 root S 20036 22% 0% ./Monitor /WOPR/oio.ini -d
> 22825 1 root S 19944 21% 0% ./Monitor /WOPR/capmon.ini -d
> 23872 1 root S 19944 21% 0% ./Monitor /WOPR/csis.ini -d
> 23479 1 root S 20040 22% 0% ./Monitor /WOPR/krak.ini -d
> 23717 1 root S 19944 21% 0% ./Monitor /WOPR/virus112.ini -d
> 1095 1 root S 61372 66%
> 0% ./wopr_service /WOPR/wopr_service.ini
> 26132 1034 root S 55884 60%
> 0% ./wopr_webserver /WOPR/wopr_webserver.
>
> For at sige det lige ud, så fatter jeg ikke en skid af at jeg tilsammen
> bruger > 200% af memory?
>
> Summary siger ~39 MB ud af de 96MB, der fysisk er i maskinen.
> Er der nogen der kan kaste lys over hvad der egentlig står?
>
> Det skal lige nævnes, at der er tale om daemons med NPTL threads, så det er
> muligt der er ting der tæller lidt for mange gange eller hur?
>

De benytter shared memory.

---

Jesper Staun Hansen wrote:
> De benytter shared memory.

Tak for svaret, det er jeg nogenlunde med på.

Men jeg skal til at kontrollere om jeg har nogle memoryleaks i mine ting.

Det kan man åbenbart ikke bruge top til, men så kommer følgespørgsmålet:
Findes der noget værktøj til Linux til den slags?

Jeg prøvede lige at starte min tunnel/filter op i en WmWare, og der siger
den:
17254 1 root S 19340 32% 0% ./wopr_service
hvor den anden siger:
1095     1 root     S    61372  66%  0% ./wopr_service

Skal man fortolke det som at jeg har en samlet leak på ~42 MB?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 30-04-2008 1

> Men jeg skal til at kontrollere om jeg har nogle memoryleaks i mine ting.

Er dine ting nogen du selv har lavet?

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 30-04-2008 1
>
>> Men jeg skal til at kontrollere om jeg har nogle memoryleaks i mine ting.
>
> Er dine ting nogen du selv har lavet?

Ja, men har det nogen betydning for mit ?

Jeg har så kigget lidt i dokumentationen for Kylix(pascal), som det er lavet
i, og ser der er noget med reservering af minimum stack space.

Principielt er det ikke noget der bekymrer mig, så længe 'it works as
designed'.

Jeg undrer mig bare over den misvisning der ligger i 'top' - eller manglende
forståelse fra min side.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 01-05-2008 00:18:
> Thorbjørn Ravn Andersen wrote:
>
>> Stig Johansen skrev den 30-04-2008 1
>>
>>> Men jeg skal til at kontrollere om jeg har nogle memoryleaks i mine ting.
>> Er dine ting nogen du selv har lavet?
>
> Ja, men har det nogen betydning for mit ?

Ja. Fordi du bør bruge et decideret modul til at finde den slags, og
ikke forlade dig på operativsystemets overordnede holdning til programmet.

>
> Jeg har så kigget lidt i dokumentationen for Kylix(pascal), som det er lavet
> i, og ser der er noget med reservering af minimum stack space.

Større programmer slæber rundt på alt muligt som kan forstyrre dine top-tal.

> Principielt er det ikke noget der bekymrer mig, så længe 'it works as
> designed'.
>
> Jeg undrer mig bare over den misvisning der ligger i 'top' - eller manglende
> forståelse fra min side.

Måske skulle du se lidt på manualsiden til top for at se deres
forklaring af de enkelte felter.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Ja. Fordi du bør bruge et decideret modul til at finde den slags, og
> ikke forlade dig på operativsystemets overordnede holdning til programmet.

Jeg er ikke 100% med på hvad du siger her.
Betyder det at top ikke kan bruges til noget, og at jeg må finde noget
andet?

Interessen er ikke større end at jeg er ude på at checke om der skulle være
en leak.

Men hvis der ikke rigtig findes noget til Linux, så er det vel bare
kildekodegranskning.

> Større programmer slæber rundt på alt muligt som kan forstyrre dine
> top-tal.

Større programmer i min optik,verden og virke er mere ovre i Mainframe
verdenen, men det hører nok ikke liiige hjemme i den her gruppe.

> Måske skulle du se lidt på manualsiden til top for at se deres
> forklaring af de enkelte felter.

Det har jeg så prøvet, og søgt på Google.

Jeg er kommet lidt frem til:
....
VSZ is the amount of memory the program would take up if it were all in
memory
....

Så det ligner mere en forecast end forbrug.

Det er fint nok til mig, og betyder, at der ikke er nogen is på koen.

Så jeg takker fordi du ledte mig på rette vej.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 01-05-2008 13:46:

> Jeg er ikke 100% med på hvad du siger her.
> Betyder det at top ikke kan bruges til noget, og at jeg må finde noget
> andet?

Top kan bruges til mangt og meget, men spørgsmålet er om det kan bruges
til præcis det du gerne vil lige her.

> Interessen er ikke større end at jeg er ude på at checke om der skulle være
> en leak.

Så brug et værktøj der kan. Jeg kender ikke Kylix godt nok til at kunne
vurdere hvad. Ellers vil jeg anbefale dig at bruge et sprog der
foretager automatisk oprydning efter brug - det er virkelig en
fantastisk lettelse i dagligdagen.


>> Større programmer slæber rundt på alt muligt som kan forstyrre dine
>> top-tal.
>
> Større programmer i min optik,verden og virke er mere ovre i Mainframe
> verdenen, men det hører nok ikke liiige hjemme i den her gruppe.

Pjat, de fleste mainframes kan køre en eller anden variant af Unix i et
eller andet hjørne, så mon ikke den går.


> Så jeg takker fordi du ledte mig på rette vej.

Ingen årsag.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Ellers vil jeg anbefale dig at bruge et sprog der
> foretager automatisk oprydning efter brug - det er virkelig en
> fantastisk lettelse i dagligdagen.

Tænker du på GC baserede ting?

GC og High Performance er nok ikke lige de to ord jeg ville bruge i samme
sætning.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 01-05-2008 22:12:

> Tænker du på GC baserede ting?

"Garbage collection", ja

> GC og High Performance er nok ikke lige de to ord jeg ville bruge i samme
> sætning.

Det kunne du ellers godt. Der sker en hel del på den front, og det kan
ses fx i diverse JVM-implementationer.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 01-05-2008 22:12:
>
>> Tænker du på GC baserede ting?
>
> "Garbage collection", ja
>
>> GC og High Performance er nok ikke lige de to ord jeg ville bruge i samme
>> sætning.
>
> Det kunne du ellers godt. Der sker en hel del på den front, og det kan
> ses fx i diverse JVM-implementationer.

Nu skrev jeg 'ting' fordi jeg lidt usikker på om du hentydede til Java,.NOT
eller Mono eller.

Det er jo nopk et spørgsmål om holdninger og måske religion hvorvidt man
bruger GC eller ej.

Nu har jeg rodet med det her programmering i knap 30 år, og personligt synes
jeg det er en fallierklæring at man ikke kan styre sine egne programmer.

Men det er muligvis mig der er 'sær', lidt ligesom jeg synes også det er
godt at (forsøge at) stave rigtigt.

Der kører p.t. religionskrige ovre i Borland grupperne med .NET eller ej.

Det er korrekt, at i det omfang GC'eren _opnår_ noget idle time inden den
går død, så kan man muligvis opleve en god performance.

Der hvor problemerne opstår med GC'ere er når der _ikke_ er idletime til den
normale oprydning, men bliver tvunget til at gå i gang.

Så går skidtet stort set i stå mens den rydder op.
(Billetnet,Selvangivelse,Apotekernet comes to my mind).

Det kunne være jeg skulle omformulere det til Heavy load i stedet for High
performance.

Rent matematisk logisk findes der ikke en 100% løsning på det problem, så
man må vel bare file på parametre hist og pist.

Kan man i øvrigt konfigurere GC'erne individuelt mht intervaller og
thresholds?


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 02-05-2008 08:17:

> Nu skrev jeg 'ting' fordi jeg lidt usikker på om du hentydede til Java,.NOT
> eller Mono eller.

Det er faktisk mindre vigtigt. Det er en vigtig del af selve sproget -
du kan fx ikkke bare lige skifte et C program over til formålet.

> Nu har jeg rodet med det her programmering i knap 30 år, og personligt synes
> jeg det er en fallierklæring at man ikke kan styre sine egne programmer.

Tjah. Du stoler vel også på at den kode compileren laver, er god nok
til dig.

Og du tager een ting ud i køkkenet af gangen når du rydder op efter
aftensmad?

>
> Men det er muligvis mig der er 'sær', lidt ligesom jeg synes også det er
> godt at (forsøge at) stave rigtigt.
>
> Der kører p.t. religionskrige ovre i Borland grupperne med .NET eller ej.

Hvilke argumenter er der hold i?

> Det er korrekt, at i det omfang GC'eren _opnår_ noget idle time inden den
> går død, så kan man muligvis opleve en god performance.
>
> Der hvor problemerne opstår med GC'ere er når der _ikke_ er idletime til den
> normale oprydning, men bliver tvunget til at gå i gang.
>
> Så går skidtet stort set i stå mens den rydder op.
> (Billetnet,Selvangivelse,Apotekernet comes to my mind).

Det er korrekt - det er ikke så fikst.

Til den slags ting skal opryddetingesten køre hele tiden og parallelt,
så problemet sker sjældent.

Hvis du er interesseret, har Jakob Marner skrevet en opgave kaldet
"Evaluating Java for Game Development" i 2002 (spørg google) som kigger
på at skrive spil i Java. Der er nogen særdeles interessante
observationer i.

Hans konklusion dengang var (baseret på Java 1.4.1):
==
"In contrary to popular belief Java applications are in fact not much
slower than C++ applications when they have been tuned for performance.
A rough estimate based on the various benchmarks would say that tweaked
Java code is a little slower than C++, typically 20-50% on the average,
but this is hard to tell for certain because of the large variations in
the speed seen in the benchmarks. The slowdown is less in 3D
applications where performance mostly depends on the performance of the
3D hardware and not on the programming language used.

For untweaked code Java is much slower than C++, often a factor of
three and four. This makes it vital to tweak the performance critical
sections of Java code.

Java increases the overall productivity of a software project with about
30% and the productivity of the code phase with about 65%. This is
quite a significant increase."
==

Når han siger tweaking betyder det ikke man skal lave stygge ting, men
bare skrive programmerne så de undgår de ting man ved er dyre at lave.
Det er det samme som i alle andre sprog.


> Det kunne være jeg skulle omformulere det til Heavy load i stedet for High
> performance.
>
> Rent matematisk logisk findes der ikke en 100% løsning på det problem, så
> man må vel bare file på parametre hist og pist.

> Kan man i øvrigt konfigurere GC'erne individuelt mht intervaller og
> thresholds?

Uha, jo det kan man godt - det er en bedre videnskab.

Du kan se her hvordan man gjorde i Java 1.4.2.

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

Der bruger man at nye objekter laves i et lille hjørne, som er optimeret
til at håndtere objekter med kort levetid, og kun hvis de overlever et
vist stykke tid, bliver de flyttet ud til de andre langlivede objekter.
Det hjælper også enormt på indsatsen der skal gøres for at skabe plads
til nye objekter.

Du kan se her hvordan IBM reducerede ventetiderne i 1.4.0:

http://www.ibm.com/developerworks/ibm/library/i-incrcomp/

Iøvrigt så er det også en kunst at udnytte flere CPU'er samtidig imens.
Det er virkelig noget som kan gøre en forskel i et produktionsmiljø.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Tjah. Du stoler vel også på at den kode compileren laver, er god nok
> til dig.

Ja, _den_ compiler jeg bruger. Det er en evolution gennem ca 20 år.
Men ikke nødvendigvis en hvilken som helst tilfældig hype of the day
compiler.

> Og du tager een ting ud i køkkenet af gangen når du rydder op efter
> aftensmad?

Nej der tager du grueligt fejl.
Netop den slags ting overlader jeg til organiske garbage collector i huset.

>> Der kører p.t. religionskrige ovre i Borland grupperne med .NET eller ej.
>
> Hvilke argumenter er der hold i?

Det samme som vi er inde på her.

Dem der laver almindelige applikationer synes det er guds gave til folket at
man kan slippe for at skrive 'object.free' hist og pist.

Dem der laver flerdimensionelle matricehåndteringer brækker sig til gængæld
over performance.

Men det har ikke så meget med GC at gøre, mere at det er pcode med dertil
hørende overhead.

>> Så går skidtet stort set i stå mens den rydder op.
>> (Billetnet,Selvangivelse,Apotekernet comes to my mind).
>
> Det er korrekt - det er ikke så fikst.
>
> Til den slags ting skal opryddetingesten køre hele tiden og parallelt,
> så problemet sker sjældent.

Ja, men du kan godt se det paradoksale i det?
Det er præcis når man har behov for high performance at det går galt.

> Hvis du er interesseret,

Ikke voldsomt.

> Java increases the overall productivity of a software project with about
> 30% and the productivity of the code phase with about 65%.

_a_ software project er nok lidt for meget generalisering.

Hvis du har in mente, at vi plejer at sige 'Java er Delphi med c-syntax' vil
det nok for os 3-4 millioner udviklerer være en kraftig reduktion i
productivity.

Og til dem der ikke kender Delphi kan jeg sige at bla. Skype er lavet i
Delphi.


> Når han siger tweaking betyder det ikke man skal lave stygge ting, men
> bare skrive programmerne så de undgår de ting man ved er dyre at lave.

Jeg er ikke ubekendt med twaking.

> Det er det samme som i alle andre sprog.

Og maskiner.
Jeg kommer i tanke om en, søn til ejeren tror jeg det var, der var begyndt
at studere datalogi engang i 80'erne.
Han havde brug for et delay på 1 sekund, men kunne ikke finde du af at bruge
pause intrinsic'en.
Så han lavede et loop på vistnok:
for i := 1 to 1000000 do
a:=a+1;

Prøv lige at spørge hvad der skete med svartiderne for de andre 200
brugere ;)

> Du kan se her hvordan IBM reducerede ventetiderne i 1.4.0:
>
> http://www.ibm.com/developerworks/ibm/library/i-incrcomp/

Hmm..
Pause times of 40 seconds are quite possible for compaction of a 1 GB heap.
Står der virkelig _sekunder_ og ikke _milli_sekunder?

> Iøvrigt så er det også en kunst at udnytte flere CPU'er samtidig imens.
> Det er virkelig noget som kan gøre en forskel i et produktionsmiljø.

Jeg tror ikke jeg er 100% med på hvad du mener her.
produktionsmiljø - som i driftsmiljø
produktionsmiljø - som i ERP systemer i produktionsvirksomheder.

En af mine kunder har - i danmark - 2 mainframes og 27 windows servere.
Det er vel bare at placere det der kører bedst, på det der kører bedst?

Det er ikke særligt smart at placere ting som DW og intranet m.v. på de
operationelle systemer, uanset antallet af CPU'er.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

>> Tjah. Du stoler vel også på at den kode compileren laver, er god nok
>> til dig.
>
> Ja, _den_ compiler jeg bruger. Det er en evolution gennem ca 20 år.
> Men ikke nødvendigvis en hvilken som helst tilfældig hype of the day
> compiler.

Nej. Det er så en smagssag. Personligt er jeg meget glad for at jeg
ikke selv skal holde styr på at rydde alle objekterne op. Det er nok at
skulle lukke databaseforbindelser osv når man er færdig med dem.


>> Og du tager een ting ud i køkkenet af gangen når du rydder op efter
>> aftensmad?
>
> Nej der tager du grueligt fejl.
> Netop den slags ting overlader jeg til organiske garbage collector i huset.

Tænkte det nok. Hæhæ.


> Dem der laver almindelige applikationer synes det er guds gave til folket at
> man kan slippe for at skrive 'object.free' hist og pist.
>
> Dem der laver flerdimensionelle matricehåndteringer brækker sig til gængæld
> over performance.

Tjah. Det skulle vel principielt heller ikke have noget med hinanden at
gøre hvis matriceobjektet er lavet ordentligt.

En ting der måske kan have deres interesse er at moderne virtuelle
maskiner (tænker her Java, da det er det jeg arbejder med), er så
skrappe at de kan inline metodekald ved runtime og foretage optimeringer
ud fra formodninger de kan udlede af konteksten, således at meget af
ulempen ved at skrive den slags objektorienteret forsvinder i praksis.
Det er ganske fascinerende.

Det kræver naturligvis at man afvikler på en platform der følger med.
Der er i fortolkerverdenen en tendens til at i stedet for at man skriver
sin egen fortolker i C at man genererer java byte code[1] og lader en
JVM afvikle det. Nu hvor Java er GPL og kan distribueres med
Linuxdistributionerne er det en nærliggende mulighed.



> Men det har ikke så meget med GC at gøre, mere at det er pcode med dertil
> hørende overhead.
>
>>> Så går skidtet stort set i stå mens den rydder op.
>>> (Billetnet,Selvangivelse,Apotekernet comes to my mind).
>> Det er korrekt - det er ikke så fikst.
>>
>> Til den slags ting skal opryddetingesten køre hele tiden og parallelt,
>> så problemet sker sjældent.
>
> Ja, men du kan godt se det paradoksale i det?
> Det er præcis når man har behov for high performance at det går galt.

Jovist. Det du glemmer er at en masse new/dispose (eller hvad det nu er
det hedder i Delphi/Pascal - er nok 15 år siden jeg sidst har skrevet
sådan et program) OGSÅ tager tid og at der også er problemer i at lave
en effektiv algoritme til at håndtere disse. Desuden kan du ikke flytte
rundt på ting når du har pointere i stedet for referencer.

Om så det summer op til mere eller mindre tid end at samle det sammen i
en opryddedel må man jo måle sig til.

> Hvis du har in mente, at vi plejer at sige 'Java er Delphi med c-syntax' vil
> det nok for os 3-4 millioner udviklerer være en kraftig reduktion i
> productivity.

Bemærk at jeg på ingen måder klandrer Delphi - jeg har været særdeles
glad for Borland Pascal, men droppede det da jeg fandt ud af at jeg ikke
kunne bruge det på andet end PC'ere.

>
> Prøv lige at spørge hvad der skete med svartiderne for de andre 200
> brugere ;)

Tjah, den gav vel ikke ham mere end den tid han var berettiget til. Men
der var ikke meget luft til de andre, nej.

Han lærte vel der at der var forskel på vægtid og cputid :)

>> Du kan se her hvordan IBM reducerede ventetiderne i 1.4.0:
>>
>> http://www.ibm.com/developerworks/ibm/library/i-incrcomp/
>
> Hmm..
> Pause times of 40 seconds are quite possible for compaction of a 1 GB heap.
> Står der virkelig _sekunder_ og ikke _milli_sekunder?

Det kan godt passe. Det er en af de ting man er særdeles opmærksom på
og hvor der løbende sker forbedringer.

Jeg så efter jeg skrev til dig at BEA (var det vist) har noget til
JRockit hvor man er garanteret at der max stoppes X ms førend der
fortsættes. Det tror jeg der er potentiale i.



>> Iøvrigt så er det også en kunst at udnytte flere CPU'er samtidig imens.
>> Det er virkelig noget som kan gøre en forskel i et produktionsmiljø.
>
> Jeg tror ikke jeg er 100% med på hvad du mener her.
> produktionsmiljø - som i driftsmiljø
> produktionsmiljø - som i ERP systemer i produktionsvirksomheder.

Drift. Det er bare en uvane fra dagligdagen.

Fordelen skulle jo gerne komme i det øjeblik hvor der er MANGE cpu'er
til at tage fra, og hvor det ikke duer at verden stopper og EEN cpu
pakker sammen. (Kan Delphi iøvrigt køre multitrådet?)




> En af mine kunder har - i danmark - 2 mainframes og 27 windows servere.
> Det er vel bare at placere det der kører bedst, på det der kører bedst?
>
> Det er ikke særligt smart at placere ting som DW og intranet m.v. på de
> operationelle systemer, uanset antallet af CPU'er.


Kender vist ikke DW.

Men jo, det kræver naturligvis at ting er desgnet så man HAR et valg.

I min verden er der dog ingen tvivl. Java er perfekt til at lave
serverting - om så JVM'erne skalerer ordentligt endnu, er en andne historie.


[1] Microsoft har med aftalen med Novell i praksis - efter min mening -
aflivet interessen for at bruge Mono som platform for Open Source
projekter.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Nej. Det er så en smagssag.

Præcis, eller måske i virkeligheden en religionssag.

(NB: reordered a little below)

> Personligt er jeg meget glad for at jeg
> ikke selv skal holde styr på at rydde alle objekterne op.
>>> Og du tager een ting ud i køkkenet af gangen når du rydder op efter
>>> aftensmad?
>>
>> Nej der tager du grueligt fejl.
>> Netop den slags ting overlader jeg til organiske garbage collector i
>> huset.
>
> Tænkte det nok. Hæhæ.

Personligt er jeg også glad for jeg ikke skal rydde de der objekter op fra
spisebordet :)

>> Ja, men du kan godt se det paradoksale i det?
>> Det er præcis når man har behov for high performance at det går galt.
>
> Jovist. Det du glemmer er at en masse new/dispose (eller hvad det nu er
> det hedder i Delphi/Pascal - er nok 15 år siden jeg sidst har skrevet
> sådan et program) OGSÅ tager tid

Vi er på ingen måde uenige om, at de ting der tager tid, tager den tid ting
tager.

Mht. GC er det et spørgsmål om _hvornår_ man bruger tiden.
Jeg er ikke ude på at anfægte GC'ere og deres eksistensberettigelse, men det
er bare ikke løsningen på alt.

> Bemærk at jeg på ingen måder klandrer Delphi - jeg har været særdeles
> glad for Borland Pascal, men droppede det da jeg fandt ud af at jeg ikke
> kunne bruge det på andet end PC'ere.

HP3000 - MPE/iX, IBM System 88 mfl. comes to my mind.

>> Prøv lige at spørge hvad der skete med svartiderne for de andre 200
>> brugere ;)
>
> Tjah, den gav vel ikke ham mere end den tid han var berettiget til. Men
> der var ikke meget luft til de andre, nej.
>
> Han lærte vel der at der var forskel på vægtid og cputid :)

Han fik da bøllebank da brugerne ringede til den ansvarlige (guess who).
Jeg var så dum at oprette ham i C-queue'n på linie med de almindelige
brugere.

Og her træder jeg måske på *nix folket, men MPE/iX havde en _noget_ mere
sofistikeret og grannuleret kø struktur end *nix.

> Fordelen skulle jo gerne komme i det øjeblik hvor der er MANGE cpu'er
> til at tage fra, og hvor det ikke duer at verden stopper og EEN cpu
> pakker sammen. (Kan Delphi iøvrigt køre multitrådet?)

Jeg tror vi drifter lidt væk fra mit oprindelige spørgsmål.

Jeg skrev oprindeligt:
> Det skal lige nævnes, at der er tale om daemons med NPTL threads

NPTL er netop svinsk hurtige tråde med et minimalt forbrug.

Jeg er lidt i gang med noget, lad os kalde det R&D, på Grøn IT.

Til det brug har jeg flækket en Linux server sammen af en PC, jeg egentlig
bare ikke har fået smidt ud.
Pentium II - tror jeg det er 200MHz.

Indledende performace forsøg med:
Monitor --> tunnel/filter --> webserver
viser at med en burst på 10 samtidige requests for hver 100 millisekunder
ligger vi på 10-20 millisekunder i svartid.

Men mit problem nu er at jeg løber tør for sockets med den sk*de TIME_WAIT
efter de ca. 64000 er brugt.
Det er jo fint nok, at man i fortiden - måske - skulle vente 30 sekunder på
outstanding packets efter en close, meen.. - vi skriver vel 2008?

> Kender vist ikke DW.

Sorry, forkortelser..
DW = Data Warehouse.

> Men jo, det kræver naturligvis at ting er desgnet så man HAR et valg.

Præcis, og i forbindelse med Data Warehouse er konceptet, at 'upper
management' selv kan definere udtræk, rapporter, decision cubes osv.

Og netop ved at lægge den slags på selvstændige servere, kan de selv sidde
og slåsser om hvem der genererer svartide for hvem

> I min verden er der dog ingen tvivl. Java er perfekt til at lave
> serverting - om så JVM'erne skalerer ordentligt endnu, er en andne
> historie.

Jeg er med på du er Java mand, men _COBOL_ rules ;)

> [1] Microsoft har med aftalen med Novell i praksis - efter min mening -
> aflivet interessen for at bruge Mono som platform for Open Source
> projekter.

Jeg ved ikke hvad der er sket i Williams bardom, men noget må være gået
grueligt galt, siden han har det ønske om at være 'Ruler of the world'.

Jeg ved ikke om aftalen med Novell ændrer noget, men jeg kiggede/skimmede på
et tidspunkt på 'hans' ROTOR projekt.

Så vidt jeg lige kunne se, er det udelukkende et spil for galleriet, alene
med det formål at (forsøge at) lave lock-in og/eller sætte kæp i hjulet for
projekter som Mono.

Nå - men jeg må videre med at finde en løsning på TIME_WAIT 'problemet'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 02-05-2008 20:39:

> Vi er på ingen måde uenige om, at de ting der tager tid, tager den tid ting
> tager.
>
> Mht. GC er det et spørgsmål om _hvornår_ man bruger tiden.

Samt om det kan betale sig at gå færre gange i stedet for en ting af gangen.

>> Bemærk at jeg på ingen måder klandrer Delphi - jeg har været særdeles
>> glad for Borland Pascal, men droppede det da jeg fandt ud af at jeg ikke
>> kunne bruge det på andet end PC'ere.
>
> HP3000 - MPE/iX, IBM System 88 mfl. comes to my mind.

Der kan du bruge Borland Pascal, eller hva'?

> Og her træder jeg måske på *nix folket, men MPE/iX havde en _noget_ mere
> sofistikeret og grannuleret kø struktur end *nix.

Afhænger svjv af hvilken Unixvariant du kigger på. Solaris skulle fx
have nogen ret effektive opdelingszoner.

> Indledende performace forsøg med:
> Monitor --> tunnel/filter --> webserver
> viser at med en burst på 10 samtidige requests for hver 100 millisekunder
> ligger vi på 10-20 millisekunder i svartid.
>
> Men mit problem nu er at jeg løber tør for sockets med den sk*de TIME_WAIT
> efter de ca. 64000 er brugt.
> Det er jo fint nok, at man i fortiden - måske - skulle vente 30 sekunder på
> outstanding packets efter en close, meen.. - vi skriver vel 2008

Æh, ovenstående giver ikke rigtigt mening. Ønsker du at lytte på 64000
porte? Eller snakker vi kølængde på en port?


>> I min verden er der dog ingen tvivl. Java er perfekt til at lave
>> serverting - om så JVM'erne skalerer ordentligt endnu, er en andne
>> historie.
>
> Jeg er med på du er Java mand, men _COBOL_ rules ;)

Tænk dig, jeg er i en biks hvor alle kollegerne er enige med dig. OPM
Cobol endda.

> Så vidt jeg lige kunne se, er det udelukkende et spil for galleriet, alene
> med det formål at (forsøge at) lave lock-in og/eller sætte kæp i hjulet for
> projekter som Mono.

Det kan også være rigeligt til at skræmme folk væk. Der skal ikke meget
til før et projekt lugter af problemer og så har det rygtet, og så skal
der dæleme løftes før det ændrer sig.


> Nå - men jeg må videre med at finde en løsning på TIME_WAIT 'problemet'.

Tjah, fra Javas Socket-klasse dokumentation:

" When a TCP connection is closed the connection may remain in a timeout
state for a period of time after the connection is closed (typically
known as the TIME_WAIT state or 2MSL wait state). For applications using
a well known socket address or port it may not be possible to bind a
socket to the required SocketAddress if there is a connection in the
timeout state involving the socket address or port.

Enabling SO_REUSEADDR prior to binding the socket using
bind(SocketAddress) allows the socket to be bound even though a previous
connection is in a timeout state.

When a Socket is created the initial setting of SO_REUSEADDR is disabled."

Måske kan det hjælpe dig videre?

Sockets kan let være sort magi.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 02-05-2008 20:39:
>> HP3000 - MPE/iX, IBM System 88 mfl. comes to my mind.
>
> Der kan du bruge Borland Pascal, eller hva'?

Det var vist en smutter. Pascal har jeg brugt på dem, ikke _Borland_ Pascal.

> Æh, ovenstående giver ikke rigtigt mening. Ønsker du at lytte på 64000
> porte? Eller snakker vi kølængde på en port?

Det kan jeg godt se.
Det er ikke altid der står det samme som det der foregår oppe i hovedet.

Men jeg prøver længere nede.

>> Så vidt jeg lige kunne se, er det udelukkende et spil for galleriet,
>> alene med det formål at (forsøge at) lave lock-in og/eller sætte kæp i
>> hjulet for projekter som Mono.
>
> Det kan også være rigeligt til at skræmme folk væk. Der skal ikke meget
> til før et projekt lugter af problemer og så har det rygtet, og så skal
> der dæleme løftes før det ændrer sig.

Jeg ved ikke om jeg husker rigtigt. Men ROTOR er 'tilsyneladende' en freeBSD
port fra M$ for at vise at .NET også virker der.
Men i licensen står der at man ikke må bruge noget som helst kode aht.
patenter eller lignende.
På den måde har han sørget for at udelukke brug af dele af kode.

Jeg er dog ikke interesseret, og kan ikke huske hvor eller hvornår jeg faldt
over det.
Det kan være alt mellem 1 og 5 år siden.

>> Nå - men jeg må videre med at finde en løsning på TIME_WAIT 'problemet'.
>
> Tjah, fra Javas Socket-klasse dokumentation:
>
> " When a TCP connection is closed the connection may remain in a timeout
> state for a period of time after the connection is closed (typically
> known as the TIME_WAIT state or 2MSL wait state).

Det er den der jeg løber ind i.
Den webserver jeg har lavet er muligvis 'the fastest ever man made'.
Problemet er, at når en request er færdig forbliver den socket i TIME_WAIT
state for længe (synes jeg).

Det med at 'vi skriver 2008' er bare lidt brok fra min side.
Dokumentationen af TIME_WAIT siger at det er for at den skal have tid til at
tømme interne buffere, outstanding packets m.v.
I dagens danmark burde der ikke være behov for den lange tid. Det virker som
om det er en reminisens fra 1200 baud tiden.

Sammenholdt med jeg har et tunnel/filter ind imellem, bruger jeg reelt 3
sockets pr. request.

De ca. 64000 var fordi jeg ikke tog regnestokken frem.
Jeg har sat den op til at måtte bruge fra port 1024 til 65535 deraf tallet.
Det der så sker - og jeg må hellere bemærke, at det nok er mere akademisk
interesse end et reelt behov - er at når jeg belaster den bette satan med
eksempelvis 10 samtidige requests for hvert 100 millisekunder, eller man
kan også betragte det som 100 requests pr. sekund.
Så efter et stykke tid stiger svartiden (naturligt nok) fra de normale 6-15
ms til både 3 og 9 sekunder.

Den går ikke ned, men venter netop på nye ledige sockets.

> Enabling SO_REUSEADDR prior to binding the socket using

Den er jeg meget sikker på jeg har med, men jeg må hellere tjekke om den
skulle være smuttet ud under en 'oprydning'.

> Måske kan det hjælpe dig videre?

Jeg skal i hvert fald have tjekket om SO_REUSEADDR er smuttet ud.

I virkeligheden var jeg ude efter at på konfigureret TIME_WAIT ned, men jeg
tror ikke det er en god ide at pille på det niveau.

Der er trods alt tale om ekstremer, der højst sandsynligt aldrig vil
forekomme i det virkelige liv.

> Sockets kan let være sort magi.

I know, been there - done that since '95.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 03-05-2008 06:40:

>>> HP3000 - MPE/iX, IBM System 88 mfl. comes to my mind.
>> Der kan du bruge Borland Pascal, eller hva'?
>
> Det var vist en smutter. Pascal har jeg brugt på dem, ikke _Borland_ Pascal.

Uf. Standard Pascal er der ikke meget sjov ved.


>>> Så vidt jeg lige kunne se, er det udelukkende et spil for galleriet,
>>> alene med det formål at (forsøge at) lave lock-in og/eller sætte kæp i
>>> hjulet for projekter som Mono.
>> Det kan også være rigeligt til at skræmme folk væk. Der skal ikke meget
>> til før et projekt lugter af problemer og så har det rygtet, og så skal
>> der dæleme løftes før det ændrer sig.
>
> Jeg ved ikke om jeg husker rigtigt. Men ROTOR er 'tilsyneladende' en freeBSD
> port fra M$ for at vise at .NET også virker der.
> Men i licensen står der at man ikke må bruge noget som helst kode aht.
> patenter eller lignende.
> På den måde har han sørget for at udelukke brug af dele af kode.

Skønt. Komplet ubrugeligt :)

> Det er den der jeg løber ind i.
> Den webserver jeg har lavet er muligvis 'the fastest ever man made'.

Det måler vi på når den virker ;)


> De ca. 64000 var fordi jeg ikke tog regnestokken frem.
> Jeg har sat den op til at måtte bruge fra port 1024 til 65535 deraf tallet.
> Det der så sker - og jeg må hellere bemærke, at det nok er mere akademisk
> interesse end et reelt behov - er at når jeg belaster den bette satan med
> eksempelvis 10 samtidige requests for hvert 100 millisekunder, eller man
> kan også betragte det som 100 requests pr. sekund.
> Så efter et stykke tid stiger svartiden (naturligt nok) fra de normale 6-15
> ms til både 3 og 9 sekunder.

Det forstår jeg stadig ikke. Man plejer normalt at sætte sig på EN port
og så bare tage fra når de kommer.

> I virkeligheden var jeg ude efter at på konfigureret TIME_WAIT ned, men jeg
> tror ikke det er en god ide at pille på det niveau.

Lad du være med det. Bare sørg for at den tager fra hurtigt nok. Du
kan evt kigge på hvordan Acmes thttpd gør ("In typical use it's about as
fast as the best full-featured servers (Apache, NCSA, Netscape). Under
extreme load it's much faster."). Han har også et par andre der kan
være værd at kigge på.

http://www.acme.com/software/thttpd/

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Det måler vi på når den virker ;)

He - det kan jo være den gamle har nogle høkertricks ;)

Det er ikke noget jeg lige har siddet og flækket sammen.
Det er en (ikke kontinuert) videreudvikling siden 1. generation fra 1998.

> Det forstår jeg stadig ikke. Man plejer normalt at sætte sig på EN port
> og så bare tage fra når de kommer.

Ja - ok.
Man sætter en listener socket op på EN port (eks.80).
Denne socket 'accepter' så incoming requests.
For hver request bliver der dannet en ny socket til denne requests.
Dvs. hvis du har 100 samtidige forbindelser, har du 100 bagvedliggende
sockets i brug.
Det er disse 100 sockets der står i time-wait i 120 sekunder.

På samme måde med min tunnel/filter.
Der er EN listener, der modtager requests.
Hver request får en bagvedliggende socket, OG forbinder til webserveren med
en ny client socket.
Så for hvis der er 100 samtidige requests har jeg her 200 sockets i brug.
(201 hvis man medtager listeneren)

> Lad du være med det. Bare sørg for at den tager fra hurtigt nok.

Det er det paradoksale i det.
Hvis den ikke var så hurtig som den er, ville jeg ikke have et 'problem' med
sockets.

> Han har også et par andre der kan
> være værd at kigge på.
>
> http://www.acme.com/software/thttpd/

Takker, men det her går ikke ud på at lave 'yet another webserver'.

Der er nogle 'ting' jeg ikke implementerer, og nogle 'ting', hvor jeg vender
nogle tankegange på hovedet + nogle andre 'ting' der skal implementeres.

Jeg ved godt den sætning er kryptisk, men mere vil jeg ikke sige/afsløre
p.t.


--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 04-05-2008 03:52:

>> Det måler vi på når den virker ;)
>
> He - det kan jo være den gamle har nogle høkertricks ;)

Man ved aldrig. Der er bare ingen garanti for at tricksene skalerer.

> Det er disse 100 sockets der står i time-wait i 120 sekunder.

Hvis det er din frontend der ikke lukker ordentligt, så overvej dog at
rette DEN.

> På samme måde med min tunnel/filter.
> Der er EN listener, der modtager requests.
> Hver request får en bagvedliggende socket, OG forbinder til webserveren med
> en ny client socket.
> Så for hvis der er 100 samtidige requests har jeg her 200 sockets i brug.
> (201 hvis man medtager listeneren)

Jeg er bange for at du er nødt til at være mere konkret førend jeg
forstår hvad det er du laver.


>> Han har også et par andre der kan
>> være værd at kigge på.
>>
>> http://www.acme.com/software/thttpd/
>
> Takker, men det her går ikke ud på at lave 'yet another webserver'.

Det var ikke det der var pointen. Det kunne være du skulle se hvordan
andre gør i programmer der bruger mange socket-forbindelser. Tit er det
"gør sådan", så gør man sådan, og så forsvinder problemet.

> Der er nogle 'ting' jeg ikke implementerer, og nogle 'ting', hvor jeg vender
> nogle tankegange på hovedet + nogle andre 'ting' der skal implementeres.

Altid spændende at høre om andres hobbysysler, men jeg forstår ikke helt
hvorfor det er hemmeligt? Du VIL opfinde alting selv? Du vil sælge det
for en milliard engang?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 04-05-2008 03:52:
>
>> He - det kan jo være den gamle har nogle høkertricks ;)
>
> Man ved aldrig. Der er bare ingen garanti for at tricksene skalerer.

Garanti - næh, Emperi - ja.
Nu kørte det sådan set produktion i Post Danmark i 4 år, så de hwærst' fejl
skulle nok være fundet.

>> Takker, men det her går ikke ud på at lave 'yet another webserver'.
>
> Det var ikke det der var pointen. Det kunne være du skulle se hvordan
> andre gør i programmer der bruger mange socket-forbindelser.

Ja, men på det tidspunkt havde vi det op at køre på en Scumpack 166 MHz med
192MB Ram incl. MS SQLServer 6.5 m.m.

> Altid spændende at høre om andres hobbysysler,

Det er ikke 100% hobby.

> men jeg forstår ikke helt hvorfor det er hemmeligt?

Det er sådan set ikke hemmeligt.

Det går ud på, at jeg har en Monitor.
Monitoren, og det ligger næsten i navnet, er beregnet til at
Monitorere/overvåge 'de andre' og opsamle måleresultater.
I sagens natur, og hvis man skal kunne stole på resultaterne, skal den være
100% fejlfri og klippe stabil (Derfor Linux).

Ud over at monitorere availability ( low frequency ) er den også i stand til
af fyre - ret voldsomme - bursts af sted.
Det er beregnet til svartidsmålinger og eller adfærd på serveren.
For at være effektiv, skal den være hurtigere en serveren.

Webserveren, som vi har snakket om, er ikke performancekritisk, den er
beregnet til en ad hoc oversigt af data fra Monitoren.

Det der er en forskel fra andre, er at både SVG generering og SQLite er
'wired into the core'.

> Du VIL opfinde alting selv?

Næh - "Udsæt aldrig til i morgen hvad du kan stjæle på nettet i dag" ;)

Men de her ting synes jeg ikke rigtig jeg kan finde noget om på nettet.

> Du vil sælge det for en milliard engang?

Jeg har ingen ambitioner om eller forhåbninger om at blive milliardær.
Det overlader jeg trygt til mr. William H Gates Jr. III

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 04-05-2008 21:07:

>>> He - det kan jo være den gamle har nogle høkertricks ;)
>> Man ved aldrig. Der er bare ingen garanti for at tricksene skalerer.
>
> Garanti - næh, Emperi - ja.
> Nu kørte det sådan set produktion i Post Danmark i 4 år, så de hwærst' fejl
> skulle nok være fundet.

Tjah, de plejer da at være ret obs på post til tiden så det må man da håbe.

>>> Takker, men det her går ikke ud på at lave 'yet another webserver'.
>> Det var ikke det der var pointen. Det kunne være du skulle se hvordan
>> andre gør i programmer der bruger mange socket-forbindelser.
>
> Ja, men på det tidspunkt havde vi det op at køre på en Scumpack 166 MHz med
> 192MB Ram incl. MS SQLServer 6.5 m.m.

Ikke dårligt. Hvorfor er der så problemer?

>> Altid spændende at høre om andres hobbysysler,
>
> Det er ikke 100% hobby.

Nej det kan jeg forstå. R&D.

>> men jeg forstår ikke helt hvorfor det er hemmeligt?
>
> Det er sådan set ikke hemmeligt.
>
> Det går ud på, at jeg har en Monitor.
> Monitoren, og det ligger næsten i navnet, er beregnet til at
> Monitorere/overvåge 'de andre' og opsamle måleresultater.
> I sagens natur, og hvis man skal kunne stole på resultaterne, skal den være
> 100% fejlfri og klippe stabil (Derfor Linux).

Ok. Så det er noget "virker alting og har det det godt"-software?

>
> Ud over at monitorere availability ( low frequency ) er den også i stand til
> af fyre - ret voldsomme - bursts af sted.
> Det er beregnet til svartidsmålinger og eller adfærd på serveren.
> For at være effektiv, skal den være hurtigere en serveren.
>
> Webserveren, som vi har snakket om, er ikke performancekritisk, den er
> beregnet til en ad hoc oversigt af data fra Monitoren.

Ok. Det er jo fredeligt nok. Der kan du jo bare embedde thttpd eller
lave statusbeskedfiler hvert minut.

> Det der er en forskel fra andre, er at både SVG generering og SQLite er
> 'wired into the core'.

Det første er ikke almindeligt endnu, det er det sidste nu såmænd,
ihvertfald i Java-verdenen. Sun er begyndt at lægge en ved deres
udviklerudgave.


>
>> Du VIL opfinde alting selv?
>
> Næh - "Udsæt aldrig til i morgen hvad du kan stjæle på nettet i dag" ;)
>
> Men de her ting synes jeg ikke rigtig jeg kan finde noget om på nettet.

Jeg tror bare det er fordi du ikke gør det rigtigt :)

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 04-05-2008 21:07:
>> Ja, men på det tidspunkt havde vi det op at køre på en Scumpack 166 MHz
>> med 192MB Ram incl. MS SQLServer 6.5 m.m.
>
> Ikke dårligt. Hvorfor er der så problemer?

Windows only.
MS SQLServer, eller rettere Sybase 'han' havde købt, kørte rigtig godt og
stabilt.
Jeg er ikke sikker på det samme gør sig gældende efter 'han' selv begyndte
at pille/'udvikle'
Derudover licenser, opgradringskrav , nye licenser osv..

>>> Altid spændende at høre om andres hobbysysler,
>>
>> Det er ikke 100% hobby.
>
> Nej det kan jeg forstå. R&D.

Både ja og nej.
Alle delkomponenterne har jeg, og de har kørt upåklageligt hos forskellige
kunder, både som Windows services og Linux daemons.

R&D aspektet ligger i at jeg lægger det over på NPTL threads i stedet for
traditionelle threads.

I mine 'gamle' versioner kørte jeg med thread pools, men den
model/implementering bruger signal handling mellem de forskellige tråde.

Det du'r ikke med NPTL, så step 1 var at fjerne mine thread pools.

Step 2, og det er dér jeg er nu, er så at se om der overhovedet er behov for
threadpools igen.
Der går rygter om, at man kan spawne 200.000 NPTL threads/sekund, så der
burde ikke længere være behove for threadpooling.

Indledende undersøgelser tyder på at det slet ikke er nødvendigt. Endvidere
synes jeg, at jeg observere at omkostningerne ved at bruge mutexes er
større en besparelsen ved threadpooling.

Flaskehalsen ser derimod ud til nu at ligge i sockets.

Jeg skal lige prøve at regne - tænke.
Vi har en time_wait på 120.000 millisekunder.
Hvis jeg har 30.000 sockets til rådighed, kan jeg max/gns bruge en for hver
4. millisekund.
Da tingene ligge på samme maskine bruger jeg 3 pr. request, så det bliver
til max 1 req. pr. 12 ms.
(Jeg skriver det her for selv at prøve at få overblikket)

Det må betyde, at alene sockets sætter en begrænsning på 88 requests /
sekund.

Vi snakker kontinuert, ikke et engangs burst.

Det jeg var lidt ude efter med time-wait var, at _hvis_ man kunne justere
den ned, så kunne man dermed få flere requests af sted pr. sekund.

Men det tyder på, at de 120 sekunder er en god gammel definition, - written
in the bible -, så der holder jeg nallerne væk.

Så afslutningen på vores socket snak er: 'Sådan er det bare - lær at leve
med begrænsningerne'.

> Ok. Så det er noget "virker alting og har det det godt"-software?

Jeg går ud fra det er en slåfejl (alting=altid).

Ja, det er nærmest en besættelse for mig at levere fejlfri software.

>> Webserveren, som vi har snakket om, er ikke performancekritisk, den er
>> beregnet til en ad hoc oversigt af data fra Monitoren.
>
> Ok. Det er jo fredeligt nok. Der kan du jo bare embedde thttpd eller
> lave statusbeskedfiler hvert minut.

Der er tale om dynamisk genereret SVG ud fra nogle parametre.
Hvis du er nysgerrig, må du godt kigge/prøve her:
<http://wopr.lir.dk/wopr.tools/monitor/monitor.statistics.html>
Men - det kører på min private ADSL linie, så du må helst ikke 'rykke for
hårdt'

Jeg er lidt ideforladt mht. indtastningsparametrene, så det er bare en Q&D
side uden nogen som helst form for validering.

Men som database kan du bruge /WOPR/db/wopr.oio.db og uriid = 1

Til og fra interveller er datoer angivet som dage.fragment, dvs. en time er
roughly 0.042


> Jeg tror bare det er fordi du ikke gør det rigtigt :)

Hmm.. ;)

--
Med venlig hilsen
Stig Johansen

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 03-05-2008 06:40:
>> Den webserver jeg har lavet er muligvis 'the fastest ever man made'.
>
> Det måler vi på når den virker ;)
>
> Lad du være med det. Bare sørg for at den tager fra hurtigt nok. Du
> kan evt kigge på hvordan Acmes thttpd gør.

Man kunne ikke rigtig dy sig.
Jeg lavede et setup hvor jeg målte performance på thttpd samt min 'wopr'.

Setup'et er som følger:
En WmWare med denne distribution:
<http://www.minimalinux.org/ttylinux/>
thttpd herfra:
<http://www.minimalinux.org/ttylinux/addons.html>

Begge monitoreringer er lavet med at hente en flad fil på ca. 5.5 KB.

Monitoren er sat op til at fyre bursts på 10 samtidige requests pr. 100
millisekunder, eller omregnet avg. 100 requests pr. sekund.

Den kører i samme WmWare.

Så samme forudsætninger, samme maskine, samme fil.
Udtræk af performancedata i csv format kan ses her:
<http://w-o-p-r.dk/wopr.tools/monitor/wopru.test.thttpd.txt>
<http://w-o-p-r.dk/wopr.tools/monitor/wopru.test.self.txt>

Jeg har ikke analyseret dataene, men bemærker, at thttpd har det lidt svært
med lidt hård belastning.

Kig under feltet 'NumberOfThreads', som er outstanding threads.

Det skal nok ind i et regneark eller lignende, da Monitoren aht.
performance/memory logger med en LIFO queue.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Men jeg skal til at kontrollere om jeg har nogle memoryleaks i mine ting.
>
> Det kan man åbenbart ikke bruge top til, men så kommer følgespørgsmålet:
> Findes der noget værktøj til Linux til den slags?

Valgrind ?

Ellers kig i /proc/$$/statm ('$$' er process-IDet for dit program). Den
giver dig:

size - Samlet RAM forbrug
phys - Fysisk RAM
shar - Shared RAM
code - Kode
libs - Altid 0
data - Data + stack
dirs - Altid 0

Tallene overlapper hinanden (RAM forbrug er notorisk svært på linux), men du
kan nøjes med at se, om de vokser over tid.

-Claus

---

Claus Rasmussen wrote:

> Ellers kig i /proc/$$/statm ('$$' er process-IDet for dit program). Den
> giver dig:
>
> size - Samlet RAM forbrug
> phys - Fysisk RAM
> shar - Shared RAM
> code - Kode
> libs - Altid 0
> data - Data + stack
> dirs - Altid 0
>
> Tallene overlapper hinanden (RAM forbrug er notorisk svært på linux), men
> du kan nøjes med at se, om de vokser over tid.

Takker mange gange, det er rart at der er noget input på mit oprindelige
spørgsmål.

Hvis jeg laver en
- cat /proc/27468/statm
Så får jeg:
- 13039 189 141 44 0 12623 0

Og det tyder på, jeg muligvis skal kigge lidt på reserved stack space.
Men kan du elaborere over hvad der er 'high water mark', og hvad der er
reelt forbrug (lige nu)?

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> wrote in message news:481dffe0$0
> Og det tyder på, jeg muligvis skal kigge lidt på reserved stack space.
> Men kan du elaborere over hvad der er 'high water mark', og hvad der er
> reelt forbrug (lige nu)?
>

Never mind.
Jeg smed nogle tusind requests af sted, og den går (naturligvis) op og ned
igen.

Hvis man kan se det, kan man se det, og hvis man ikke kan, kan man ikke, men
en kort performance måling af en 'ting' burde ligger her:

http://wopr.lir.dk/wopr.isapi.monitor/statistics/peakmeasure/?db=%2FWOPR%2Fd
b%2Fwopr.monitor.db&uriid=1&fromdate=39572.0&todate=39572.9&ok=400.0&warn=55
0.0&warn2=800.0&submit=submit+form

For en god ordens skyld, skal jeg lige nævne, at målingerne er foretaget på
en arbitrær URI.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Thorbjørn Ravn Andersen wrote:
>
>> Ellers vil jeg anbefale dig at bruge et sprog der
>> foretager automatisk oprydning efter brug - det er virkelig en
>> fantastisk lettelse i dagligdagen.
>
> Tænker du på GC baserede ting?

Der er andre former for automatisk hukommelsesstyring end den
oprindelige naive 'stop the world' GC.

//Makholm

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Nu har jeg rodet med det her programmering i knap 30 år, og personligt synes
> jeg det er en fallierklæring at man ikke kan styre sine egne programmer.

Andvender du et styresystem? Er det ikke lidt en faliterklæring ikke
at kunne styre maskinen selv?

//Makholm

---

Peter Makholm wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>
>> Nu har jeg rodet med det her programmering i knap 30 år, og personligt
>> synes jeg det er en fallierklæring at man ikke kan styre sine egne
>> programmer.
>
> Andvender du et styresystem? Er det ikke lidt en faliterklæring ikke
> at kunne styre maskinen selv?

Den må du kunne gøre bedre .
Jeg prøvede at skrive:
> Det er jo nok et spørgsmål om ... religion

Du skal nok mere over i en analogi hvor jeg ikke har brug for
chauffør,vejviser,svigermor på bagsædet m.v. for at køre til bageren efter
morgenbrød (aka unødigt overhead).

--
Med venlig hilsen
Stig Johansen

---

Thorbjørn Ravn Andersen wrote:

>> Ja, _den_ compiler jeg bruger. Det er en evolution gennem ca 20 år. Men
>> ikke nødvendigvis en hvilken som helst tilfældig hype of the day
>> compiler.
>
> Nej. Det er så en smagssag. Personligt er jeg meget glad for at jeg
> ikke selv skal holde styr på at rydde alle objekterne op. Det er nok at
> skulle lukke databaseforbindelser osv når man er færdig med dem.

Smag og behag er forskellig, men hvis compileren understøtter RAII
princippet, kan jeg ikke se behovet for auto GC
<http://en.wikipedia.org/wiki/RAII>

En C++ destructor kan også lukke en DB connection.

--
Jesper Lund

---

---

Michael Rasmussen wrote:

> On Sat, 03 May 2008 06:40:33 +0200
> Stig Johansen <wopr.dk@gmaill.com> wrote:
>
>>
>> Det med at 'vi skriver 2008' er bare lidt brok fra min side.
>> Dokumentationen af TIME_WAIT siger at det er for at den skal have tid
>> til at tømme interne buffere, outstanding packets m.v.
>> I dagens danmark burde der ikke være behov for den lange tid. Det
>> virker som om det er en reminisens fra 1200 baud tiden.
>>
> Grunden til denne opførsel skyldes den grundliggende antagelse om god
> opførsel på nettet: Vær liberal med hvad du modtager, og konservativ
> med hvad du sender.
> Man skal skal ikke se på denne situation som en time_wait, men mere
> betragte det som en karantæne. Karantænen er indført for at tage
> hensyn til dårlig opførsel blandt klienter, som indebærer, at de
> glemmer at sende FIN tilbage til serveren. Forøvrigt er karantæne
> perioden for en TCP socket præcis 2 min.

Det er jeg med på.
Det er mere de 120 S., jeg 'brokker' mig over.
Ikke seriøst brok, for dengang nogen vedtog det skulle være 120 S var det
nok en passende størrelse.
Kiggede lige i
<http://tools.ietf.org/html/rfc793>
Den er fra 1981, men jeg så ikke lige om der nævnt størrelser på tiderne.

Der er ikke mere i det, en at jeg undrer mig over hvorfor man ikke
'ajourfører' time-wait perioden i takt med de højere hastigheder, og
kortere latency.

Hvis man eksempelvis bare satte den ned til 30 S kan man firedoble loaden.

> Du husker at sætte option SO_REUSEADDR inden, du laver bind?

Ja.
> Efter en bind er foretaget, har SO_REUSEADDR ingen effekt.

Exactly.

Men jeg vil lige sige, at de her ting med sockets jeg skriver, er baseret på
nysgerrighed under udviklingen, ikke en konkret og kortlagt / dokumenteret
test.

Det er muligt den stod til default port range 32768-61000 dengang.

Jeg er ved at ombygge nogle 'ting' til SQLite så jeg kan ikke p.t.
efterprøve 'ting'.

--
Med venlig hilsen
Stig Johansen

---

---

Michael Rasmussen wrote:

> On Sun, 04 May 2008 20:24:05 +0200
> Stig Johansen <wopr.dk@gmaill.com> wrote:
>> Og det tyder på, jeg muligvis skal kigge lidt på reserved stack space.
>> Men kan du elaborere over hvad der er 'high water mark', og hvad der
>> er reelt forbrug (lige nu)?
>>
> Måske denne kan hjælpe:
> http://mail.nl.linux.org/linux-mm/2003-03/msg00077.html

Det må jeg kigge på - engang.
Nu kører jeg med NPTL threads, hvor memory er shared, og ikke
kopieret/forked ud.
Så jeg er ikke så meget for dokumenter/ting omhandlende kernel før 2.6.

--
Med venlig hilsen
Stig Johansen

---

On Wed, 2008-04-30 at 08:03 +0200, Stig Johansen wrote:
> Hej alle.
>
> Jeg må indrømme jeg er lidt rusten udi *nix meen..

Prøv at læs:

http://www.oreilly.com/catalog/spt2/chapter/ch04.html

---

Christian E. Lysel wrote:

>
> On Wed, 2008-04-30 at 08:03 +0200, Stig Johansen wrote:
>> Hej alle.
>>
>> Jeg må indrømme jeg er lidt rusten udi *nix meen..
>
> Prøv at læs:
>
> http://www.oreilly.com/catalog/spt2/chapter/ch04.html

Jo tak, men jeg er ikke så interesseret i internals, der har man trods alt
trådt sine barnesko her:
<http://www.hpl.hp.com/palo_alto/>

Det der undrede mig var at 'top' ikke kan finde ud af at rapportere korrekt.
Jeg kører uden swap, så et forbrug, der overstiger den samlede ram, for en
enkelt process er ligesom en umulighed.

Claus har peget på /proc/$$/statm som mere ligner noget mere brugbart.

Som nævnt kører jeg med NPTL, hvor måske 90 - 95 % er global, eller shared,
memory.

Jeg er lidt ude efter at se hvor meger de enkelte _tråde_ bruger, ikke så
meget master processen.

I min MPE/iX verden havde vi måleværktøjer, der kunne fortælle om
min,max,avg, highwatermarks o. lign. på alt, disk i/o memory consumption
osv.

Det er nok mere sådan et værktøj jeg er ude efter.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 05-05-2008 22:04:

> I min MPE/iX verden havde vi måleværktøjer, der kunne fortælle om
> min,max,avg, highwatermarks o. lign. på alt, disk i/o memory consumption
> osv.

DET har man ikke brug for under Linux (og der er nok ikke nogen der har
gidet skrive det).

Den mest udspørgelige af slagsen jeg kender er Solaris. Den kan du
hente til x86 gratis, og den er nok mindst lige så stabil som Linux.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:

> Stig Johansen skrev den 05-05-2008 22:04:
>
>> I min MPE/iX verden havde vi måleværktøjer, der kunne fortælle om
>> min,max,avg, highwatermarks o. lign. på alt, disk i/o memory consumption
>> osv.
>
> DET har man ikke brug for under Linux (og der er nok ikke nogen der har
> gidet skrive det).

Ok, men det har man altså brug for til store transactions baserede systemer.

Jeg er med på, at der ikke er 'nogen', der har gidet at skrive det, men da
HP har store interesser i, og postet $B+ i Linux, kunne det være de havde
lavet noget.

Men på den anden side kostede værktøjet vistnok 2 spidser af en jetjager, så
det kommer nok ikke ud som opensource.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 05-05-2008 22:36:

>> DET har man ikke brug for under Linux (og der er nok ikke nogen der har
>> gidet skrive det).
>
> Ok, men det har man altså brug for til store transactions baserede systemer.

Ubetinget. Jeg savner selv gode værktøjer - sar fx - når der er bøvl
med et eller andet.

> Jeg er med på, at der ikke er 'nogen', der har gidet at skrive det, men da
> HP har store interesser i, og postet $B+ i Linux, kunne det være de havde
> lavet noget.

Jovist. Det har de sikkert også. Du må på hovedet i deres OpenSource
projekter.

> Men på den anden side kostede værktøjet vistnok 2 spidser af en jetjager, så
> det kommer nok ikke ud som opensource.

Jeg tror Sun har set lyset med deres "UD MED DET HELE som opensource".
Det kommer også fra de andre.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On Mon, 05 May 2008 22:45:54 +0200
Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:

> Ubetinget. Jeg savner selv gode værktøjer - sar fx - når der er bøvl
> med et eller andet.

installer sysstat pakken, så får du iostat og sar



--
//Jacob Gaarde
//Dont reply to my (aparent) e-mail address. Instead Use
//e-mail : gaarde <at> mailme <dot> dk

---

On Thu, 2008-05-08 at 15:14 +0200, Thorbjørn Ravn Andersen wrote:
> Smukt, takker. Et hurtigt kig giver flashback til Irix - om det så er
> godt eller ej, tænker jeg lige over.

Det bliver smukkere ... når du så sidder og kikker på data'erne sar
generere kan du starte med at kikke på:

http://www.linux.com/articles/114224

Eller blot http://ksar.atomique.net/index.html