Pagefile verplaatsen naar SSD zinvol of...?

[Sjaak_Banaan]

Onze server (2x Xeon 2.66GHz DC s771, 4GB ram, Server 2003 x86) is wat aan de trage kant geworden. Het budget laat het momenteel niet toe te investeren in een nieuwe server, dus zijn we op zoek naar en manier om voor weinig geld de boel wat sneller/minder traag te maken. Er staan 2 grote databases op waardoor het ram-geheugen vrijwel vol zit wat waarschijnlijk het probleem veroorzaakt.

Helaas is het een 32-bit systeem, dus ram upgraden is vrij zinloos.
Nu hebben we het idee om de pagefile te verplaatsen naar SSD schijf zodat het minder traag is.
Is dit een goed idee of levert het te weinig prestaties op?

Idee twee is om de databases te verhuizen naar een ssd waardoor ze sneller toegankelijk zijn.

Een derde idee is om een grotere SSD te kopen en de harddisk (2 partities) te clonen. In theorie zou dat moeten werken maar ik heb geen idee hoe dit in de praktijk moet worden uitgevoerd en of het überhaupt werkt.

We gaan natuurlijk ook proberen een aantal jaren te exporteren waardoor de databases zullen krimpen.

Heeft iemand hier ervaring mee of nog andere ideeën welke tegen een kleine prijs winst opleveren?
(Is een cpu upgrade eigenlijk toegestaan bij een OEM licentie? Stel dat we die goedkoop kunnen krijgen)

[Multi-X]

Om geld te besparen maar toch snelheid te winnen denk ik neit dat je met een SSD goed zult scoren. De reden is dat SSD die je voor zakelijk gebruik kunt kopen dit duur zal zijn.
Het zal altijd helpen om de pagefile op een apparte disk te hebben buiten je bestaande RAID array waar je DB op draait.

Je zegt RAM upgraden is zinloos, dit is niet waar dit geld namelijk alleen voor de Standard uitvoering van Windows Server 32 bit. De andere uitvoeringen hebben 64GB limiet.

Kijk hier: MSDN: Memory Limits for Windows Releases

[Rolfie]

Ik zou eerst eens kijken waar de performance issues precies in zitten.

Kans is idd groot dat je een geheugen issue hebt. Maar dit hangt van je type databases af, en wat er nu precies traag is.

Databases op SSD, zal misschien een performance winst op leveren. Maar wat als je SSD het begeeft? Daag database.....
Database logfiles op de SSD. Ook niet een fijn iets.

Pagefile op SSD, ook niet helemaal een lekker gevoel. Maar kan misschien wel wat oplossen, is zeker iets wat ik niet zou willen adviseren. maar is wel de minst slechte om te doen, maar nog steeds een risco. Maar een 32GB SSD kost ook zoveel.

[tss68nl]

Een pagefile heb je heel veel writes op toch?

SSD's en vele malen herschrijven gaat niet echt samen. Als je hem snel weg wilt gooien dan moet je juist dat doen.

SSD's zijn handig om als windows disk te gebruiken waarop je eenmalig windows en je programma's kan zetten. De pagefile zet je vervolgens op een normale schijf, en je propt gewoon genoeg geheugen in een machine zodat de pagefile minder nodig is. In zulk een configuratie is het lezen van gegevens benodigd voor uitvoer van windows of programma's een stuk sneller, en slijt je machine niet. Het zal echter nooit de overall performance van een machine verbeteren.

[Sjaak_Banaan]

Laat ons nou net de 'Standard Edition' hebben, zover had ik ook al gelezen

Het is vrijwel zeker een geheugen issue, onder performance zie je gewoon dat het constant zo goed als vol is.

Maar ik begrijp dus uit jullie reacties dat een consumenten SSD (bijvoorbeeld de Intel 320 serie) niet te vertrouwen is voor servergebruik? Zou een standaard harddisk wel voldoen voor de pagefile of is die winst minimaal?

Database op SSD hoeft toch niet zo'n probleem te zijn? Nu werk ik pas een jaar of zo met SSD, maar heb er nog nooit problemen mee gehad. Daarnaast wordt er dagelijks een backup gemaakt, dus weg zal die database niet zijn.

