---

Hej

I forbindelse med nogle ekstremt krævende brugere løber jeg ind i at de får
presset beregningsknuderne i bund og deres job crasher. Derved efterlader
jobbet et sted mellem 40 og 100GB i /tmp. Dem vil jeg gerne have slettet
automatisk. Problemet er bare, at det skal foregå på et kørende system af
hensyn til de andre jobs der kører clusteret/knuderne.

Er der nogle der har erfaring med slige ting? Og hvordan har I i givet faldt
løst det?

Thomas
--

---

Thomas S. Iversen wrote:

> Hej
>
> I forbindelse med nogle ekstremt krævende brugere løber jeg ind i at de
> får presset beregningsknuderne i bund og deres job crasher. Derved
> efterlader jobbet et sted mellem 40 og 100GB i /tmp. Dem vil jeg gerne
> have slettet automatisk. Problemet er bare, at det skal foregå på et
> kørende system af hensyn til de andre jobs der kører clusteret/knuderne.
>
> Er der nogle der har erfaring med slige ting? Og hvordan har I i givet
> faldt løst det?

Jeg har ingen erfaring, men der findes et tool kaldet "lsof" list of open
files, som ihvertfald kan give dig en ide om hvorvidt en fil i øjeblikket
er åben af en kørende proces.

Filer over en vis alder, over en vis størrelse, som ikke er åbnet i /tmp
kunne du jo så måske med en vis sikkerhed slette...

Alternativt er at forsøge at lave noget wrapper omkring folks programmer der
holder øje med hvilke filer de åbner, og sletter disse i tilfælde af crash.

Mads

--
Mads Bondo Dydensborg mads@dydensborg.dk http://www.madsdydensborg.dk/

The low quality of [MP3] files should prevent this format from threatening
control of our intellectual property. Why would anyone listen to a sub-CD
quality song when they can easily buy the CD at the local Tower Records?
- RIAA head, Hillary Rosen, March 1997

---

Mads Bondo Dydensborg <madsdyd@challenge.dk> skrev 2006-03-22:
> Jeg har ingen erfaring, men der findes et tool kaldet "lsof" list of open
> files, som ihvertfald kan give dig en ide om hvorvidt en fil i øjeblikket
> er åben af en kørende proces.

Ja den har jeg også tænkt på, men jeg ved at nogle af programmerne kører med
checkpoints, hvor de laver en ordentlig bunke data og så lukker filen. 3
skridt længere henne bliver filen så igen åbnet og læst. Det gør, at jeg
ikke kan lave antagelsen:

Hvis ikke nogen process tilgår filen så kan jeg slette den. Jeg kan også
have svært ved at lave en heuristik selvom jeg tager tiden ind for nogle af
de her jobs kører 30-60 dage ad gangen (når de ikke vælter

> Alternativt er at forsøge at lave noget wrapper omkring folks programmer der
> holder øje med hvilke filer de åbner, og sletter disse i tilfælde af crash.

Det vil jeg også lige se på.

Thomas
--

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

> I forbindelse med nogle ekstremt krævende brugere løber jeg ind i at de får
> presset beregningsknuderne i bund og deres job crasher. Derved efterlader
> jobbet et sted mellem 40 og 100GB i /tmp. Dem vil jeg gerne have slettet
> automatisk. Problemet er bare, at det skal foregå på et kørende system af
> hensyn til de andre jobs der kører clusteret/knuderne.
>
> Er der nogle der har erfaring med slige ting? Og hvordan har I i givet faldt
> løst det?

På både SuSE og FreeBSD, som er de systemer jeg bruger, er der mulighed for
at indstille periodisk sletning af filer i bl.a. /tmp ud fra tiden, filerne
senest er blevet tilgået (atime).

Du skriver ikke hvilket system, du bruger, men mon ikke der er noget
tilsvarende?

--
Christian Laursen

---

> at indstille periodisk sletning af filer i bl.a. /tmp ud fra tiden, filerne
> senest er blevet tilgået (atime).

Hmm, det vil jeg lige se på. Ved du hvilket program/script der rent faktisk
udfører arbejdet?

> Du skriver ikke hvilket system, du bruger, men mon ikke der er noget
> tilsvarende?

RHEL3

Thomas
--

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

>> at indstille periodisk sletning af filer i bl.a. /tmp ud fra tiden, filerne
>> senest er blevet tilgået (atime).
>
> Hmm, det vil jeg lige se på. Ved du hvilket program/script der rent faktisk
> udfører arbejdet?

På SuSE er det et script i cron.daily kaldet suse.de-clean-tmp.

Indstillingerne sættes i filen /etc/sysconfig/cron.

--
Christian Laursen

---

"Thomas S. Iversen" wrote:
>
> > at indstille periodisk sletning af filer i bl.a. /tmp ud fra tiden, filerne
> > senest er blevet tilgået (atime).
>
> Hmm, det vil jeg lige se på. Ved du hvilket program/script der rent faktisk
> udfører arbejdet?

tmpwatch. Prøv: rpm -ql tmpwatch

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspher"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

>> Hmm, det vil jeg lige se på. Ved du hvilket program/script der rent faktisk
>> udfører arbejdet?
>
> tmpwatch. Prøv: rpm -ql tmpwatch

Takker.

Thomas
--

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

> I forbindelse med nogle ekstremt krævende brugere løber jeg ind i at de får
> presset beregningsknuderne i bund og deres job crasher. Derved efterlader
> jobbet et sted mellem 40 og 100GB i /tmp. Dem vil jeg gerne have slettet
> automatisk. Problemet er bare, at det skal foregå på et kørende system af
> hensyn til de andre jobs der kører clusteret/knuderne.

Vil det eventuelt give mening at tildele dem et alternativt tmp, fx
/tmp/brugernavn?

Hvor kommer disse store filer fra?

--
Thorbjørn Ravn Andersen

---

> Vil det eventuelt give mening at tildele dem et alternativt tmp, fx
> /tmp/brugernavn?

Ja det var måske en mulighed. og så slette data når brugeren ikke er logget
ind mere (jobsene kører som brugerne selv). Den vil jeg lige tænke over.

> Hvor kommer disse store filer fra?

Skifter lidt. Gaussian, schroedinger og et par andre
molekyleberegningsprogrammer.

Det er folk der laver forskning og ikke altid lige tænker sig om og får
beregnet på en samling molekyler med for mange elektroner i for stor
detaljegrad. Så eksploderer det helt vildt i hukommelsesforbrug.

Thomas
--

---

On 2006-03-22, Thomas S. Iversen <zensonic@zensonic.dk> wrote:

>> Vil det eventuelt give mening at tildele dem et alternativt tmp, fx
>> /tmp/brugernavn?
>
> Ja det var måske en mulighed. og så slette data når brugeren ikke er logget
> ind mere (jobsene kører som brugerne selv). Den vil jeg lige tænke over.

Hvorfor så ikke blot checke uid på filen?

--
Andreas

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

> > Hvor kommer disse store filer fra?
>
> Skifter lidt. Gaussian, schroedinger og et par andre
> molekyleberegningsprogrammer.
>
> Det er folk der laver forskning og ikke altid lige tænker sig om og får
> beregnet på en samling molekyler med for mange elektroner i for stor
> detaljegrad. Så eksploderer det helt vildt i hukommelsesforbrug.

Lyder da som om I godt kunne bruge nogen 64-bit maskiner :)

