[W2K / *nix] 'vollopen' geheugen door SQL

[klokop]

Op mijn vraag
'Waarom is de interne server zo traag?'
krijg ik van onze sysop regelmatig/altijd het antwoord
'Het geheugen van de sql server is volgelopen, ik zal de server ff rebooten'.

De server is een win2k bak met MS-SQL server.

En schijnbaar moet die server eens in de zoveel tijd ff gereboot worden, vooral na het doen van zware sql operaties. Nou vraag ik mij af of dat op een Linux server ook wel eens gebeurt? Iemand ervaring mee? Dit in het kader van info vergaren om 'men' over te halen op *ix over te stappen.

[Freek]

Haalt ie niet op de een of andere manier, niet meer nuttige info autmagisch uit het geheugen?

[Koffie]

Move PNS > NOS + titel edit

[Marzman]

Bij een linuxserver loopt het geheugen ook langzaam aan vol, maar op het moment dat hij het nodig heeft haalt hij wel automatisch de minder zinnige dingen uit het geheugen.

[Verwijderd]

Of die bak wel of niet over de kop gaat is een kwestie van resource mgmt, wat voor zover ik weet, ook onder 2k kan (foei @ jouw sysop). Verder is het voor een "overstap" veel interesanter om te weten hoe men met die database(s) omgaat. Gebruik je stored-procedures, wazige frontends etcetc.... Memory mgmt is daarbij nog wel je minste zorg.

[klokop]

Ik was al bang dat het allemaal niet zo simpel zou liggen .

Ik denk eerlijk gezegd niet dat ik er nog in slaag men over te halen over te stappen op een *nix omgeving...

Wat het al dan niet overstappen op *nix met stored procedures te maken heeft snap ik niet r3b00t? Leg eens uit .

[pinball]

als in: zijn de functies/features die jullie nu gebruiken ook beschikbaar op <ander platform>
stel dat jullie stored procedures intensief gebruiken en die bestaan niet op mysql onder linux, dan heb je dus een probleem.

edit:

en trouwens, stuur je db-beheerder eens op cursus, kan ie leren hoe geheugenmanagement werkt met mssql/win2k, zodat ie niet steeds hoeft te herstarten

[ Voor 30% gewijzigd door pinball op 20-06-2003 15:01 . Reden: free advice ]

[klokop]

Ik heb MySQL nooit genoemd

[Verwijderd]

Disclaimer: mijn DB kennis is niet groot, dus dit is voornamelijk theorie, en dingen die ik in de praktijk ben tegen gekomen

Op het moment dat jij in MS-SQL een stored procedure schrijft, en die wil je gebruiken in, ik zeg maar wat, postgresql, dan kun je er nog wel eens tegenaanlopen dat de syntax tussen beide SQL talen iets verschillend is (zou me niets verbazen iig).

Het zijn niet alleen de stored procedures hoor. Een database is een platform imo (je hebt de backend (de DB), en je hebt een frontend (eg ms access, www, etc). Dat is in jullie geval gemaakt voor MS-SQL, en dat dient dan gepoort te worden naar, bijvoorbeeld, postgresql. Met deze poort-slag zul je, meestal, de meeste problemen tegenkomen, en ik weet niet jouw mgmt daar zo blij mee zal zijn...

[klokop]

Pinball schreef op 20 juni 2003 @ 14:58:

edit:

en trouwens, stuur je db-beheerder eens op cursus, kan ie leren hoe geheugenmanagement werkt met mssql/win2k, zodat ie niet steeds hoeft te herstarten

Tsja...

[ge-flopt]

Ik heb ook niet erg veel kennis van databases, maar ik denk de enige manier om het geheugen van de db server vol te laten lopen, is door een programma te draaien die doordat hij slecht geprogrameerd is het geheel vol laat lopen maar het niet meer vrij geeft. Is volgens mij het enoge wat direct kan.

[Verwijderd]

ge-flopt schreef op 20 June 2003 @ 15:07:
Ik heb ook niet erg veel kennis van databases, maar ik denk de enige manier om het geheugen van de db server vol te laten lopen, is door een programma te draaien die doordat hij slecht geprogrameerd is het geheel vol laat lopen maar het niet meer vrij geeft. Is volgens mij het enoge wat direct kan.

Draai maar wat "zware" queries, bij voorkeur met veel cursoren en kijk eens naar het geheugen gebruik...

Niets te maken met "slect geprogrammeerd"...

[ge-flopt]

Ik heb het eens voor elkaar gekregen met een simpele query, om in een sec. of dertig 512 MB vol te krijgen: zoek uit hoveel records je in een database hebt: maak dan een loop die het record uitleest: Vergeet een statement te maken wat naar het volgende record uitlees. In dertig seconden 512 MB Vol. Door slecht programeer werk.

[klokop]

...maar der servert zegt dan op een gegeven moment 'hohoho, dat script van joe duurt te lang, ik stop met het uitvoeren van dat ding' en knikkert vervolgens alles weer uut 't g'heugen. Toch? 't Is niet zo dat er wat dingen achter blijven?

[_JGC_]

MSSQL vreet alle geheugen die ie maar kan krijgen, zo staat ie standaard ingesteld. Als die beheerder gewoon even nadenkt, en aangeeft in de MSSQL configuratie dat MSSQL alle geheugen op 128MB na mag opvreten, blijft die server enigszins werkbaar en hoeft ie niet te rebooten na een zware operatie.

En nee, het ligt niet aan Windows of MSSQL, het is duidelijk de beheerder die fouten maakt

Op linux gaat het net zo hard met programma's die op deze manier geheugen vreten. Op school draaiden we Tomcat4, een webservertje gemaakt in Java om JSPs te compilen en uit te voeren. Guess what? de OOM killer kwam gewoon elk halfuur langs om de hele server weer reagerend te maken. Resultaat: elk halfuur klagende studenten omdat Tomcat4 weer es alles opgevroten had, half gekilled was door de OOM en zo bleef als ie stond: dood. Probleem met Java is alleen dat het gewoon niet werkt in de situatie waar wij het in gebruiken: een webserver voor 75 studenten die opdrachten moeten maken erop, terwijl je normaal Tomcat4 servers ziet staan waarbij 6 servers het werk voor 1 site doen

[ge-flopt]

klokop schreef op 20 June 2003 @ 17:09:
...maar der servert zegt dan op een gegeven moment 'hohoho, dat script van joe duurt te lang, ik stop met het uitvoeren van dat ding' en knikkert vervolgens alles weer uut 't g'heugen. Toch? 't Is niet zo dat er wat dingen achter blijven?

Nee hoor niet helemaal: Als een script iets start en dat duurt lang voordat er er info terug komt dat het script nog leeft dan killed hij hem. De situatie die ik schets kan gewoon want bij elke loop leest hij het records in dus de server weet dat het script nog "leeft", want de server start elke keer het record request.

[ Voor 8% gewijzigd door ge-flopt op 20-06-2003 19:36 ]