Tot nog toe lijkt de database inkrimpen de beste oplossing...

[PeterPan]

De Intel 311 is een kleine (20GB), relatief goedkope SSD met SLC geheugen chips.
Die zou je kunnen overwegen voor je pagefile.

[SteeringWheel]

Sjaak_Banaan schreef op vrijdag 02 maart 2012 @ 12:39:
Het is vrijwel zeker een geheugen issue, onder performance zie je gewoon dat het constant zo goed als vol is.

Indien SQL Server, die reserveert vrijwel al het geheugen, of het nou actief gebruikt wordt of niet. 'Vrijwel zeker' lijkt me niet goed genoeg. Memory issues kun je toch zo meten mbv perfmon lijkt me (oa Pages/Sec). Investeren in een SSD voor swap lijkt me qua prijs/prestatie vrij zinloos.

[ Voor 4% gewijzigd door SteeringWheel op 02-03-2012 13:21 ]

[Multi-X]

Sjaak_Banaan schreef op vrijdag 02 maart 2012 @ 12:39:
Laat ons nou net de 'Standard Edition' hebben, zover had ik ook al gelezen

Upgraden naar Enterprise.

[The Eagle]

Een pagefile op een SSD is geen goed idee, met name vanwege het vele aantal read/writes naar de pagefile. Een DB op een SSD is al een beter idee, maar dat hangt in dit geval ook samen met het beheer van het DBMS zelf (als in: bijvoorbeeld hoevaak worden de datafiles opgeschoond om lege ruimte vrij te maken).
Wil je een DB sneller maken, dan moet je al snel aan een RAID1 config denken en niet aan losse schijven, ongeacht of dat nou HDD's of SSD's zijn.

Nogmaals de vraag: om wat voor DB's gaat het? Oracle kan een stuk anders met geheugen omgaan als SQL server, om maar eens een zijstraat te noemen. Van Oracle weet ik dat als je een instance 4GB geheugen toekent, hij dat onder windows ook direct pakt, ongeacht of ie het nodig heeft. Het gebruik regelt ie zelf wel
Van het eigenlijke gebruik zie je op OS niveau dan ook vrijwel niks, maar een DBA kan een stuk meer zien.

Ik denk dat je eerst moet bepalen waar je bottleneck precies zit. "Traag" is namelijk nogal een breed begrip
Verder: realiseer je ook dat als jij hier een volle week aan besteed qua uren, je voor dat geld ook een instapserver had kunnen kopen. Soms is vervangen een goedkopere oplossing, en zeker bij oudere hardware is die "soms" een "steeds vaker"

[Milmoor]

Microsoft is het niet met je eens. Een SSD plus pagefile is juist een heel goed idee zijn. Ik kan helaas zo snel de bron niet terugvinden. Het was een artikel over SSD's in het algemeen en staat gequote in een van de grote SSD topics. Wat ik wel gevonden heb is een korte en bondige mening waar ik mij in kan vinden:
Hier is de catch: zet je de pagefile op de SSD genereer je een kleine hoeveelheid schrijfbewerkingen, maar als je de pagefile echt nodig hebt en hij staat op de HDD heb je een vrij grote performancehit. Gewoon op de SSD gooien dus.
Maar dat gaat wel uit van consumenten situaties. Anandtech heeft laatst een analyse gedaan van een bedrijfssituatie en SSD's met cijfertjes.

[ Voor 4% gewijzigd door Milmoor op 03-03-2012 21:34 ]

[ACM]

tss68nl schreef op vrijdag 02 maart 2012 @ 12:30:
Een pagefile heb je heel veel writes op toch?

Een pagefile gebruik je liever natuurlijk zo min mogelijk. Het is een kunstgreep om meer geheugen beschikbaar te krijgen. Het OS zal dan ook juist relatief ongebruikt geheugen er heen verplaatsen om zo ruimte in het RAM nuttiger in te kunnen zetten.

Als je een SSD gaat gebruiken voor de pagefile lijkt me dat je het verkeerde probleem zit op te lossen. Bij een database heb je vooral voor twee dingen geheugen nodig:
- Het geheugen dat nodig is om een query te kunnen verwerken
- Het geheugen dat nodig is om de meest gebruikte data snel bij de hand te hebben