Kunne nogen af de her 32-tråds Sparc CPU'er give en fordel i disse
beregninger?

--
Thorbjørn Ravn Andersen

---

> Lyder da som om I godt kunne bruge nogen 64-bit maskiner :)

Det er skam 64 bit maskiner, men der var "kun" penge til 2GB hukommelse pr.
node til at starte på. Og så er der også "kun" 100GB tmp. Jeg siger det
gerne igen: Fysikere og kemikere er de meste krævende computerbrugere. De
får gamere til at ligne nybegyndere!!

> Kunne nogen af de her 32-tråds Sparc CPU'er give en fordel i disse
> beregninger?

På nogle af dem. Nogle af beregningerne skalerer fint. Andre er helt
horible. Noget af det tungeste er simulering af en 30-40 molekyler og
tilhørende elektroner i flere milisekunder og det burde skalere fint.

Thomas
--

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

> Det er skam 64 bit maskiner, men der var "kun" penge til 2GB hukommelse pr.
> node til at starte på. Og så er der også "kun" 100GB tmp. Jeg siger det
> gerne igen: Fysikere og kemikere er de meste krævende computerbrugere. De
> får gamere til at ligne nybegyndere!!

Ved det. Var systemdims for sådanne nogen tilbage i midt90'erne.

> > Kunne nogen af de her 32-tråds Sparc CPU'er give en fordel i disse
> > beregninger?
>
> På nogle af dem. Nogle af beregningerne skalerer fint. Andre er helt
> horible. Noget af det tungeste er simulering af en 30-40 molekyler og
> tilhørende elektroner i flere milisekunder og det burde skalere fint.

Det er jo så bare at skovle CPU'er i. Er der nogen grund til at man
ikke slår sig sammen om nogen af de mange,mange cpumaskiner?
--
Thorbjørn Ravn Andersen

---

> Det er jo så bare at skovle CPU'er i. Er der nogen grund til at man
> ikke slår sig sammen om nogen af de mange,mange cpumaskiner?

Det ved jeg faktisk ikke. Jeg blev bare købt til at sætte det op og holde
dem lidt i hånden mens de lærte at køre det selv. Iøvrigt en sjov anekdote:
bevillingen til clusteret var KUN til indkøb af maskinel, der blev ikke sat
penge af til løn og vedligehold. Er det ikke typisk offentlig tankegang når
det er bedst?!

Nå, det var en tangent. Jeg ser på hvad jeg kan brygge sammen af cleanup
scripts med de her input.

Thomas
--

---

Thorbjørn Ravn Andersen wrote:
>
> Det er jo så bare at skovle CPU'er i. Er der nogen grund til at man
> ikke slår sig sammen om nogen af de mange,mange cpumaskiner?

Eller får nogen i USA (det er ikke tilgængeligt udenfor USA endnu) til
at loade jobbet ind i SUNs grid:

http://www.theregister.co.uk/2006/03/21/sun_fires_grid/

God smiles on Sun and delivers grid computing miracle
Let there be CPUs
By Ashlee Vance in Mountain View
Published Tuesday 21st March 2006 02:17 GMT

http://www.network.com/


Vh

--
Ole Michaelsen, Copenhagen, Denmark
http://www.olemichaelsen.dk/

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:

> Kunne nogen af de her 32-tråds Sparc CPU'er give en fordel i disse
> beregninger?

Du tænker på T1?

Den har (op til) 8 kerner til heltalsberegninger, men kun en til
floatingpoint beregninger. Samtidig er clockfrekvensen ikke voldsom.
Jeg ser primært dens styrke i hostingmiljøer, og ikke for alvor til
scientific computing.

De 32 tråde kommer så vidt jeg husker af at de påstår at en process
alligevel kun kan bruge CPU-tid en fjerdedel af tiden. Resten af tiden
venter den på I/O. Det var i hvert fald nogenlunde den historie jeg
hørte i december da jeg var til noget Sun-halløj.

--
Jacob

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> De 32 tråde kommer så vidt jeg husker af at de påstår at en process
> alligevel kun kan bruge CPU-tid en fjerdedel af tiden. Resten af tiden
> venter den på I/O. Det var i hvert fald nogenlunde den historie jeg
> hørte i december da jeg var til noget Sun-halløj.

Har bare skimmet noget niagarareklamehalløj.

Spørgsmålet i dette tilfælde er jo også hvor flaskehalsen er. Med de
mængder data, kan det faktisk godt være at disksystemerne er
problematiske hvis forskerne ikke har tænkt over lokalitet.

--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) writes:
> Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
>> De 32 tråde kommer så vidt jeg husker af at de påstår at en process
>> alligevel kun kan bruge CPU-tid en fjerdedel af tiden. Resten af tiden
>> venter den på I/O. Det var i hvert fald nogenlunde den historie jeg
>> hørte i december da jeg var til noget Sun-halløj.
>
> Har bare skimmet noget niagarareklamehalløj.

Den slags er ofte taknemmeligt

> Spørgsmålet i dette tilfælde er jo også hvor flaskehalsen er. Med de
> mængder data, kan det faktisk godt være at disksystemerne er
> problematiske hvis forskerne ikke har tænkt over lokalitet.

Klart, men min erfaring siger mig at folk lærer den slags ret hurtigt.
Det har vi i hvert fald lært på min arbejdsplads, hvor vi også gør en
del i diverse beregninger.

Jeg ser klart mere T1'erens styrker i hosting-miljøer, hvor man gerne
vil servere mange websider eller sende mange emails fra så få
rack-units som muligt. Det var også det Sun gerne ville sælge den på.
Den er som sagt heller ikke skide anvendelig til floating point
beregninger så vidt jeg har forstået.

--
Jacob - www.bunk.cc
You're using a keyboard! How quaint!

---

> Klart, men min erfaring siger mig at folk lærer den slags ret hurtigt.

Nogle steder. Her (Danmarks Farmaceutiske Universitet) lader man også
kandidat og phd studerende kører tunge beregninger. De får oftere startet en
"uheldig" beregning end de mere lærde folk. Problemet er også at springet
fra "nu presser vi grænsen for vores viden" til "Utopisk tung beregning"
oftest er hårfin herinde. Uvist af hvilken grund for mig (jeg er ikke
kemiker).

> Jeg ser klart mere T1'erens styrker i hosting-miljøer, hvor man gerne
> vil servere mange websider eller sende mange emails fra så få
> rack-units som muligt. Det var også det Sun gerne ville sælge den på.

Jeg har lige læst på Niagra chippen. Den lader ikke til at være egnet til
FPU beregninger som du siger.

Thomas
--

---

"Thomas S. Iversen" <zensonic@zensonic.dk> writes:

>> Klart, men min erfaring siger mig at folk lærer den slags ret hurtigt.
>
> Nogle steder. Her (Danmarks Farmaceutiske Universitet) lader man også
> kandidat og phd studerende kører tunge beregninger. De får oftere startet en
> "uheldig" beregning end de mere lærde folk. Problemet er også at springet
> fra "nu presser vi grænsen for vores viden" til "Utopisk tung beregning"
> oftest er hårfin herinde. Uvist af hvilken grund for mig (jeg er ikke
> kemiker).

Det kender jeg godt - jeg arbejder med bioinformatik. Der kan man også
hurtigt få en god idé til et eller andet man gerne vil regne ud og når
man så tænker sig lidt om komme i tanke om at det nok vil tage alt for
lang tid på den hardware man nu har tilgængeligt.

Jeg er så heldig(?) at arbejde et sted hvor vi er en ret begrænset
brugerskare der deles om ressourcerne, så vi har ikke de store
problemer med folk der crasher vores maskiner med umulige beregninger.

--
Jacob - www.bunk.cc
Success is a journey, not a destination.