Alle RAM die over is kan voor de 2e punt gebruikt worden. Er zijn ook databases die dat aan de OS' page/diskcache functionaliteit overlaten of een hybride model hanteren en een deelf zelf bijhouden en 'de rest' aan het OS over laten. Ik weet niet hoe MS SQL Server het doet (ik geloof alles in eigen beheer?), maar meer RAM is vrijwel altijd beter in die context. Althans, er komt een punt dat het niet meer toevoegt (als je een 1GB database hebt, biedt een server met 128GB RAM je waarschijnlijk weinig meer dan eentje met slechts 4GB). Bovendien gebruik je normaliter niet alle data van je database veel, waardoor je alleen maar ruim voldoende geheugen voor de actieve dataset hoeft te hebben.

Alles wat niet in het RAM zit, moet uiteraard van de permanente storage komen. Dus het is de bedoeling dat je RAM vol zit... want anders ben je snel RAM-geheugen aan het verspillen (door het niet te gebruiken) en dwing je het systeem om langzame storage te benaderen.

Zodra je je database echter zo configureert dat ie zijn "RAM"-cache van veelgebruikte data in de pagefile stopt, dan ben je effectief die data op twee plekken van disk aan het lezen... Dan kan je database het dus beter gewoon van de originele plek van de disk gaan lezen.

Mocht er dus meer "disk cache" nodig zijn, dan lijkt het me alleen zinvol om dat op te lossen door meer RAM toe te voegen. En dat lijkt in jouw geval niet mogelijk bij gebrek aan 64bits OS of ondersteuning voor PAE. Bovendien lijkt het me niet dat een 32bits SQL Server in de praktijk meer dan in totaal 4GB aan data in geheugen kan bewaren, ongeacht hoeveel virtueel geheugen je er in totaal voor beschikbaar maakt (maar met een 64bits of PAE-OS zou je alsnog wel meer disk-cache van je OS krijgen en alsnog winst kunnen boeken met meer RAM).

Naast investeren in meer RAM-geheugen is het voor databases ook nuttig om snellere disk-I/O te hebben.
Daarmee kan je dan de kosten van een "cache miss" verlagen. In de praktijk heb je daar dan weer allerlei oplossingen voor, onder andere snellere storage kopen en/of een secundaire cache. Wat beide met een SSD kan worden opgelost.

Of je systeem ook praktisch van SSD voorzien kan worden is natuurlijk een hele andere vraag. Als je nog disk-bays over hebt zou je er een tweetal Intel 320's in RAID1 in kunnen steken en zien of dat beter gaat. Ik denk echter dat het niet enorm zinvol gaat zijn om de pagefile naar een SSD te verhuizen, 't zou me verbazen als je daar noemenswaardige performancewinst uit krijgt, tenzij je daadwerkelijk fors zit te swappen (maar dan is je database sowieso al verkeerd geconfigureerd).

Overigens moet je de gebrekkige beschijfbaarheid van consumentendrives ook weer niet overdrijven. Over het algemeen kan je er nog steeds vele terabytes of zelfs petabytes naartoe schrijven.

Dus hoewel ik het eens ben met het statement dat het geen goed is om de pagefile naar een SSD te verplaatsen, ben ik het niet eens met de reden die ervoor wordt gegeven

[The Eagle]

Ik ben het over het algemeen ook niet met MS eens, dus dat treft
In een consumentensituatie heb je het niet over schijven die 24/7 aan staan, en over hardware die een stuk minder intensief gebruikt wordt. Imho een totaal onvergelijkbare situatie. Bovendien: de meeste consumenten PC's hebben niet meer dan 1 HDD (of SDD) ingebouwd. Als ie vol zit kopen ze wel een andere. Geldt uiteraard niet voor tweakers, maar dat zijn ook geen normale consumenten

Daarnaast: we hebben nog steeds niet van de TS gehoord wat voor DB's ie nou draait en waar hem precies de bottleneck zit. Ik denk dat dat veel belangrijker is in deze dan simpelweg een SSD kopen en kijken wat het doet.

[ACM]

The Eagle schreef op zondag 04 maart 2012 @ 22:37:
Daarnaast: we hebben nog steeds niet van de TS gehoord wat voor DB's ie nou draait en waar hem precies de bottleneck zit. Ik denk dat dat veel belangrijker is in deze dan simpelweg een SSD kopen en kijken wat het doet.

Dat is natuurlijk sowieso nuttig. Het is vrij gebruikelijk dat er een index op een grote, veelgebruikte tabel mist, waardoor het ook met een SSD nog steeds traag zou zijn en het zonder investeringen in hardware zou zijn op te lossen.
Dus databasetuning (indexen toevoegen/verbeteren waar nodig, etc) en querytuning (indexen en andere data efficienter gebruiken) zijn zeker punten van aandacht, vooral omdat ze precies in de vraag van de TS passen (zonder geld uitgeven de performance verbeteren)

Of wellicht is het helemaal de database niet...

[The Eagle]

Idd

En daarbij: welke kosten wil ie maken voor onderzoek en fixen? Globale kosten/baten analyse is denk ik oo op zijn plaats. Hoe lang wil men doormodderen met de huidige machine?

Simpele test is overigens door een van de twee DB's plat te gooien en kijken of dat een hoop performance winst oplevert. If so, dan ligt het dus aan de DB's. Kun je ook meteen zien welke processen er behalve de DB's een hoop CPU en RAM verstoken.

Overigens zou ik de DB's altijd naar een RAID1+0 config verplaatsen (HDD of SSD). Levert een stuk snelheid en een stuk extra veiligheid op. Kost je wel 3 HDD/SSD's ipv 1.

[ Voor 53% gewijzigd door The Eagle op 04-03-2012 22:51 ]

[Sjaak_Banaan]

Sorry voor de late reactie.... het betreffen SQL databases.
Databasetuning klinkt interessant, want voor zover ik weet gebeurt dat zelden of niet... dat ga ik zeker even checken bij systeembeheer.

[The Eagle]

Met SQL databases bedoel je neem ik aan MS SQL databases?
(als in: SQL is simpelweg de taal waarmee je de boel benadert. Er bestaat ook zoiets als MySQL, NoSQL, etc)

Overigens zal in het algemeen DB tuning niet direct invloed hebben op het geheugengebruik (een Oracle of MS SQL DB instance pakt namelijk meteen de hoeveelheid geheugen die voor hem gereserveerd is), maar als je de boel tuned dan kun je mogelijk wel met minder geheugen toe --> dan kun je dus de hoeveelheid te gebruiken geheugen terugbrengen. En dat scheelt wel

[AndriesLouw]

ACM schreef op zondag 04 maart 2012 @ 22:34:
[...]

Een pagefile (...) wordt gegeven

Mag ik je bedanken voor deze heldere post? Niet dat ik iets te maken heb met de TS of MS SQL, maar het geeft me wel inzicht op database-performance-gebieden die voorheen nog wat vaag waren voor me!

[PolarBear]

Lees dit even door mbt memory managment van SQL Server. Het memory management van SQL server is geavanceerd en zal zeker niet zomaar meer claimen dan nodig is.

MSDN: Inside SQL Server's Memory Management Facilities

As the server runs, the memory manager checks to make sure that a given amount of physical memory remains available on the server so that Windows and other applications on the server continue to run smoothly. This amount can vary between 4MB and 10MB (it trends closer to 10MB on Windows Server 2003) and is based on the system load and the page life expectancy for the BPool. If the available physical memory on the server begins to dip below this threshold, the server decommits BPool pages in order to shrink its physical storage usage (assuming that dynamic memory configuration is enabled). The memory manager also ensures that a given number of pages remain free at any given point in time so that, as new allocation requests come in, they will not have to wait for memory to be allocated. By "free," I mean that the page is committed but not used. Unused committed BPool pages are tracked via a free list. As pages are used from this list, the memory manager commits more pages from the BPool reservation until the entire reservation has been committed. You will see the Process:Private Bytes Perfmon counter increase gradually (and usually linearly) due to this activity.