[SQL2005] Traag, over op SSD?

[HellStorm666]

Mijn Probleem
We hebben hier een SQL server 2005 draaien op een S2008 server.
Deze gebruiken wij voor ProductStream (database pakket voor 3D tekeningen ed)

De database is 2GB groot, de files die er bij horen zijn 476GB en groeiende.

Helaas is dit systeem erg traag. Het openen van een project gaat gewoon vervelend langzaam. Zelfs het opbouwen van de lijst schiet niet op.

Relevante software en hardware die ik gebruik
Windows Server 2008
SQL server 2005

Server is een Dell T110
Xeon X3450
2x 4GB DDR3
1x C: WD250ABYS (Windows)
2x E: Hitachi Deskstar 7K2000 (RAID 1 (mirror)) (Database + Files+ Backup)
1x F: WD20EADS (Backup)


Wat ik al gevonden of geprobeerd heb
Ik heb wat tests gedaan en wat monitoring.
CPU load is tussen de 7% en 20%
Mem is 82% gebruikt (4,2GB voor sqlsrv)

Dit lijkt mij allemaal prima.
Dus zal het aan de HDD's liggen of een instelling (is mijn gedachte)

diskspd gedraait (diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat)
CPU avg is daar 5,61%
Total IO: 379MB, 3.01 MB/s, 385 I/O per s, AvgLat 82,912ms
Read IO: 2.26 MB/s, 289 I/O per s, AvgLat 108ms
Write IO: 0,75 MB/s, 96 I/O per s, AvgLat 6ms

Nu lijkt dit mij wel heel slecht.
2,2 MB/s lezen uit de DB schiet natuurlijk niet op. Zeker niet als dat met 7 man tegelijk gebeurt.

Mijn vraag
Is het systeem inderdaad traag door de HDD's?
Helpt het als ik er 2x SSD Sandisk Ultra? in doe?
Zo ja, deze dan in RAID 1 (mirror) zetten? of gewoon elk uur backup en dan op 1 SSD houden?
Zit het probleem ergens anders?

[Dennism]

Tja, als je kijk naar de hardware dan kan die zeker wel een boost gebruiken. Je draait een productie database op consumer grade disks, daar kan je geen performance uit verwachten.

SSD's kunnen hier zeker de boel helpen verwacht ik, of de San disk ultra een goede keuze is weer ik niet. Ik zou er iig voor zorgen dat je SSD's neemt die beveiligd zijn tegen powerloss bij het draaien van SQL databases.

Tevens zou je ook kunnen kijken naar je disk configuratie, SQL databases, files en backups of dezelfde disks is in ieder geval zeker geen best practise voor SQL Server. Ik zou er minimaal voor zonder dat de files op eigen disks komen te staan, de SQL databases op eigen disks en backups ergens buiten de server opgeslagen worden.

Houd er ook rekening mee dat SQL 2005 out of support is, ook hier zou je een upgrade kunnen overwegen, ik kan me bijv. voorstellen dat de leverancier van Product Stream er ook niet blij mee is dat de database op niet supported software draait.

Verder zou ik ook zeker eens een balletje opgooien bij de leverancier van Product Stream, wat voor configuratie bevelen zij aan op hardware en software gebied, welke diskconfiguraties voor de SQL databases e.d. Ik kan me namelijk bijna niet voorstellen dat een systeem als bovenstaande voldoet aan de minimale vereisten van een leverancier die gebruikmaakt van SQL databases.

[Hero of Time]

Je kan het beste investeren in geheugen. Een SSD kan ook zeker helpen, maar RAM bied veel meer winst. Het wil namelijk zo veel mogelijk in RAM doen en als het constant aan het 'swappen' is naar schijf, haal je bedroevend lage snelheden, zoals je laat zien.

De grootte van een database zegt niets over hoeveel geheugen het nodig heeft. Er gebeurt namelijk ook veel in tijdelijke tables en die zie je niet terug op je schijf.

[Jazzy]

Meten is weten, doe anders eerst eens een performance test met de PAL tool. Die meet niet alleen maar levert ook een helder rapport op waar in staat wat de bottleneck is.

[HeatWave]

8GB is wel karig voor een SQLserver idd. Ik zou dat zeker ook meenemen in de upgrade.

[Dennism]

Hero of Time schreef op vrijdag 27 mei 2016 @ 13:36:
Je kan het beste investeren in geheugen. Een SSD kan ook zeker helpen, maar RAM bied veel meer winst. Het wil namelijk zo veel mogelijk in RAM doen en als het constant aan het 'swappen' is naar schijf, haal je bedroevend lage snelheden, zoals je laat zien.

De grootte van een database zegt niets over hoeveel geheugen het nodig heeft. Er gebeurt namelijk ook veel in tijdelijke tables en die zie je niet terug op je schijf.

Geheugen kan inderdaad ook, al is 82% in gebruik wel weinig als het een geheugen issue zou zijn (tenzij er bepaalde instellingen gedaan zijn om geheugen gebruik te beperken).De MS SQL servers die ik met performance problemen heb zien lopen primair veroorzaakt door een gebrek aan geheugen zaten altijd op rond de 98-100% geheugen gebruik.

[HellStorm666]

Even ter info, CADAC is onze leverancier voor Productstream, en zij hebben dan ook de server geinstalleerd.
Dus de SQL2005 is een keuze van hun, net als het alles op 1 disk hebben draaien. (vond dit ook al raar).

Meer RAM gaat dus helpen, ondanks dat het ramgebruik nu niet 100% is?

[Jazzy]

HellStorm666 schreef op vrijdag 27 mei 2016 @ 13:44:
Meer RAM gaat dus helpen, ondanks dat het ramgebruik nu niet 100% is?

Nee, eerst meten zodat je zeker weet wat de bottleneck is. Niemand kan zomaar op afstand zeggen wat je moet upgraden zonder de details te kennen. Straks heb je de hele server vervangen en blijkt het aan een applicatieprobleem te liggen.

[ Voor 27% gewijzigd door Jazzy op 27-05-2016 13:46 ]

[HellStorm666]

Jazzy schreef op vrijdag 27 mei 2016 @ 13:38:
Meten is weten, doe anders eerst eens een performance test met de PAL tool. Die meet niet alleen maar levert ook een helder rapport op waar in staat wat de bottleneck is.

Waar kan ik dat PAL tool vinden?

[Jazzy]

Hier.

[ Voor 26% gewijzigd door Jazzy op 27-05-2016 13:48 ]

[Craven]

Hero of Time schreef op vrijdag 27 mei 2016 @ 13:36:
Je kan het beste investeren in geheugen. Een SSD kan ook zeker helpen, maar RAM bied veel meer winst. Het wil namelijk zo veel mogelijk in RAM doen en als het constant aan het 'swappen' is naar schijf, haal je bedroevend lage snelheden, zoals je laat zien.

De grootte van een database zegt niets over hoeveel geheugen het nodig heeft. Er gebeurt namelijk ook veel in tijdelijke tables en die zie je niet terug op je schijf.

Als ik lees dat zijn DB 2GB is de files die ernaast zitten 476 dan zou ik toch eerst gaan meten waar de traagheid vandaan komt. Memory is zeker interessant. Maar als jullie veel van die 476GB aanspreken dan moet een ssd ook zeker nuttig zijn.

Overigens kun je je gezien de kosten, want wat kost 16GB mem + 2 ssd's nou tegenwoordig, wel afvragen of je veel tijd moet steken in onderzoeken i.p.v. dat je het er gewoon in stampt.

[maratropa]

Ligt het ook niet gewoon aan met 7 man 500GB aan data (op een HD) via een 1gbit lijntje benaderen?

[ Voor 6% gewijzigd door maratropa op 27-05-2016 13:49 ]

[HellStorm666]

Craven schreef op vrijdag 27 mei 2016 @ 13:48:
[...]

Als ik lees dat zijn DB 2GB is de files die ernaast zitten 476 dan zou ik toch eerst gaan meten waar de traagheid vandaan komt. Memory is zeker interessant. Maar als jullie veel van die 476GB aanspreken dan moet een ssd ook zeker nuttig zijn.

Overigens kun je je gezien de kosten, want wat kost 16GB mem + 2 ssd's nou tegenwoordig, wel afvragen of je veel tijd moet steken in onderzoeken i.p.v. dat je het er gewoon in stampt.

Die 2 SSD's dan dus in RAID 1?
had begrepen dat SSD en RAID een no-go is, of is dat niet voor mirror?

[HellStorm666]

maratropa schreef op vrijdag 27 mei 2016 @ 13:49:
Ligt het ook niet gewoon aan met 7 man 500GB aan data (op een HD) via een 1gbit lijntje benaderen?

Nope, had ik al gemeten, wordt nog geen eens 20Mbit gebruikt.
En iperf testje liet zien dat 980Mbit gewoon gehaald werd.

[DukeBox]

Hoeveelheid IO is wel erg laag, zelfs voor een fileserver, laat staan voor een sql server.
Wat voor raid controller zit er in ? En hoeveel (write) cache heeft die ?

[HellStorm666]

DukeBox schreef op vrijdag 27 mei 2016 @ 13:51:
Hoeveelheid IO is wel erg laag, zelfs voor een fileserver, laat staan voor een sql server.
Wat voor raid controller zit er in ? En hoeveel (write) cache heeft die ?

IDE controller is een Intel AHCI.
En Microsoft VHD HBA (Volgens mij gebruiken we software RAID 1)

[Dennism]

HellStorm666 schreef op vrijdag 27 mei 2016 @ 13:49:
[...]

Die 2 SSD's dan dus in RAID 1?
had begrepen dat SSD en RAID een no-go is, of is dat niet voor mirror?

Ik zou zeker geen 2 SSD's pakken, maar minimaal 4 of zelfs meer als je direct voor SSD's gaat zonder verder onderzoek. Waarom een brakke oplossing vervangen voor een net iets minder brakke oplossing, als je er toch aan gaat sleutelen, doe het dan imho gelijk goed.

Doe wat Jazzy zegt, ga meten, bepaal de bottlenecks en ga dan kijken naar hardware om deze bottlenecks te verhelpen.

Dat een machine opgezet is door de leverancier een jaar of (ik gok) 8 geleden betekend natuurlijk niet deze deze opstelling nog steeds aan de eisen voldoet.

Verder zou ik echt minimaal de Files, Databases en de backup gaan opsplitsen en zeker niet op het zelfde volume / schijven set laten staan. Raid 1 gaat verder prima met SSD's. Intel software raid zou ik trouwens zelf nooit en te nimmer inzetten op een productie server.

[ Voor 7% gewijzigd door Dennism op 27-05-2016 13:56 ]

[Hero of Time]

Dennism schreef op vrijdag 27 mei 2016 @ 13:44:
[...]


Geheugen kan inderdaad ook, al is 82% in gebruik wel weinig als het een geheugen issue zou zijn (tenzij er bepaalde instellingen gedaan zijn om geheugen gebruik te beperken).De MS SQL servers die ik met performance problemen heb zien lopen primair veroorzaakt door een gebrek aan geheugen zaten altijd op rond de 98-100% geheugen gebruik.

Het verschil zit 'm in gebruik en cache. Je kan 80% van je geheugen in gebruik hebben, maar als de overige 20% cache is en daar je programma in werkt, wordt het uiteindelijk gewoon bagger traag omdat de cache ruimte onvoldoende is om acties in z'n geheel vanuit cache te draaien. Dat zie je niet terug in werkelijk gebruik.


Maar de tip voor I/O controleren is ook een goede. Kijk eens met Perfmon wat de schijf doet. Is het veel I/O wait, seek of andere dingen?

[DukeBox]

Dennism schreef op vrijdag 27 mei 2016 @ 13:54:
Ik zou zeker geen 2 SSD's pakken, maar minimaal 4 of zelfs meer. Waarom een brakke oplossing vervangen voor een net iets minder brakke oplossing, als je er toch aan gaat sleutelen, doe het dan imho gelijk goed.

Wat is er brak aan 2 SSD's in mirror ?

Hero of Time schreef op vrijdag 27 mei 2016 @ 13:55:
Het verschil zit 'm in gebruik en cache.

Een DB van maar 2GB groot mag geen memory probleem zijn op een 2008 server met 8GB waar buiten een fileserver niets op draait.

[ Voor 28% gewijzigd door DukeBox op 27-05-2016 13:57 ]

[Dennism]

DukeBox schreef op vrijdag 27 mei 2016 @ 13:55:
[...]

Wat is er brak aan 2 SSD's in mirror ?

Ik bedoel niet de SSD's an sich, maar je wil gewoon niet je SQL databases op dezelfde diskset hebben staan als je fileshares en je backup. Vandaar meerdere Raid 1 disksets (minimaal 1 voor SQL databases, en 1 voor de Fileshares).

[HellStorm666]

Wat moet ik precies monitoren/meten, want daar kom ik niet echt uit.
PAL Tool begint direct met moeilijke vragen te komen... Counter Log... geen idee?

Perf mon heb ik wat in gemonitord, daar lijkt de I/O wait wat schommelen, maar komt niet boven de 2 uit (tenzij ik die dd test doe, dan wordt ie 14 oid).

[HellStorm666]

Systeem is trouwens in juni 2010 opgezet en is vorig jaar nog onder handen genomen omdat we problemen bleven houden.

[DonJunior]

juni 2010 is ook alweer 6 jaar geleden.. 6 jaar is erg veel in computer jaren

[DukeBox]

Dennism schreef op vrijdag 27 mei 2016 @ 13:58:
Ik bedoel niet de SSD's an sich, maar je wil gewoon niet je SQL databases op dezelfde diskset hebben staan als je fileshares en je backup.

Een database van maar 2 GB ? Daar ga je geen aparte SSD set's voor maken..

Denk dat TS moet kijken wat mogelijk is qua uitbreiding en/of vervanging. Een goede raid controller kan al wonderen doen maar de eenvoudige oplossing van 2 flinke SSD's in mirror is prijs technisch gezien ook zeer interessant. De oude HDD('s) kan je dan altijd als backup disk gebruiken.

[Question Mark]

Tenzij de oorzaak geen disk bottleneck is natuurlijk, dan is het weggegooid geld...

TS zal echt eerst moeten gaan meten.Een mooi startpunt is hier:

How to troubleshoot SQL Server performance issues

[wagenveld]

Waar je waarschijnlijk ook tegen aanloopt (naast wat al genoemd is) is dat de instap Dells wel een RAID controller hebben, maar die is gebaseerd op de onboard Intel chip met een Dell sausje. In jouw geval waarschijnlijk een S100 of een H200. Omdat er geen BBWC aanwezig is schakelen deze controllers standaard de write cache van de schijven uit. Resultaat is belabberde disk performance.
Zie ook: http://www.dell.com/suppo.../en?c=us&l=en&s=bsd&cs=04
en: http://betanews.com/2014/...ow-end-server-raid-cards/

Dit is in de eerste plaats om ervoor te zorgen dat je bij stroomuitval geen data corruptie krijgt. De beste tip is om bij een volgende server sowieso te kijken naar een goede RAID controller met BBWC.

[ Voor 6% gewijzigd door wagenveld op 27-05-2016 14:33 ]

[Hero of Time]

DukeBox schreef op vrijdag 27 mei 2016 @ 13:55:
[...]

Een DB van maar 2GB groot mag geen memory probleem zijn op een 2008 server met 8GB waar buiten een fileserver niets op draait.

Is het ook niet, maar de TS heeft het tevens over lage I/O met z'n fileserver. Dat deel wil ook graag dingen cachen in geheugen en als je database in geheugen staat, maar er ruimte in de cache is om werk uit te voeren (denk aan updates, writes en delete), dan wordt de harde schijf ook telkens aangeroepen. Zeg dan maar tegen je database performance.

[HellStorm666]

Sorry, maar die links over het troubleshoten van sql wordt ik echt niet wijs uit.
Het hele SQL gebeuren is nog een soort abracadabra voor mij.
En bij bijna alles wat ik op internet vind wordt weer verwezen naar andere dingen, die weer verwijzen ergens anders heen, enz.

Gewoon een uitleg van, start/installeer dit, monitor dat, wacht zus en doe zo, kan ik niet vinden.

Kan iemand iets meer stap-voor-stap uitleggen wat ik moet doen om die bottleneck te vinden?

Veel verder dan mem/cpu en hdd gebruik monitoren in aida, systeembeheer ed kom ik nog niet echt.
dus disk i/o, blocks, en weet ik wat, heb ik meer hulp/uitleg bij nodig a.u.b.
ps. heb ook librenms draaien waar t een en ander in bijgehouden wordt via snmp v2c

[Jazzy]

Als je de info om de PAL tool te gebruiken niet kunt vinden dan ga je ook niets aan de resultaten hebben. In dat geval doe je er misschien beter aan om gewoon random resources toe te voegen, wie weet dat je er resultaat mee haalt.

Moet wel zeggen dat je wat snel opgeeft. Er is zat documentatie die je door PAL heen leidt, er staan allerlei links op de site waar je de tool gedownload hebt zelfs: https://pal.codeplex.com/

Troubleshooten van performance issues is helaas complex, je moet je er echt even in vast willen bijten als je het goed wilt doen.

[ Voor 41% gewijzigd door Jazzy op 27-05-2016 16:37 ]

[Dennism]

HellStorm666 schreef op vrijdag 27 mei 2016 @ 15:31:
Sorry, maar die links over het troubleshoten van sql wordt ik echt niet wijs uit.
Het hele SQL gebeuren is nog een soort abracadabra voor mij.
En bij bijna alles wat ik op internet vind wordt weer verwezen naar andere dingen, die weer verwijzen ergens anders heen, enz.

Gewoon een uitleg van, start/installeer dit, monitor dat, wacht zus en doe zo, kan ik niet vinden.

Kan iemand iets meer stap-voor-stap uitleggen wat ik moet doen om die bottleneck te vinden?

Veel verder dan mem/cpu en hdd gebruik monitoren in aida, systeembeheer ed kom ik nog niet echt.
dus disk i/o, blocks, en weet ik wat, heb ik meer hulp/uitleg bij nodig a.u.b.
ps. heb ook librenms draaien waar t een en ander in bijgehouden wordt via snmp v2c

Je kan natuurlijk ook externe kennis inhuren als het probleem te complex is voor je om te troubleshooten, maar het bedrijf wel geld kost omdat de performance er niet is, en de gebruikers onnodig tijd kwijt zijn. Wanneer het probleem op dit moment groot genoeg qua financiële impact is zal je die uurtjes consultancy zo terug verdiend hebben.

Of inderdaad resources toevoegen en hopen dat het goed komt. Als ik even kijk wat je mogelijk aan resources kan toevoegen zal een betere controller / wat SSD's en extra geheugen je ook de kop niet kosten verwacht ik.

[ Voor 9% gewijzigd door Dennism op 27-05-2016 19:43 ]

[CMD-Snake]

HellStorm666 schreef op vrijdag 27 mei 2016 @ 13:09:
Mijn Probleem
We hebben hier een SQL server 2005 draaien op een S2008 server.
Deze gebruiken wij voor ProductStream (database pakket voor 3D tekeningen ed)

De database is 2GB groot, de files die er bij horen zijn 476GB en groeiende.

Die database is niet zo woest groot. Die bestanden zijn echter fors te noemen.

Je schrijft dat dit ingericht is door de leverancier in 2010, waarom is er dan gekozen voor SQL Server 2005? Je had dan 2008R2 moeten kiezen. SQL Server 2005 is nu end of life.

Server is een Dell T110
Xeon X3450
2x 4GB DDR3
1x C: WD250ABYS (Windows)
2x E: Hitachi Deskstar 7K2000 (RAID 1 (mirror)) (Database + Files+ Backup)
1x F: WD20EADS (Backup)

Het is natte vinger werk zolang je niet echt gaat trouble shooten. Een ding wat wel in het oog springt is je disk verdeling. Je slaat namelijk alles op dezelfde disk op. Zowel de database, de bestanden en je back-ups. Dat is dus vechten om toegang tot die disk voor alles.

Ik zou die data uit gaan splitsen. Die grote file share kan je echt beter naar zijn eigen disk verplaatsen. Dat lijkt mij ergens een open deur onafhankelijk van wat er uit je analyse van SQL Server komt.

[HellStorm666]

CMD-Snake schreef op zondag 29 mei 2016 @ 10:43:
[...]


Die database is niet zo woest groot. Die bestanden zijn echter fors te noemen.

Je schrijft dat dit ingericht is door de leverancier in 2010, waarom is er dan gekozen voor SQL Server 2005? Je had dan 2008R2 moeten kiezen. SQL Server 2005 is nu end of life.


[...]


Het is natte vinger werk zolang je niet echt gaat trouble shooten. Een ding wat wel in het oog springt is je disk verdeling. Je slaat namelijk alles op dezelfde disk op. Zowel de database, de bestanden en je back-ups. Dat is dus vechten om toegang tot die disk voor alles.

Ik zou die data uit gaan splitsen. Die grote file share kan je echt beter naar zijn eigen disk verplaatsen. Dat lijkt mij ergens een open deur onafhankelijk van wat er uit je analyse van SQL Server komt.

Geen idee waarom ze SQL2005 hebben gekozen.
Ik werkte hier toen ook nog niet.
db, files en backup op dezelfde schijf leek mij ook totaal niet logisch.

Ik zal eens zien of ik meer te weten kan komen over wat er gemonitord moet worden om de exacte problemen te vinden.

Al denk ik, gezien jullie reacties, dat meer ram, 2x SSD voor db en 2x SSD voor data een goede stap zou moeten zijn.

[VHware]

Backup wil je overigens ook niet op dezelfde disks hebben als waar je data op staat... als die stuk gaat is immers alles weg. Plus als het heel belangrijk is voor het bedrijf (wat mij wel lijkt), is het wel handig als er iets van een offsite-backup geregeld wordt waardoor er een kopie van de backup niet in hetzelfde pand aanwezig is als de primaire backup.

[ Voor 25% gewijzigd door VHware op 30-05-2016 09:02 ]

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 09:00:
[...]


Backup wil je overigens ook niet op dezelfde disks hebben als waar je data op staat... als die stuk gaat is immers alles weg. Plus als het heel belangrijk is voor het bedrijf (wat mij wel lijkt), is het wel handig als er iets van een offsite-backup geregeld wordt waardoor er een kopie van de backup niet in hetzelfde pand aanwezig is als de primaire backup.

Was misch handig geweest om te vermelden.
Die WD hdd voor de back-up is een externe schijf die gewisselt wordt.
Elke maandag wisselen we de externe hdd. De ene drive ligt bij collega thuis, de andere hangt aan t systeem.

[VHware]

Ah zo top - Is er verder door het bedrijf een maintenance plan in SQL Server ingesteld? Hierdoor wordt bv de database opgeschoond, eventueel herindexeerd etc. Worden de SQL transaction logs opgeruimd na backup enzo?

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 09:06:
Ah zo top - Is er verder door het bedrijf een maintenance plan in SQL Server ingesteld? Hierdoor wordt bv de database opgeschoond, eventueel herindexeerd etc. Worden de SQL transaction logs opgeruimd na backup enzo?

Het gene dat ik weet is:
elke dag om 0:00 en 12:00 een back-up van de db.
daarin gebeurt: Shrink databases
Reorganize Index
Rebuild Index
Back-up database

En elke zondag om 0:00
Check database integrity

[VHware]

Die shrink databases kan ook wel een reden zijn van trage database. Shrinken zou je alleen moeten doen in uitzonderlijke gevallen.

Zie voor info: http://www.sqlskills.com/...t-shrink-your-data-files/

[VHware]

Eventueel kun je nog hier naar kijken: https://sqlserverperforma...-for-sql-server-20052008/
en https://sqlserverperforma...-right-in-windows-server/

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 09:18:
Die shrink databases kan ook wel een reden zijn van trage database. Shrinken zou je alleen moeten doen in uitzonderlijke gevallen.

Zie voor info: http://www.sqlskills.com/...t-shrink-your-data-files/

Als ik die link goed begrijp moet ik dus de Shrink Database weggooien uit de maintenance plan?
Nu is de config daarvan: Connection: Local server connection
Databases: Specific databases
Shrink database when it grows beyond: 50MB
Amount of free space to remain after shrink: 10%
Return freed space to os.

[VHware]

HellStorm666 schreef op maandag 30 mei 2016 @ 09:47:
[...]

Als ik die link goed begrijp moet ik dus de Shrink Database weggooien uit de maintenance plan?
Nu is de config daarvan: Connection: Local server connection
Databases: Specific databases
Shrink database when it grows beyond: 50MB
Amount of free space to remain after shrink: 10%
Return freed space to os.

Yep inderdaad. Het probleem is dat je database-indexen hiermee gefragmenteerd raken en het lezen ervan veel I/O kost... en je hebt al niet zoveel disk I/O's.

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 09:52:
[...]

Yep inderdaad. Het probleem is dat je database-indexen hiermee gefragmenteerd raken en het lezen ervan veel I/O kost... en je hebt al niet zoveel disk I/O's.

Ok, dan verwijder ik die shrink uit de job (of is disable ook genoeg?).
Is er een manier om de db te defragmenteren?

[pven]

HellStorm666 schreef op maandag 30 mei 2016 @ 08:31:
[...]


Geen idee waarom ze SQL2005 hebben gekozen.

Tip van een pro: kaart dat eens aan. 2005 is al lang niet meer gesupport, als je daar productie op hebt draaien dan speel je Russisch roulette.

(Op de rest ga ik nog reageren, waarschijnlijk vanavond. )

[VHware]

HellStorm666 schreef op maandag 30 mei 2016 @ 09:53:
[...]

Ok, dan verwijder ik die shrink uit de job (of is disable ook genoeg?).
Is er een manier om de db te defragmenteren?

Disable is genoeg.

Dat kan met maintenance taken:

Reorganize Index
Rebuild Index

Deze maintenance taken kunnen dan nu weekly worden, je hebt ze nu waarschijnlijk vaker staan? Deze taken hoeven normaal niet vaak uitgevoerd te worden, alleen wanneer fragmentatie een issue is.

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 10:03:
[...]

Disable is genoeg.

Dat kan met maintenance taken:

Reorganize Index
Rebuild Index

Deze maintenance taken kunnen dan nu weekly worden, je hebt ze nu waarschijnlijk vaker staan? Deze taken hoeven normaal niet vaak uitgevoerd te worden, alleen wanneer fragmentatie een issue is.

thnx

[VHware]

Hoewel offtopic:

In je maintenance plan mis ik Maintenance Plan cleanup task (MSDN: Maintenance Cleanup Task (Maintenance Plan)) en een taak die controleert of je backup goed is. Je kan een database restore doen met ik dacht "verifyOnly" optie.

[HellStorm666]

Ok, we hebben nu het volgende plan.

2x 4GB aan ecc ram er bij (totaal zit dan op 16GB)
1x Sandisk Ultra SSD van 960GB voor de files.
1x SSD voor de Database (waarschijnlijk 40GB oid)

Back-up schedule waarin elk uur een increment back-up wordt gemaakt van zowel de files als de DB.
Deze back-up zal dan naar de 2x 2TB (raid-1) gaan.
1x per week de reorganize en rebuild index
1x per weer een full-backup naar de externe hdd.

[Dennism]

pven schreef op maandag 30 mei 2016 @ 09:56:
[...]

Tip van een pro: kaart dat eens aan. 2005 is al lang niet meer gesupport, als je daar productie op hebt draaien dan speel je Russisch roulette.

(Op de rest ga ik nog reageren, waarschijnlijk vanavond. )

Valt ook wel weer mee, 12 april 2016 is SQL 2005 uit of support gegaan. Zoals ik ook al aanhaalde is het inderdaad een issue dat aangepakt moet worden. Maar spreken van al lang niet meer gesupport en Russische roulette is ook wat snel in dat opzicht. Maar het is uiteraard wel een situatie die op den duur (z.s.m. wanneer mogelijk) wil migreren.

[HellStorm666]

Dennism schreef op maandag 30 mei 2016 @ 10:23:
[...]


Valt ook wel weer mee, 12 april 2016 is SQL 2005 uit of support gegaan. Zoals ik ook al aanhaalde is het inderdaad een issue dat aangepakt moet worden. Maar spreken van al lang niet meer gesupport en Russische roulette is ook wat snel in dat opzicht. Maar het is uiteraard wel een situatie die op den duur (z.s.m. wanneer mogelijk) wil migreren.

Met 1 a 2 jaar gaan wij sowieso over op Autodesk Vault. Daarvoor komt er een compleet nieuwe server met nieuwe db software ed.
Dus heel veel investeren is niet de bedoeling nu.

[pven]

Dennism schreef op maandag 30 mei 2016 @ 10:23:
[...]


Valt ook wel weer mee, 12 april 2016 is SQL 2005 uit of support gegaan. Zoals ik ook al aanhaalde is het inderdaad een issue dat aangepakt moet worden. Maar spreken van al lang niet meer gesupport en Russische roulette is ook wat snel in dat opzicht. Maar het is uiteraard wel een situatie die op den duur (z.s.m. wanneer mogelijk) wil migreren.

Je draait productie op een systeem wat niet gesupport is. Als er dus iets gebeurt, dan krijg je geen ondersteuning. Tsjah, het ligt er natuurlijk aan hoeveel waarde je aan productie-data hecht, maar bij de bedrijven waar ik regelmatig kom is een unsupported versie niet acceptabel.

Maar goed: vanavond meer, dan heb ik tijd om alles door te lezen

[ Voor 4% gewijzigd door pven op 30-05-2016 10:27 ]

[HellStorm666]

pven schreef op maandag 30 mei 2016 @ 10:27:
[...]

Je draait productie op een systeem wat niet gesupport is. Als er dus iets gebeurt, dan krijg je geen ondersteuning. Tsjah, het ligt er natuurlijk aan hoeveel waarde je aan productie-data hecht, maar bij de bedrijven waar ik regelmatig kom is een unsupported versie niet acceptabel.

Support hebben we sowieso van Cadac, die hebben dit geleverd.

[VHware]

HellStorm666 schreef op maandag 30 mei 2016 @ 10:16:
1x SSD voor de Database (waarschijnlijk 40GB oid)

Je zou voor bv pricewatch: Crucial BX200 240GB kunnen gaan. Deze heeft in elk geval stroomverliesbescherming.

[Dennism]

HellStorm666 schreef op maandag 30 mei 2016 @ 10:16:
Ok, we hebben nu het volgende plan.

2x 4GB aan ecc ram er bij (totaal zit dan op 16GB)
1x Sandisk Ultra SSD van 960GB voor de files.
1x SSD voor de Database (waarschijnlijk 40GB oid)

Back-up schedule waarin elk uur een increment back-up wordt gemaakt van zowel de files als de DB.
Deze back-up zal dan naar de 2x 2TB (raid-1) gaan.
1x per week de reorganize en rebuild index
1x per weer een full-backup naar de externe hdd.

Check wel even of de gekozen SSD's een vorm van power loss protection hebben. Wanneer je geen controller hebt met BBWC of FBWC en dus de cache op de SSD's als write cache gaat gebruiken is dat imho op een productie server wel een must om te hebben.

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 10:28:
[...]


Je zou voor bv pricewatch: Crucial BX200 240GB kunnen gaan. Deze heeft in elk geval stroomverliesbescherming.

Hoe belangrijk is die stroomverlies bescherming?
Het systeem hangt natuurlijk ook gewoon achter een UPS en wordt dus netjes afgesloten als de stroom uitvalt.

[VHware]

HellStorm666 schreef op maandag 30 mei 2016 @ 10:29:
[...]

Hoe belangrijk is die stroomverlies bescherming?
Het systeem hangt natuurlijk ook gewoon achter een UPS en wordt dus netjes afgesloten als de stroom uitvalt.

Een onverwachte reboot is bv ook "stroomverlies" waarbij datacorruptie kan optreden als een SSD dat niet heeft. Daar beschermd een UPS niet tegen. Het gaat er voornamelijk om dat de inhoud van de cache op de SSD netjes wordt weggeschreven naar de flash.

[ Voor 11% gewijzigd door VHware op 30-05-2016 10:33 ]

[Dennism]

pven schreef op maandag 30 mei 2016 @ 10:27:
[...]

Je draait productie op een systeem wat niet gesupport is. Als er dus iets gebeurt, dan krijg je geen ondersteuning. Tsjah, het ligt er natuurlijk aan hoeveel waarde je aan productie-data hecht, maar bij de bedrijven waar ik regelmatig kom is een unsupported versie niet acceptabel.

Maar goed: vanavond meer, dan heb ik tijd om alles door te lezen

Heb je uiteraard gelijk in, maar jouw post deed voorkomen dat de software al tijden uit support was, we praten over een periode van net 6 weken. Dat het beter gepland had kunnen worden, ook zeker met je eens en bij een boel relaties van mij is unsupported ook niet acceptabel, maar ik heb ook relaties die er helaas maar weinig om geven en unsupported als risico incalculeren, ook omdat ze nooit gebruik zullen maken van MS support, maar dit door andere partijen laten doen.

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 10:28:
[...]


Je zou voor bv pricewatch: Crucial BX200 240GB kunnen gaan. Deze heeft in elk geval stroomverliesbescherming.

De Cruxial MX200 is dan interesanter denk ik. die heeft een TBW van 320TB ipv 72TB.
Maar thnx voor deze info. Weet nu iig dat stroomverliesbescherming belangrijk is

[VHware]

HellStorm666 schreef op maandag 30 mei 2016 @ 10:37:
[...]

De Cruxial MX200 is dan interesanter denk ik. die heeft een TBW van 320TB ipv 72TB.
Maar thnx voor deze info. Weet nu iig dat stroomverliesbescherming belangrijk is

MX200 is beter ja, maar gezien je net zei dat je binnenkort de server ging vervangen had ik niet het idee dat de TBW zo belangrijk was

[HellStorm666]

VHware schreef op maandag 30 mei 2016 @ 10:40:
[...]

MX200 is beter ja, maar gezien je net zei dat je binnenkort de server ging vervangen had ik niet het idee dat de TBW zo belangrijk was

zo'n SSD kan altijd hergebruikt worden in testomgevingen ed

[redfoxert]

MX200 heeft ook een betere performance als de queuedepth hoger wordt.

[eheijnen]

Voordat je gaat upgraden kun je nog eens naar het volgende kijken:

Kijk eens met performance monitor naar de Disk Queue. Als daar een waarde optreed van 2 of hoger dan krijgt het systeem meer IO te verwerken dan je disk-subsystem aankan. Dit kun je gewoon doen terwijl het systeem in bedrijf is. Is die lager dan 2 en je systeem nog steeds traag dan zou ik eerder tippen dat er iets met HD-controller aan de hand is (aparate controller of onboard op het mobo).

Als je voor nieuwe SDD schijven kiest ga dan voor enterprise-grade producten en niet voor budget consumenten hardware.

[VHware]

eheijnen schreef op maandag 30 mei 2016 @ 10:48:
Als je voor nieuwe SDD schijven kiest ga dan voor enterprise-grade producten en niet voor budget consumenten hardware.

HellStorm666 schreef op maandag 30 mei 2016 @ 10:26:
[...]

Met 1 a 2 jaar gaan wij sowieso over op Autodesk Vault. Daarvoor komt er een compleet nieuwe server met nieuwe db software ed.
Dus heel veel investeren is niet de bedoeling nu.

[eheijnen]

VHware schreef op maandag 30 mei 2016 @ 10:55:
[...]


[...]

Daar wil ik aan toevoegen dat je die schijven mee kunt nemen naar de nieuwe server..

[Trommelrem]

Een dringend advies: Blijf weg van consumenten SSD's.

Consumer grade HDD's hebben betere performance dan consumer grade SSD's op serverhardware. Neem alleen SSD's die op de HCL staan van Dell. Alleen dan merk je een performancewinst.

Ik heb meerdere omgevingen overgenomen waarbij de vorige beheerder dacht slim te zijn om consumergrade SSD's te gebruiken om servers een performanceboost te geven, alleen werd die belofte nooit waargemaakt. SSD's van de HCL was dan de enige oplossing.

Met de bovenstaande oplossingen met consumer grade SSD's ga je juist een performancehit van Bijbelse proporties meemaken.

[ Voor 11% gewijzigd door Trommelrem op 30-05-2016 11:16 ]

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 10:48:
Voordat je gaat upgraden kun je nog eens naar het volgende kijken:

Kijk eens met performance monitor naar de Disk Queue. Als daar een waarde optreed van 2 of hoger dan krijgt het systeem meer IO te verwerken dan je disk-subsystem aankan. Dit kun je gewoon doen terwijl het systeem in bedrijf is. Is die lager dan 2 en je systeem nog steeds traag dan zou ik eerder tippen dat er iets met HD-controller aan de hand is (aparate controller of onboard op het mobo).

Als je voor nieuwe SDD schijven kiest ga dan voor enterprise-grade producten en niet voor budget consumenten hardware.

Van zowel Logical Disk als Physical Disk even staan loggen.
Current Disk Queue Length van Logical disk is max 1,000 (tijdens t testen dus door het programma gebladerd en uiteraard weer flink traag)
Current Disk Queue Length van PhysicalDisk 1 = 0 en van disk 2 = max 1,000

Tijdens een speed-test van de database (20GB schijven/lezen 25%/75% met 8k bloks) zorgt wel voor de volgende resultaten:
Avg DQL Logical = 41,091 max en 4,027 avg
Cur DQL Logical = 35,000 max en 4,006 avg
Avg DQL PD1 = 25,073 max en 2,599 avg
Avg DQL PD2 = 22,838 max en 2,492 avg

commando was: diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat
en resultaat is 2,31 MB/s lezen met 296 IO per s
en 0,77 MB/s schrijven met 98 IO per s
50% was 73ms of korter
90% was 224 ms of korter
99% was 547ms of korter

Ook CrystalDiskMark ff gedraait (5.1.2 x64)
2, 4gib op de data/db schijf.
DQL Logical = 35,000 max (ongeveer)
DQL PD1/PD2 = 34,000/32,000 max

	Read MB/s	Write MB/s
Seq Q32T1	101,7	92,28
4k Q32T1	1,330	0,827
Seq	89,55	86,82
4k	0,443	0,799

[eheijnen]

HellStorm666 schreef op maandag 30 mei 2016 @ 11:38:
[...]

Van zowel Logical Disk als Physical Disk even staan loggen.
Current Disk Queue Length van Logical disk is max 1,000 (tijdens t testen dus door het programma gebladerd en uiteraard weer flink traag)
Current Disk Queue Length van PhysicalDisk 1 = 0 en van disk 2 = max 1,000

Tijdens een speed-test van de database (20GB schijven/lezen 25%/75% met 8k bloks) zorgt wel voor de volgende resultaten:
Avg DQL Logical = 41,091 max en 4,027 avg
Cur DQL Logical = 35,000 max en 4,006 avg
Avg DQL PD1 = 25,073 max en 2,599 avg
Avg DQL PD2 = 22,838 max en 2,492 avg

commando was: diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat
en resultaat is 2,31 MB/s lezen met 296 IO per s
en 0,77 MB/s schrijven met 98 IO per s
50% was 73ms of korter
90% was 224 ms of korter
99% was 547ms of korter

Ook CrystalDiskMark ff gedraait (5.1.2 x64)
2, 4gib op de data/db schijf.
DQL Logical = 35,000 max (ongeveer)
DQL PD1/PD2 = 34,000/32,000 max

	Read MB/s	Write MB/s
Seq Q32T1	101,7	92,28
4k Q32T1	1,330	0,827
Seq	89,55	86,82
4k	0,443	0,799

Kun je nog eens een test doen met een block-size van respectievelijk:
16, 32, 64 en 128K

Kijken of dan de doorvoer omhoog gaat.

[Dennism]

Trommelrem schreef op maandag 30 mei 2016 @ 11:14:
Een dringend advies: Blijf weg van consumenten SSD's.

Consumer grade HDD's hebben betere performance dan consumer grade SSD's op serverhardware. Neem alleen SSD's die op de HCL staan van Dell. Alleen dan merk je een performancewinst.

Ik heb meerdere omgevingen overgenomen waarbij de vorige beheerder dacht slim te zijn om consumergrade SSD's te gebruiken om servers een performanceboost te geven, alleen werd die belofte nooit waargemaakt. SSD's van de HCL was dan de enige oplossing.

Met de bovenstaande oplossingen met consumer grade SSD's ga je juist een performancehit van Bijbelse proporties meemaken.

De ene server is natuurlijk de andere niet.

Dit heeft ook vaak te maken met de gebruikte controllers. In mijn ervaring werken budget servers van o.a. HP en Dell vaak prima met consumer grade SSDs. Gebruik je echter de hogere modellen van deze partijen dan komen deze vaak met een controller die wanneer ze geen schijven detecteren met firmware van de fabrikant soms zeer vreemde dingen laat zien qua performance.

zo werkt uit ervaring bijv. een HP Microserver of een DL120 prima met bijv. Samsung Pro / Intel of Crucial SSD's, terwijl een DL360/380 of hoger met P440AR of hogere controller flink selectiever is qua goed werkende schijven.

[Jazzy]

HellStorm666 schreef op maandag 30 mei 2016 @ 11:38:
[...]

Van zowel Logical Disk als Physical Disk even staan loggen.
Current Disk Queue Length van Logical disk is max 1,000 (tijdens t testen dus door het programma gebladerd en uiteraard weer flink traag)
Current Disk Queue Length van PhysicalDisk 1 = 0 en van disk 2 = max 1,000

Is het echt 1000 wat je gemeten hebt? Want dat is wel extreem hoog en een verdacht rond getal. Kijk even naar Avg. Disk Queue Length in plaats van Current. Die zou onder de vijf moeten zijn.

[ Voor 8% gewijzigd door Jazzy op 30-05-2016 11:55 ]

[HellStorm666]

Jazzy schreef op maandag 30 mei 2016 @ 11:54:
[...]
Is het echt 1000 wat je gemeten hebt? Want dat is wel extreem hoog en een verdacht rond getal.

ik denk dat t 1 komma 000 is, dus 1,000 maar dan amerikaanse notatie dus 1.000

[Jazzy]

Dan is het nog een hele rare waarde, waarom zou die pieken tot exact 1000?

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 11:41:
[...]


Kun je nog eens een test doen met een block-size van respectievelijk:
16, 32, 64 en 128K

Kijken of dan de doorvoer omhoog gaat.

Hier de resultaten:

8k

code:

Command Line: diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'E:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 8192
        using random I/O (alignment: 8192)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   1.68%|   0.72%|    0.96%|  98.32%
   1|   9.52%|   0.65%|    8.87%|  90.48%
   2|   3.41%|   1.27%|    2.13%|  96.59%
   3|   0.68%|   0.14%|    0.53%|  99.32%
   4|   1.22%|   0.59%|    0.64%|  98.78%
   5|   0.16%|   0.00%|    0.16%|  99.84%
   6|   1.66%|   0.86%|    0.81%|  98.33%
   7|   0.23%|   0.01%|    0.22%|  99.76%
-------------------------------------------
avg.|   2.32%|   0.53%|    1.79%|  97.68%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        47783936 |         5833 |       0.38 |      48.61 |   82.319 |   112.910 | E:\iotest.dat (20GB)
     1 |        48144384 |         5877 |       0.38 |      48.98 |   81.643 |   127.940 | E:\iotest.dat (20GB)
     2 |        50446336 |         6158 |       0.40 |      51.32 |   77.934 |   102.025 | E:\iotest.dat (20GB)
     3 |        47783936 |         5833 |       0.38 |      48.61 |   82.230 |   127.582 | E:\iotest.dat (20GB)
     4 |        48324608 |         5899 |       0.38 |      49.16 |   81.272 |   123.577 | E:\iotest.dat (20GB)
     5 |        47882240 |         5845 |       0.38 |      48.71 |   82.111 |   149.027 | E:\iotest.dat (20GB)
     6 |        50028544 |         6107 |       0.40 |      50.89 |   78.701 |   106.377 | E:\iotest.dat (20GB)
     7 |        47611904 |         5812 |       0.38 |      48.43 |   82.532 |   132.173 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         388005888 |        47364 |       3.08 |     394.70 |   81.058 |   123.318

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        36069376 |         4403 |       0.29 |      36.69 |  107.663 |   119.404 | E:\iotest.dat (20GB)
     1 |        36241408 |         4424 |       0.29 |      36.87 |  107.033 |   138.310 | E:\iotest.dat (20GB)
     2 |        37879808 |         4624 |       0.30 |      38.53 |  102.373 |   107.035 | E:\iotest.dat (20GB)
     3 |        35577856 |         4343 |       0.28 |      36.19 |  108.898 |   138.082 | E:\iotest.dat (20GB)
     4 |        35971072 |         4391 |       0.29 |      36.59 |  107.693 |   133.346 | E:\iotest.dat (20GB)
     5 |        36036608 |         4399 |       0.29 |      36.66 |  107.599 |   163.893 | E:\iotest.dat (20GB)
     6 |        37699584 |         4602 |       0.30 |      38.35 |  102.921 |   112.297 | E:\iotest.dat (20GB)
     7 |        35520512 |         4336 |       0.28 |      36.13 |  109.100 |   143.592 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         290996224 |        35522 |       2.31 |     296.02 |  106.604 |   132.865

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        11714560 |         1430 |       0.09 |      11.92 |    4.284 |     6.043 | E:\iotest.dat (20GB)
     1 |        11902976 |         1453 |       0.09 |      12.11 |    4.339 |     4.810 | E:\iotest.dat (20GB)
     2 |        12566528 |         1534 |       0.10 |      12.78 |    4.269 |     5.026 | E:\iotest.dat (20GB)
     3 |        12206080 |         1490 |       0.10 |      12.42 |    4.499 |     5.635 | E:\iotest.dat (20GB)
     4 |        12353536 |         1508 |       0.10 |      12.57 |    4.338 |     3.346 | E:\iotest.dat (20GB)
     5 |        11845632 |         1446 |       0.09 |      12.05 |    4.570 |     8.278 | E:\iotest.dat (20GB)
     6 |        12328960 |         1505 |       0.10 |      12.54 |    4.642 |     8.909 | E:\iotest.dat (20GB)
     7 |        12091392 |         1476 |       0.10 |      12.30 |    4.486 |     7.402 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:          97009664 |        11842 |       0.77 |      98.68 |    4.428 |     6.422


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.546 |      0.386 |      0.386
   25th |     34.906 |      2.448 |     10.598
   50th |     73.222 |      3.944 |     46.379
   75th |    133.781 |      5.004 |    108.060
   90th |    224.598 |      8.322 |    195.187
   95th |    302.702 |     10.602 |    268.761
   99th |    547.125 |     12.552 |    489.846
3-nines |   1506.885 |     92.291 |   1319.630
4-nines |   2777.212 |    269.664 |   2578.633
5-nines |   7215.333 |    298.370 |   7215.333
6-nines |   7215.333 |    298.370 |   7215.333
7-nines |   7215.333 |    298.370 |   7215.333
8-nines |   7215.333 |    298.370 |   7215.333
9-nines |   7215.333 |    298.370 |   7215.333
    max |   7215.333 |    298.370 |   7215.333

16K

code:

Command Line: diskspd -b16K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'E:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 16384
        using random I/O (alignment: 16384)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   1.38%|   0.82%|    0.56%|  98.62%
   1|   8.66%|   0.78%|    7.88%|  91.34%
   2|   3.19%|   1.37%|    1.82%|  96.81%
   3|   0.81%|   0.33%|    0.48%|  99.19%
   4|   1.66%|   1.11%|    0.56%|  98.33%
   5|   0.34%|   0.12%|    0.22%|  99.66%
   6|   1.55%|   0.91%|    0.64%|  98.45%
   7|   0.26%|   0.12%|    0.14%|  99.74%
-------------------------------------------
avg.|   2.23%|   0.69%|    1.54%|  97.77%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        94978048 |         5797 |       0.75 |      48.31 |   82.783 |   131.111 | E:\iotest.dat (20GB)
     1 |        94240768 |         5752 |       0.75 |      47.93 |   83.421 |   128.937 | E:\iotest.dat (20GB)
     2 |        93978624 |         5736 |       0.75 |      47.80 |   83.770 |   136.221 | E:\iotest.dat (20GB)
     3 |        96157696 |         5869 |       0.76 |      48.91 |   81.825 |   132.627 | E:\iotest.dat (20GB)
     4 |        96124928 |         5867 |       0.76 |      48.89 |   81.876 |   119.148 | E:\iotest.dat (20GB)
     5 |        96714752 |         5903 |       0.77 |      49.19 |   81.264 |   126.421 | E:\iotest.dat (20GB)
     6 |        95993856 |         5859 |       0.76 |      48.83 |   82.032 |   131.175 | E:\iotest.dat (20GB)
     7 |        93782016 |         5724 |       0.75 |      47.70 |   83.849 |   128.205 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         761970688 |        46507 |       6.06 |     387.56 |   82.592 |   129.300

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        71712768 |         4377 |       0.57 |      36.48 |  108.073 |   141.795 | E:\iotest.dat (20GB)
     1 |        71041024 |         4336 |       0.56 |      36.13 |  109.210 |   139.059 | E:\iotest.dat (20GB)
     2 |        70516736 |         4304 |       0.56 |      35.87 |  110.064 |   148.085 | E:\iotest.dat (20GB)
     3 |        71581696 |         4369 |       0.57 |      36.41 |  108.337 |   144.452 | E:\iotest.dat (20GB)
     4 |        71450624 |         4361 |       0.57 |      36.34 |  108.618 |   127.659 | E:\iotest.dat (20GB)
     5 |        72876032 |         4448 |       0.58 |      37.07 |  106.383 |   136.521 | E:\iotest.dat (20GB)
     6 |        72384512 |         4418 |       0.58 |      36.82 |  107.316 |   142.177 | E:\iotest.dat (20GB)
     7 |        70041600 |         4275 |       0.56 |      35.63 |  110.715 |   138.325 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         571604992 |        34888 |       4.54 |     290.74 |  108.573 |   139.870

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        23265280 |         1420 |       0.18 |      11.83 |    4.829 |    12.414 | E:\iotest.dat (20GB)
     1 |        23199744 |         1416 |       0.18 |      11.80 |    4.451 |     6.749 | E:\iotest.dat (20GB)
     2 |        23461888 |         1432 |       0.19 |      11.93 |    4.740 |     9.707 | E:\iotest.dat (20GB)
     3 |        24576000 |         1500 |       0.20 |      12.50 |    4.606 |     6.122 | E:\iotest.dat (20GB)
     4 |        24674304 |         1506 |       0.20 |      12.55 |    4.437 |     6.792 | E:\iotest.dat (20GB)
     5 |        23838720 |         1455 |       0.19 |      12.13 |    4.474 |     6.198 | E:\iotest.dat (20GB)
     6 |        23609344 |         1441 |       0.19 |      12.01 |    4.513 |     4.064 | E:\iotest.dat (20GB)
     7 |        23740416 |         1449 |       0.19 |      12.08 |    4.586 |     8.153 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         190365696 |        11619 |       1.51 |      96.83 |    4.578 |     7.873


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.731 |      0.460 |      0.460
   25th |     34.051 |      2.401 |     10.655
   50th |     72.383 |      4.017 |     45.726
   75th |    135.302 |      5.047 |    108.176
   90th |    231.973 |      8.574 |    201.081
   95th |    315.079 |     10.800 |    278.943
   99th |    567.632 |     13.293 |    511.198
3-nines |   1689.000 |    116.734 |   1504.913
4-nines |   3367.243 |    289.766 |   3261.381
5-nines |   3612.666 |    303.903 |   3612.666
6-nines |   3612.666 |    303.903 |   3612.666
7-nines |   3612.666 |    303.903 |   3612.666
8-nines |   3612.666 |    303.903 |   3612.666
9-nines |   3612.666 |    303.903 |   3612.666
    max |   3612.666 |    303.903 |   3612.666

32k

code:

Command Line: diskspd -b32K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'E:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 32768
        using random I/O (alignment: 32768)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   1.66%|   1.01%|    0.65%|  98.33%
   1|   8.78%|   0.86%|    7.92%|  91.22%
   2|   3.58%|   1.92%|    1.65%|  96.42%
   3|   0.82%|   0.49%|    0.33%|  99.18%
   4|   1.39%|   0.95%|    0.44%|  98.61%
   5|   0.49%|   0.42%|    0.08%|  99.50%
   6|   1.76%|   1.24%|    0.52%|  98.24%
   7|   0.49%|   0.40%|    0.09%|  99.50%
-------------------------------------------
avg.|   2.37%|   0.91%|    1.46%|  97.63%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       185204736 |         5652 |       1.47 |      47.10 |   85.174 |   138.187 | E:\iotest.dat (20GB)
     1 |       180322304 |         5503 |       1.43 |      45.86 |   87.232 |   139.194 | E:\iotest.dat (20GB)
     2 |       169771008 |         5181 |       1.35 |      43.18 |   92.618 |   178.283 | E:\iotest.dat (20GB)
     3 |       180682752 |         5514 |       1.44 |      45.95 |   86.847 |   143.309 | E:\iotest.dat (20GB)
     4 |       174718976 |         5332 |       1.39 |      44.43 |   90.041 |   157.525 | E:\iotest.dat (20GB)
     5 |       186122240 |         5680 |       1.48 |      47.33 |   84.536 |   126.241 | E:\iotest.dat (20GB)
     6 |       181239808 |         5531 |       1.44 |      46.09 |   86.546 |   146.171 | E:\iotest.dat (20GB)
     7 |       178814976 |         5457 |       1.42 |      45.48 |   87.922 |   161.249 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        1436876800 |        43850 |      11.42 |     365.42 |   87.546 |   149.161

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       139984896 |         4272 |       1.11 |      35.60 |  111.044 |   149.963 | E:\iotest.dat (20GB)
     1 |       135921664 |         4148 |       1.08 |      34.57 |  114.066 |   150.818 | E:\iotest.dat (20GB)
     2 |       127500288 |         3891 |       1.01 |      32.43 |  121.647 |   197.240 | E:\iotest.dat (20GB)
     3 |       134348800 |         4100 |       1.07 |      34.17 |  115.062 |   156.506 | E:\iotest.dat (20GB)
     4 |       129761280 |         3960 |       1.03 |      33.00 |  119.467 |   173.266 | E:\iotest.dat (20GB)
     5 |       140378112 |         4284 |       1.12 |      35.70 |  110.543 |   135.527 | E:\iotest.dat (20GB)
     6 |       136085504 |         4153 |       1.08 |      34.61 |  113.589 |   159.652 | E:\iotest.dat (20GB)
     7 |       133562368 |         4076 |       1.06 |      33.97 |  115.893 |   177.948 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        1077542912 |        32884 |       8.56 |     274.03 |  115.052 |   163.134

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        45219840 |         1380 |       0.36 |      11.50 |    5.092 |    10.305 | E:\iotest.dat (20GB)
     1 |        44400640 |         1355 |       0.35 |      11.29 |    5.087 |    10.159 | E:\iotest.dat (20GB)
     2 |        42270720 |         1290 |       0.34 |      10.75 |    5.060 |    10.214 | E:\iotest.dat (20GB)
     3 |        46333952 |         1414 |       0.37 |      11.78 |    5.036 |     7.997 | E:\iotest.dat (20GB)
     4 |        44957696 |         1372 |       0.36 |      11.43 |    5.110 |     8.515 | E:\iotest.dat (20GB)
     5 |        45744128 |         1396 |       0.36 |      11.63 |    4.724 |     5.629 | E:\iotest.dat (20GB)
     6 |        45154304 |         1378 |       0.36 |      11.48 |    5.046 |     9.698 | E:\iotest.dat (20GB)
     7 |        45252608 |         1381 |       0.36 |      11.51 |    5.365 |    12.610 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         359333888 |        10966 |       2.86 |      91.38 |    5.064 |     9.571


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.790 |      0.408 |      0.408
   25th |     33.012 |      2.531 |     10.848
   50th |     71.639 |      4.335 |     44.328
   75th |    136.543 |      5.327 |    108.831
   90th |    249.678 |      8.873 |    213.213
   95th |    356.967 |     11.029 |    309.594
   99th |    677.047 |     15.361 |    602.518
3-nines |   1844.065 |    191.517 |   1696.345
4-nines |   4034.251 |    240.411 |   3778.094
5-nines |   6153.809 |    240.972 |   6153.809
6-nines |   6153.809 |    240.972 |   6153.809
7-nines |   6153.809 |    240.972 |   6153.809
8-nines |   6153.809 |    240.972 |   6153.809
9-nines |   6153.809 |    240.972 |   6153.809
    max |   6153.809 |    240.972 |   6153.809

64k

code:

Command Line: diskspd -b64K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'E:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 65536
        using random I/O (alignment: 65536)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   1.66%|   0.81%|    0.86%|  98.33%
   1|   7.89%|   0.65%|    7.24%|  92.11%
   2|   2.82%|   1.18%|    1.64%|  97.18%
   3|   0.69%|   0.23%|    0.46%|  99.31%
   4|   0.95%|   0.51%|    0.44%|  99.05%
   5|   0.30%|   0.14%|    0.16%|  99.70%
   6|   1.04%|   0.56%|    0.48%|  98.96%
   7|   0.35%|   0.13%|    0.22%|  99.65%
-------------------------------------------
avg.|   1.96%|   0.53%|    1.44%|  98.03%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       319619072 |         4877 |       2.54 |      40.64 |   98.588 |   144.018 | E:\iotest.dat (20GB)
     1 |       310378496 |         4736 |       2.47 |      39.47 |  101.503 |   164.104 | E:\iotest.dat (20GB)
     2 |       318111744 |         4854 |       2.53 |      40.45 |   98.842 |   155.918 | E:\iotest.dat (20GB)
     3 |       324861952 |         4957 |       2.58 |      41.31 |   96.705 |   144.024 | E:\iotest.dat (20GB)
     4 |       329515008 |         5028 |       2.62 |      41.90 |   95.481 |   144.500 | E:\iotest.dat (20GB)
     5 |       338952192 |         5172 |       2.69 |      43.10 |   92.754 |   132.167 | E:\iotest.dat (20GB)
     6 |       311558144 |         4754 |       2.48 |      39.62 |  101.019 |   182.859 | E:\iotest.dat (20GB)
     7 |       315686912 |         4817 |       2.51 |      40.14 |   99.812 |   146.890 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        2568683520 |        39195 |      20.41 |     326.63 |   98.010 |   152.209

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       241762304 |         3689 |       1.92 |      30.74 |  126.861 |   154.573 | E:\iotest.dat (20GB)
     1 |       235012096 |         3586 |       1.87 |      29.88 |  130.470 |   178.425 | E:\iotest.dat (20GB)
     2 |       238485504 |         3639 |       1.90 |      30.33 |  128.470 |   169.309 | E:\iotest.dat (20GB)
     3 |       241172480 |         3680 |       1.92 |      30.67 |  126.359 |   155.403 | E:\iotest.dat (20GB)
     4 |       244383744 |         3729 |       1.94 |      31.08 |  125.028 |   156.453 | E:\iotest.dat (20GB)
     5 |       256507904 |         3914 |       2.04 |      32.62 |  119.360 |   141.305 | E:\iotest.dat (20GB)
     6 |       233635840 |         3565 |       1.86 |      29.71 |  130.849 |   201.766 | E:\iotest.dat (20GB)
     7 |       235929600 |         3600 |       1.88 |      30.00 |  130.270 |   158.243 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        1926889472 |        29402 |      15.31 |     245.02 |  127.107 |   165.011

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |        77856768 |         1188 |       0.62 |       9.90 |   10.795 |    27.652 | E:\iotest.dat (20GB)
     1 |        75366400 |         1150 |       0.60 |       9.58 |   11.176 |    29.306 | E:\iotest.dat (20GB)
     2 |        79626240 |         1215 |       0.63 |      10.13 |   10.103 |    27.622 | E:\iotest.dat (20GB)
     3 |        83689472 |         1277 |       0.67 |      10.64 |   11.251 |    32.987 | E:\iotest.dat (20GB)
     4 |        85131264 |         1299 |       0.68 |      10.83 |   10.659 |    29.191 | E:\iotest.dat (20GB)
     5 |        82444288 |         1258 |       0.66 |      10.48 |    9.975 |    25.276 | E:\iotest.dat (20GB)
     6 |        77922304 |         1189 |       0.62 |       9.91 |   11.577 |    31.065 | E:\iotest.dat (20GB)
     7 |        79757312 |         1217 |       0.63 |      10.14 |    9.715 |    21.635 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:         641794048 |         9793 |       5.10 |      81.61 |   10.651 |    28.302


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.712 |      0.598 |      0.598
   25th |     35.438 |      2.961 |     12.886
   50th |     79.401 |      4.907 |     50.416
   75th |    152.438 |      6.278 |    122.478
   90th |    277.827 |     11.955 |    234.567
   95th |    408.404 |     50.116 |    355.293
   99th |    785.196 |    124.458 |    713.327
3-nines |   1571.028 |    460.669 |   1451.003
4-nines |   3626.729 |    518.092 |   2788.575
5-nines |   5611.875 |    518.092 |   5611.875
6-nines |   5611.875 |    518.092 |   5611.875
7-nines |   5611.875 |    518.092 |   5611.875
8-nines |   5611.875 |    518.092 |   5611.875
9-nines |   5611.875 |    518.092 |   5611.875
    max |   5611.875 |    518.092 |   5611.875

128k

code:

Command Line: diskspd -b128K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G E:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'E:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 131072
        using random I/O (alignment: 131072)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   1.92%|   1.20%|    0.73%|  98.09%
   1|   9.84%|   3.65%|    6.19%|  90.17%
   2|   8.18%|   6.29%|    1.89%|  91.83%
   3|   3.39%|   2.83%|    0.56%|  96.62%
   4|   7.25%|   6.29%|    0.96%|  92.76%
   5|  11.10%|  10.69%|    0.42%|  88.91%
   6|   8.27%|   7.55%|    0.72%|  91.74%
   7|   1.56%|   1.20%|    0.36%|  98.45%
-------------------------------------------
avg.|   6.44%|   4.96%|    1.48%|  93.57%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       498204672 |         3801 |       3.96 |      31.68 |  126.175 |   128.302 | E:\iotest.dat (20GB)
     1 |       509083648 |         3884 |       4.05 |      32.37 |  123.549 |   126.695 | E:\iotest.dat (20GB)
     2 |       505282560 |         3855 |       4.02 |      32.13 |  124.624 |   130.684 | E:\iotest.dat (20GB)
     3 |       520617984 |         3972 |       4.14 |      33.10 |  120.796 |   128.539 | E:\iotest.dat (20GB)
     4 |       512098304 |         3907 |       4.07 |      32.56 |  122.815 |   129.967 | E:\iotest.dat (20GB)
     5 |       497549312 |         3796 |       3.95 |      31.63 |  126.441 |   126.449 | E:\iotest.dat (20GB)
     6 |       501743616 |         3828 |       3.99 |      31.90 |  125.352 |   127.246 | E:\iotest.dat (20GB)
     7 |       525598720 |         4010 |       4.18 |      33.42 |  119.666 |   126.442 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        4070178816 |        31053 |      32.35 |     258.78 |  123.634 |   128.070

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       375259136 |         2863 |       2.98 |      23.86 |  147.358 |   133.179 | E:\iotest.dat (20GB)
     1 |       384040960 |         2930 |       3.05 |      24.42 |  142.444 |   133.381 | E:\iotest.dat (20GB)
     2 |       380502016 |         2903 |       3.02 |      24.19 |  144.862 |   137.769 | E:\iotest.dat (20GB)
     3 |       385744896 |         2943 |       3.07 |      24.53 |  140.327 |   135.925 | E:\iotest.dat (20GB)
     4 |       379322368 |         2894 |       3.01 |      24.12 |  143.260 |   137.417 | E:\iotest.dat (20GB)
     5 |       379060224 |         2892 |       3.01 |      24.10 |  145.325 |   131.935 | E:\iotest.dat (20GB)
     6 |       372244480 |         2840 |       2.96 |      23.67 |  144.235 |   132.818 | E:\iotest.dat (20GB)
     7 |       392691712 |         2996 |       3.12 |      24.97 |  138.783 |   133.176 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        3048865792 |        23261 |      24.23 |     193.84 |  143.290 |   134.494

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       122945536 |          938 |       0.98 |       7.82 |   61.518 |    83.783 | E:\iotest.dat (20GB)
     1 |       125042688 |          954 |       0.99 |       7.95 |   65.515 |    79.035 | E:\iotest.dat (20GB)
     2 |       124780544 |          952 |       0.99 |       7.93 |   62.911 |    78.875 | E:\iotest.dat (20GB)
     3 |       134873088 |         1029 |       1.07 |       8.58 |   64.937 |    82.004 | E:\iotest.dat (20GB)
     4 |       132775936 |         1013 |       1.06 |       8.44 |   64.404 |    81.204 | E:\iotest.dat (20GB)
     5 |       118489088 |          904 |       0.94 |       7.53 |   66.028 |    81.636 | E:\iotest.dat (20GB)
     6 |       129499136 |          988 |       1.03 |       8.23 |   71.073 |    89.752 | E:\iotest.dat (20GB)
     7 |       132907008 |         1014 |       1.06 |       8.45 |   63.180 |    80.944 | E:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        1021313024 |         7792 |       8.12 |      64.93 |   64.955 |    82.278


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.920 |      0.822 |      0.822
   25th |     47.974 |      5.471 |     32.752
   50th |    102.830 |     21.370 |     85.726
   75th |    193.205 |    102.857 |    172.400
   90th |    315.672 |    191.297 |    286.509
   95th |    408.599 |    244.090 |    369.211
   99th |    630.630 |    333.306 |    591.031
3-nines |    947.986 |    467.783 |    915.828
4-nines |   1469.781 |    497.268 |   1442.101
5-nines |   2179.279 |    497.268 |   2179.279
6-nines |   2179.279 |    497.268 |   2179.279
7-nines |   2179.279 |    497.268 |   2179.279
8-nines |   2179.279 |    497.268 |   2179.279
9-nines |   2179.279 |    497.268 |   2179.279
    max |   2179.279 |    497.268 |   2179.279

[eheijnen]

Zoals je kunt zien gaat met de "block-size" ook de performance omhoog.

De snelheden die Crystaldisk aangeeft zijn standaard snelheden voor zo'n 7200 RPM schijf. Dat is dan wel met door het programma gegenereerde test data. En niet de bestaande inhoud van het file-system.

Ga je met die benchmark-tool aan het werk dan zal die zonder meer, zoals je kunt zien, je Queue verzadigen.
De Diskqueue-waarden die je in normaal bedrijf hebt zijn verder redelijk.

- De HD's in die server worden die ook regelmatig gedefragenteerd ?
- Draai in een console eens een DEFRAG /A X: van de DB drive

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 12:12:
Zoals je kunt zien gaat met de "block-size" ook de performance omhoog.

De snelheden die Crystaldisk aangeeft zijn standaard snelheden voor zo'n 7200 RPM schijf. Dat is dan wel met door het programma gegenereerde test data. En niet de bestaande inhoud van het file-system.

Ga je met die benchmark-tool aan het werk dan zal die zonder meer, zoals je kunt zien, je Queue verzadigen.
De Diskqueue-waarden die je in normaal bedrijf hebt zijn verder redelijk.

- De HD's in die server worden die ook regelmatig gedefragenteerd ?
- Draai in een console eens een DEFRAG /A X: van de DB drive

Viel me idd op dat de speed omhoog gaat als de blocksize omhoog gaat.
Schijf is afgelopen vrijdag avond voor het laatst nog helemaal gedefragmenteerd (voor t eerst)

Maar als ik dit zo zie, zou ik zeggen dat de controller niet het probleem is, maar de schijven.
immers haal ik wel redelijke snelheden.

Ik heb nog een oudere SSD liggen, die er in pluggen en een test daar op doen om te zien wat dat doet met de test? (als die hoger is, dan is t de hdd, als ie net zo laag is, dan is t de controller?)

[Jazzy]

Performance testen tegen die disks terwijl de applicatie ook draait hebben niet zo veel zin. Kijk eerst maar even of je disken daadwerkelijk de bottleneck zijn door de Avg. Disk Queue Length te meten en de read/write latency te meten tijdens gebruik van de applicatie. Stel dat de Avg. Disk Queue Length nooit boven de twee komen en de latency netjes onder de 15ms blijft dan zit je in de verkeerde richting te zoeken. Of andersom gezegd, als je disk subsystem daadwerkelijk de bottleneck is dan moet je dat terugzien in een hoge Avg. Disk Queue Length en bijbehorende latency spikes.

eheijnen schreef op maandag 30 mei 2016 @ 12:12:
De Diskqueue-waarden die je in normaal bedrijf hebt zijn verder redelijk.

Misschien lees ik er overheen, maar bedoel je die 1-1000?

[ Voor 16% gewijzigd door Jazzy op 30-05-2016 12:19 ]

[eheijnen]

HellStorm666 schreef op maandag 30 mei 2016 @ 12:15:
[...]

Viel me idd op dat de speed omhoog gaat als de blocksize omhoog gaat.
Schijf is afgelopen vrijdag avond voor het laatst nog helemaal gedefragmenteerd (voor t eerst)

Maar als ik dit zo zie, zou ik zeggen dat de controller niet het probleem is, maar de schijven.
immers haal ik wel redelijke snelheden.

Ik heb nog een oudere SSD liggen, die er in pluggen en een test daar op doen om te zien wat dat doet met de test? (als die hoger is, dan is t de hdd, als ie net zo laag is, dan is t de controller?)

OK.
Dan heb je het disk-subsystem voorzover uitgesloten.

Op hoeveel memory is de SQL server ingesteld ?
Plaats eens een screenshot van de taskmanager-performance-tab en process tab.

[Jazzy]

eheijnen schreef op maandag 30 mei 2016 @ 12:24:
[...]
OK.
Dan heb je het disk-subsystem voorzover uitgesloten.

Ik probeer een beetje te begrijpen wat er nu precies gebeurt, kun je uitleggen hoe je vastgesteld hebt dat de applicatie niet op het disk subsystem staat te wachten?

[HellStorm666]

Jazzy schreef op maandag 30 mei 2016 @ 12:16:
Performance testen tegen die disks terwijl de applicatie ook draait hebben niet zo veel zin. Kijk eerst maar even of je disken daadwerkelijk de bottleneck zijn door de Avg. Disk Queue Length te meten en de read/write latency te meten tijdens gebruik van de applicatie. Stel dat de Avg. Disk Queue Length nooit boven de twee komen en de latency netjes onder de 15ms blijft dan zit je in de verkeerde richting te zoeken. Of andersom gezegd, als je disk subsystem daadwerkelijk de bottleneck is dan moet je dat terugzien in een hoge Avg. Disk Queue Length en bijbehorende latency spikes.
[...]
Misschien lees ik er overheen, maar bedoel je die 1-1000?

Heb je hier iets aan?



Avg DQL max = 2,482
Avg Disk sec/Read max = 0,055
Avg Disk sec/Transd max = 0,028
Avg Disk sec/Write max = 0,005

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 12:24:
[...]


OK.
Dan heb je het disk-subsystem voorzover uitgesloten.

Op hoeveel memory is de SQL server ingesteld ?
Plaats eens een screenshot van de taskmanager-performance-tab en process tab.

[eheijnen]

Wat meer memory zal hier zeker goed doen ( 2 x 4GB )
Je kunt idd eens die SSD plaatsen en dan nog eens die zelfde tests doen.
Wat is dat precies voor merk en type SDD ?

[Jazzy]

HellStorm666 schreef op maandag 30 mei 2016 @ 12:29:
[...]

Heb je hier iets aan?

[afbeelding]

Avg DQL max = 2,482
Avg Disk sec/Read max = 0,055
Avg Disk sec/Transd max = 0,028
Avg Disk sec/Write max = 0,005

Super! Een write duur gemiddeld 5ms, dat is heel keurig. Dat kan niet gezegd worden van de reads met gemiddeld 55 ms. Het is een beetje lastig te zien doordat je verschillende schalen gebruikt in je grafiek maar wat mij vooral opvalt is hoe constant het beeld is, dat je hebt bijna continu een zelfde latency hebt.

Verder lijkt de Avg. Disk Queue Length de hele tijd 1 te zijn als ik naar de grafiek kijk, dat is beslist niet schokkend. Wel zou het interessant zijn om wat beter te begrijpen welke processor voor dit gedrag zorgen, ik zou een veel piekerig gedrag verwachten namelijk. Open anders je resource monitor eens om uit te vogelen welke processen de meeste disk i/o veroorzaken en welk karakter dit heeft.

eheijnen schreef op maandag 30 mei 2016 @ 12:39:
Wat meer memory zal hier zeker goed doen ( 2 x 4GB )

Er is ongeveer 70% van het beschikbaar geheugen in gebruik, waarom zou meer memory goed doen?

@TS: Weet je zeker dat je je niet even wilt inlezen over de PAL tool? Met die tool kun je een custom performance counter log aanmaken en die vervolgens laten analyseren. Nu moeten we continu om informatie vragen die op afstand bovendien lastig te interpreteren is.

[ Voor 19% gewijzigd door Jazzy op 30-05-2016 12:44 ]

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 12:39:
Wat meer memory zal hier zeker goed doen ( 2 x 4GB )
Je kunt idd eens die SSD plaatsen en dan nog eens die zelfde tests doen.
Wat is dat precies voor merk en type SDD ?

SSD is een LAT-256M2S
Zat in een DELL workstation.
SSD heeft problemen, maar moet voor een speedtest prima werken.

[HellStorm666]

Jazzy schreef op maandag 30 mei 2016 @ 12:41:
[...]
Super! Een write duur gemiddeld 5ms, dat is heel keurig. Dat kan niet gezegd worden van de reads met gemiddeld 55 ms. Het is een beetje lastig te zien doordat je verschillende schalen gebruikt in je grafiek maar wat mij vooral opvalt is hoe constant het beeld is, dat je hebt bijna continu een zelfde latency hebt.

Verder lijkt de Avg. Disk Queue Length de hele tijd 1 te zijn als ik naar de grafiek kijk, dat is beslist niet schokkend. Wel zou het interessant zijn om wat beter te begrijpen welke processor voor dit gedrag zorgen, ik zou een veel piekerig gedrag verwachten namelijk. Open anders je resource monitor eens om uit te vogelen welke processen de meeste disk i/o veroorzaken en welk karakter dit heeft.
[...]
Er is ongeveer 70% van het beschikbaar geheugen in gebruik, waarom zou meer memory goed doen?

@TS: Weet je zeker dat je je niet even wilt inlezen over de PAL tool? Met die tool kun je een custom performance counter log aanmaken en die vervolgens laten analyseren. Nu moeten we continu om informatie vragen die op afstand bovendien lastig te interpreteren is.

Wil best die PAL tool doen.
Maar snap er nog geen snars van
Waar haal ik bijv. die performance counter log vandaan?
En moet ook .net spul weer installeren daarvoor, en dat heeft waarschijnlijk weer een reboot nodig waar de tekenkamer niet blij mee zal zijn.

[Jazzy]

Is dit nou echt teveel moeite? https://www.google.co.in/...=pal+tool+howto&gfe_rd=cr

Je hoeft alleen maar je data op de server te genereren, de analyse kun je op je eigen computer doen. Huur anders even een consultant in.

[ Voor 41% gewijzigd door Jazzy op 30-05-2016 12:51 ]

[HellStorm666]

Jazzy schreef op maandag 30 mei 2016 @ 12:50:
Is dit nou echt teveel moeite? https://www.google.co.in/...=pal+tool+howto&gfe_rd=cr

Je hoeft alleen maar je data op de server te genereren, de analyse kun je op je eigen computer doen.

Zeker niet te veel moeite, maar nog geen tijd gehad om er verder in te duiken.
Zo om 14u een vergadering, zal daarna eens in de PAL tool duiken.

[eheijnen]

HellStorm666 schreef op maandag 30 mei 2016 @ 12:47:
[...]

SSD is een LAT-256M2S
Zat in een DELL workstation.
SSD heeft problemen, maar moet voor een speedtest prima werken.

Dan is dit misschien nog een optie:
Kijk eens in de device manager naar de properties van de HD (plaatje).


Zijn deze opties aangevinkt ?
Door ook nog de tweede in te schakelen gaat Windows agressiever cachen voor deze disk. Vreet dan wel weer wat meer geheugen.

-->SSD is een LAT-256M2S
Hier een spec-sheet van Lite-on kun je dat afzetten tegen de benchmarks die je gaat daaien.
http://www.liteonssd.com/datasheet/2.5_M2S_MLC.pdf

[ Voor 13% gewijzigd door eheijnen op 30-05-2016 13:04 ]

[Baazie]

Als ik zo de post's even doorlees kom ik nog op een aantal vragen:

1. Staat je Server ook te swappen?
dit heeft nadelige impact fileserver en sql omdat deze gaat schrijven op je hdd terwijl dit in geheugen zou moeten staan.
2. Zijn er juiste indexes opgebouwd in je database?
dit kan vertragende effect hebben op de applicatie die niets anders doet dan query calls.
3. Perfomance van sql controleren kan met management studio voor SQL echter is sql2005 behoorlijk
gedateerd en heb ik geen idee of de nieuwe management studio hiermee overweg kan.
https://support.microsoft.com/en-us/kb/298475
4. Wat zegt Windows EventViewer?.

Aanbeveling,
1. Zoek uit of sql 2005 te upgraden is deze bevatten vatten vaak beveiliging lekken en ik weet niet of je zou willen dat straks de productie data op straat staat.
2. Disaster recovery plan opstellen, met externe back-up etc..
3. Dedicated server alleen voor SQL en Dedicated fileserver.

[HellStorm666]

Baazie schreef op maandag 30 mei 2016 @ 13:03:
Als ik zo de post's even doorlees kom ik nog op een aantal vragen:

1. Staat je Server ook te swappen?
dit heeft nadelige impact fileserver en sql omdat deze gaat schrijven op je hdd terwijl dit in geheugen zou moeten staan.
2. Zijn er juiste indexes opgebouwd in je database?
dit kan vertragende effect hebben op de applicatie die niets anders doet dan query calls.
3. Perfomance van sql controleren kan met management studio voor SQL echter is sql2005 behoorlijk
gedateerd en heb ik geen idee of de nieuwe management studio hiermee overweg kan.
https://support.microsoft.com/en-us/kb/298475
4. Wat zegt Windows EventViewer?.

Aanbeveling,
1. Zoek uit of sql 2005 te upgraden is deze bevatten vatten vaak beveiliging lekken en ik weet niet of je zou willen dat straks de productie data op straat staat.
2. Disaster recovery plan opstellen, met externe back-up etc..
3. Dedicated server alleen voor SQL en Dedicated fileserver.

1. Geen idee, hoe check ik dat?
2. zie 1.

Over de aanbevelingen.
Een upgrade van de SQL server wordt veel te duur. Zeker omdat met 1 a 2 jaar de server weg gaat en er Vault komt te draaien.
Externe back-ups hebben we
Dit willen we voor Vault ook gaan doen. Denk een ZFS voor de fileserver.

[KillerAce_NL]

HellStorm666 schreef op maandag 30 mei 2016 @ 10:26:
[...]

Met 1 a 2 jaar gaan wij sowieso over op Autodesk Vault. Daarvoor komt er een compleet nieuwe server met nieuwe db software ed.
Dus heel veel investeren is niet de bedoeling nu.

Een servertje aanschaffen is veel goedkoper als nog 2 jaar performance issue's hebben...
Je krijgt tegenwoordig veel meer performance voor je buck.
Vraag aub gedegen advies bij aanschaf, een instapservertje met een cheap raidcontrollertje, shitty consumer disks en ook nog een slecht ingericht is gewoon jammer van het geld.

[Dekaasboer]

Holy crapshoot! Dit topic gaat echt alle kanten op. Sorry dat ik het zeg maar ik zie een hoop onzinnig advies hier staan.

Eerst eens analyseren! Er wordt al gesproken over allemaal hardware aanschaffen zonder dat er goed geanalyseerd is. Consumer SSD's in een server... Er wordt verwezen naar PAL. Helemaal top! echter als je niet weet hoe je het moet interpreteren schiet je er niks mee op. Er wordt nu gefocust op je disk performance. Maar misschien zit het probleem wel in 1 tabel die een index mist. Of in je netwerk. Of je hebt te weinig temp db's aangemaakt. Misschien ga je RAM kopen terwijl de bottleneck schrijf performance is of je koopt ram terwijl heel SQL al uit cache draait en het is gewoon simultane transfersize van de overige files.

Wellicht moet je je afvragen of je professionele ondersteuning nodig hebt.
Maar om je toch wat verder te helpen. De resultaten van de volgende query's geven een beetje inzicht in de staat van je SQL machine.

SQL:

--Controle settings DB. Hier voor is "show advanced options" nodig. 
--Deze word met een reconfigure statement geactiveerd en weer gedeactiveerd. 
--Het is raadzaam eerst te controleren of er nog andere reconfigure statements klaar staan voor een "commit"


EXEC sp_configure 'Show Advanced Options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure;
EXEC sp_configure 'Show Advanced Options', 0;
GO
RECONFIGURE;

--Geeft databases, files en settings weer.
select name, recovery_model from sys.databases
select name, type, size, growth, is_percent_growth from sys.master_files


--Query op DM rapporteert de 50 grootste wait stats.
select top 10 * from sys.dm_os_wait_stats
order BY wait_time_ms desc

--Geeft de meest gefragmenteerde indexes weer
use [vul hier de naam van je applicatie database in]
SELECT Object_name(object_id) as Tablename,s.name as Indexname
,index_type_desc
,avg_fragmentation_in_percent
,page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, N'LIMITED') d
join sysindexes s on d.object_id = s.id
and d.index_id = s.indid
--and s.name ='IX_TestIndex_Index'
where avg_fragmentation_in_percent > '10' and page_count > '1000'  

--Geeft de grootste index bottlenecks weer volgens SQL en een create index statement.
SELECT TOP 10
dm_mid.database_id AS DatabaseID,
dm_migs.avg_user_impact*(dm_migs.user_seeks+dm_migs.user_scans) Avg_Estimated_Impact,
dm_migs.last_user_seek AS Last_User_Seek,
OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) AS [TableName],
'CREATE INDEX [IX_' + OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) + '_'
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.equality_columns,''),', ','_'),'[',''),']','') +
CASE
WHEN dm_mid.equality_columns IS NOT NULL AND dm_mid.inequality_columns IS NOT NULL THEN '_'
ELSE ''
END
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.inequality_columns,''),', ','_'),'[',''),']','')
+ ']'
+ ' ON ' + dm_mid.statement
+ ' (' + ISNULL (dm_mid.equality_columns,'')
+ CASE WHEN dm_mid.equality_columns IS NOT NULL AND dm_mid.inequality_columns IS NOT NULL THEN ',' ELSE
'' END
+ ISNULL (dm_mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + dm_mid.included_columns + ')', '') AS Create_Statement
FROM sys.dm_db_missing_index_groups dm_mig
INNER JOIN sys.dm_db_missing_index_group_stats dm_migs
ON dm_migs.group_handle = dm_mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details dm_mid
ON dm_mig.index_handle = dm_mid.index_handle
WHERE dm_mid.database_ID = DB_ID()
ORDER BY Avg_Estimated_Impact DESC
GO

Voor onderhoud kan je eens kijken naar de oplossing van Olla Hallgren:
https://ola.hallengren.com/
Deze staat standaard afgesteld op de aanbevolen Microsoft thresholds.
Dit voorkomt rebuilds. Dat is slim omdat anders het onderhoud je memory caches leegt!
Als dit te heftig is doe dan je index rebuild 1x per week. Met een DB van 2 GB zal het waarschijnlijk niet heel write intensief zijn en wil je vooral goede caches in ram. Daar maakt fragmentatie niks uit.

[ Voor 11% gewijzigd door Dekaasboer op 30-05-2016 15:21 ]

[HellStorm666]

Ik heb PAL 30 min laten lopen (deze handleiding: http://blog.fpweb.net/usi...gs-pal-tool/#.V0wbB_mLRD8) maar er gebeurt niets. er zou een htm file moeten komen... maar dat gebeurt dus niet.
Staat niets raars in het log.
Heeft iemand iets aan het .blg bestand? (die is 6,8MB geworden)

[eheijnen]

Nog een vraag: sinds wanneer is het systeem traag geworden ?

[HellStorm666]

Dekaasboer schreef op maandag 30 mei 2016 @ 15:03:
Holy crapshoot! Dit topic gaat echt alle kanten op. Sorry dat ik het zeg maar ik zie een hoop onzinnig advies hier staan.

Eerst eens analyseren! Er wordt al gesproken over allemaal hardware aanschaffen zonder dat er goed geanalyseerd is. Consumer SSD's in een server... Er wordt verwezen naar PAL. Helemaal top! echter als je niet weet hoe je het moet interpreteren schiet je er niks mee op. Er wordt nu gefocust op je disk performance. Maar misschien zit het probleem wel in 1 tabel die een index mist. Of in je netwerk. Of je hebt te weinig temp db's aangemaakt. Misschien ga je RAM kopen terwijl de bottleneck schrijf performance is of je koopt ram terwijl heel SQL al uit cache draait en het is gewoon simultane transfersize van de overige files.

Wellicht moet je je afvragen of je professionele ondersteuning nodig hebt.
Maar om je toch wat verder te helpen. De resultaten van de volgende query's geven een beetje inzicht in de staat van je SQL machine.

SQL:

--Controle settings DB. Hier voor is "show advanced options" nodig. 
--Deze word met een reconfigure statement geactiveerd en weer gedeactiveerd. 
--Het is raadzaam eerst te controleren of er nog andere reconfigure statements klaar staan voor een "commit"


EXEC sp_configure 'Show Advanced Options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure;
EXEC sp_configure 'Show Advanced Options', 0;
GO
RECONFIGURE;

--Geeft databases, files en settings weer.
select name, recovery_model from sys.databases
select name, type, size, growth, is_percent_growth from sys.master_files


--Query op DM rapporteert de 50 grootste wait stats.
select top 10 * from sys.dm_os_wait_stats
order BY wait_time_ms desc

--Geeft de meest gefragmenteerde indexes weer
use [vul hier de naam van je applicatie database in]
SELECT Object_name(object_id) as Tablename,s.name as Indexname
,index_type_desc
,avg_fragmentation_in_percent
,page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, N'LIMITED') d
join sysindexes s on d.object_id = s.id
and d.index_id = s.indid
--and s.name ='IX_TestIndex_Index'
where avg_fragmentation_in_percent > '10' and page_count > '1000'  

--Geeft de grootste index bottlenecks weer volgens SQL en een create index statement.
SELECT TOP 10
dm_mid.database_id AS DatabaseID,
dm_migs.avg_user_impact*(dm_migs.user_seeks+dm_migs.user_scans) Avg_Estimated_Impact,
dm_migs.last_user_seek AS Last_User_Seek,
OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) AS [TableName],
'CREATE INDEX [IX_' + OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) + '_'
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.equality_columns,''),', ','_'),'[',''),']','') +
CASE
WHEN dm_mid.equality_columns IS NOT NULL AND dm_mid.inequality_columns IS NOT NULL THEN '_'
ELSE ''
END
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.inequality_columns,''),', ','_'),'[',''),']','')
+ ']'
+ ' ON ' + dm_mid.statement
+ ' (' + ISNULL (dm_mid.equality_columns,'')
+ CASE WHEN dm_mid.equality_columns IS NOT NULL AND dm_mid.inequality_columns IS NOT NULL THEN ',' ELSE
'' END
+ ISNULL (dm_mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + dm_mid.included_columns + ')', '') AS Create_Statement
FROM sys.dm_db_missing_index_groups dm_mig
INNER JOIN sys.dm_db_missing_index_group_stats dm_migs
ON dm_migs.group_handle = dm_mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details dm_mid
ON dm_mig.index_handle = dm_mid.index_handle
WHERE dm_mid.database_ID = DB_ID()
ORDER BY Avg_Estimated_Impact DESC
GO

Voor onderhoud kan je eens kijken naar de oplossing van Olla Hallgren:
https://ola.hallengren.com/
Deze staat standaard afgesteld op de aanbevolen Microsoft thresholds.
Dit voorkomt rebuilds. Dat is slim omdat anders het onderhoud je memory caches leegt!
Als dit te heftig is doe dan je index rebuild 1x per week. Met een DB van 2 GB zal het waarschijnlijk niet heel write intensief zijn en wil je vooral goede caches in ram. Daar maakt fragmentatie niks uit.

Ok, hier mijn poging om dit te doen (1e keer dat ik SQL querys draai op een sql server (ken alleen mysql, mariadb enz.)

EDIT:
Heb de hele code in 1x gedraaid. hier de output:

code:

Ad Hoc Distributed Queries  0   1   0   0
affinity I/O mask   -2147483648 2147483647  0   0
affinity mask   -2147483648 2147483647  0   0
affinity64 I/O mask -2147483648 2147483647  0   0
affinity64 mask -2147483648 2147483647  0   0
Agent XPs   0   1   1   1
allow updates   0   1   0   0
awe enabled 0   1   0   0
blocked process threshold   0   86400   5   5
c2 audit mode   0   1   0   0
clr enabled 0   1   0   0
cost threshold for parallelism  0   32767   5   5
cross db ownership chaining 0   1   0   0
cursor threshold    -1  2147483647  -1  -1
Database Mail XPs   0   1   0   0
default full-text language  0   2147483647  1033    1033
default language    0   9999    0   0
default trace enabled   0   1   1   1
disallow results from triggers  0   1   0   0
fill factor (%) 0   100 0   0
ft crawl bandwidth (max)    0   32767   100 100
ft crawl bandwidth (min)    0   32767   0   0
ft notify bandwidth (max)   0   32767   100 100
ft notify bandwidth (min)   0   32767   0   0
index create memory (KB)    704 2147483647  0   0
in-doubt xact resolution    0   2   0   0
lightweight pooling 0   1   0   0
locks   5000    2147483647  0   0
max degree of parallelism   0   64  0   0
max full-text crawl range   0   256 4   4
max server memory (MB)  16  2147483647  2147483647  2147483647
max text repl size (B)  0   2147483647  65536   65536
max worker threads  128 32767   0   0
media retention 0   365 0   0
min memory per query (KB)   512 2147483647  1024    1024
min server memory (MB)  0   2147483647  0   0
nested triggers 0   1   1   1
network packet size (B) 512 32767   4096    4096
Ole Automation Procedures   0   1   0   0
open objects    0   2147483647  0   0
PH timeout (s)  1   3600    60  60
precompute rank 0   1   0   0
priority boost  0   1   0   0
query governor cost limit   0   2147483647  0   0
query wait (s)  -1  2147483647  -1  -1
recovery interval (min) 0   32767   0   0
remote access   0   1   1   1
remote admin connections    0   1   0   0
remote login timeout (s)    0   2147483647  20  20
remote proc trans   0   1   0   0
remote query timeout (s)    0   2147483647  600 600
Replication XPs 0   1   0   0
scan for startup procs  0   1   0   0
server trigger recursion    0   1   1   1
set working set size    0   1   0   0
show advanced options   0   1   1   1
SMO and DMO XPs 0   1   1   1
SQL Mail XPs    0   1   0   0
transform noise words   0   1   0   0
two digit year cutoff   1753    9999    2049    2049
user connections    0   32767   0   0
user options    0   32767   0   0
Web Assistant Procedures    0   1   0   0
xp_cmdshell 0   1   0   0

code:

master  3
tempdb  3
model   1
msdb    3
NXTdimPDM_ELT   3

code:

master  0   512 10  1
mastlog 1   160 10  1
tempdev 0   1024    10  1
templog 1   64  10  1
modeldev    0   280 128 0
modellog    1   1880    10  1
MSDBData    0   3288    10  1
MSDBLog 1   320 10  1
PSP2009_B   0   146856  128 0
PSP2009_B_log   1   128248  10  1

code:

LAZYWRITER_SLEEP    1030159 1025517406  1279    2464
SQLTRACE_BUFFER_FLUSH   256780  1025509014  4180    0
CXPACKET    2356824 13408519    8283    587312
SLEEP_BPOOL_FLUSH   449237  4477759 171 7316
WRITELOG    1147114 2793509 11606   56051
SOS_SCHEDULER_YIELD 29973440    2037139 202 2036998
LCK_M_IS    685 1485301 12339   3884
ASYNC_IO_COMPLETION 61  1419827 84802   0
BACKUPBUFFER    68178   1406021 702 1185
LCK_M_SCH_S 357 650258  11325   951

code:

AIM_IMPORT_DML  NULL    HEAP    33,4364261168385    22468

code:

5   49615020,87 2016-05-30 15:37:34.263 JOBSERVER   CREATE INDEX [IX_JOBSERVER_ELEMENT_AIMKEY] ON [NXTdimPDM_ELT].[dbo].[JOBSERVER] ([ELEMENT_AIMKEY])
5   1316461,5   2016-05-30 15:30:13.013 DOCUMENT    CREATE INDEX [IX_DOCUMENT_FILE_LINKNAME] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([FILE_LINKNAME]) INCLUDE ([AIMKEY], [FILE_NAME])
5   302155,14   2016-05-30 11:30:34.460 DOCUMENT    CREATE INDEX [IX_DOCUMENT_PART_NUMBER_FILE_TYPE] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER],[FILE_TYPE])
5   139319,4    2016-05-27 08:43:24.130 ELEMENT CREATE INDEX [IX_ELEMENT_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [ENTITY_TYPE], [SHORT_DESC], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_1_SHORT], [WORLD_GROUP])
5   55232,12    2016-05-30 14:09:21.603 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [CREATE_USER], [OWNER], [OWNER_GROUP], [RIGHTS], [WORLD_GROUP])
5   29083,2 2016-05-30 11:30:34.530 DOCUMENT    CREATE INDEX [IX_DOCUMENT_PART_NUMBER] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER])
5   27058,5 2016-05-30 14:36:46.980 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP])
5   21030,8 2016-05-25 16:40:00.753 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [CUSTOM_3_NAME], [WORLD_GROUP])
5   20075,88    2016-05-30 14:42:33.300 CONFIGURATION2  CREATE INDEX [IX_CONFIGURATION2_PROFILE] ON [NXTdimPDM_ELT].[dbo].[CONFIGURATION2] ([PROFILE]) INCLUDE ([AIMKEY], [TYPE], [NAME], [VALUE], [PARENT])
5   15748,8 2016-05-30 15:38:01.523 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP])

[ Voor 62% gewijzigd door HellStorm666 op 30-05-2016 15:40 . Reden: Even alles in 1x ]

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 15:31:
Nog een vraag: sinds wanneer is het systeem traag geworden ?

Al ruim een jaar geleden... Maar de database is sinds een tijdje flink aan t groeien (vooral ook de files) en is daarmee nog trager geworden.
Ik ben de eerste die t aandurft om het probleem op te gaan lossen.

[eheijnen]

Eens afwachten wat deKaasboer zegt van die output

[eheijnen]

Ik kan die SQL zaken wel begrijpen die men aandraagt. Kan me echter niet voorstellen dat die applicatieleverancier zulk soort zaken als indexen niet heeft geregeld / dat die standaard niet geoptimaliseerd zijn. Op de HD na heeft dat ding in principe genoeg performance om een DB van 2GB te draaien en ook nog wel groter.

Mocht dat testen met die SDD goedgaan. Zou je een test kunnen doen door die database tijdelijk een dag op de SDD te plaatsen en te kijken wat de gebruikers ervan vinden.

[HellStorm666]

eheijnen schreef op maandag 30 mei 2016 @ 15:54:
Ik kan die SQL zaken wel begrijpen die men aandraagt. Kan me echter niet voorstellen dat die applicatieleverancier zulk soort zaken als indexen niet heeft geregeld / dat die standaard niet geoptimaliseerd zijn. Op de HD na heeft dat ding in principe genoeg performance om een DB van 2GB te draaien en ook nog wel groter.

Mocht dat testen met die SDD goedgaan. Zou je een test kunnen doen door die database tijdelijk een dag op de SDD te plaatsen en te kijken wat de gebruikers ervan vinden.

Wat is de makkelijkste en veiligste mannier om de DB te verplaatsen (tijdelijk) naar de SSD?
(als t kan a.u.b. redelijk stap voor stap)

[Jazzy]

https://www.google.co.in/...w+to+move+files&gfe_rd=cr

Dit is volgens mij de derde keer dat ik uitleg dat je de gevraagde info makkelijk zelf kunt vergaren. Ik zeg het nog maar een keer, als deze materie je boven de pet gaat dan kun je beter een externe inhuren.

Dit is een forum dus vragen staat vrij, maar realiseer je wel hoeveel van onze tijd je vraagt door zelf niet te zoeken voordat je het vraagt.

[ Voor 67% gewijzigd door Jazzy op 30-05-2016 16:02 ]

[eheijnen]

Hier op Technet wordt het hele proces beschreven
MSDN: Move a Database Using Detach and Attach (Transact-SQL)

[HellStorm666]

diskspd getest nu op de ssd

code:

Command Line: diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G D:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'D:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 8192
        using random I/O (alignment: 8192)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   6.71%|   1.61%|    5.10%|  93.29%
   1|  48.59%|   1.53%|   47.06%|  51.40%
   2|   9.61%|   1.73%|    7.88%|  90.39%
   3|   7.81%|   1.59%|    6.23%|  92.18%
   4|   8.87%|   1.30%|    7.57%|  91.13%
   5|   2.21%|   0.57%|    1.64%|  97.79%
   6|   6.85%|   2.05%|    4.80%|  93.15%
   7|   3.25%|   0.72%|    2.54%|  96.75%
-------------------------------------------
avg.|  11.74%|   1.39%|   10.35%|  88.26%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1504174080 |       183615 |      11.95 |    1530.13 |    2.611 |     2.008 | D:\iotest.dat (20GB)
     1 |      1441112064 |       175917 |      11.45 |    1465.98 |    2.724 |     2.057 | D:\iotest.dat (20GB)
     2 |      1492541440 |       182195 |      11.86 |    1518.30 |    2.632 |     2.005 | D:\iotest.dat (20GB)
     3 |      1496735744 |       182707 |      11.90 |    1522.57 |    2.624 |     1.997 | D:\iotest.dat (20GB)
     4 |      1502478336 |       183408 |      11.94 |    1528.41 |    2.615 |     1.997 | D:\iotest.dat (20GB)
     5 |      1511317504 |       184487 |      12.01 |    1537.40 |    2.600 |     1.978 | D:\iotest.dat (20GB)
     6 |      1481433088 |       180839 |      11.77 |    1507.00 |    2.652 |     2.083 | D:\iotest.dat (20GB)
     7 |      1492590592 |       182201 |      11.86 |    1518.35 |    2.632 |     2.004 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:       11922382848 |      1455369 |      94.75 |   12128.13 |    2.636 |     2.016

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1129046016 |       137823 |       8.97 |    1148.53 |    3.351 |     1.717 | D:\iotest.dat (20GB)
     1 |      1080909824 |       131947 |       8.59 |    1099.56 |    3.487 |     1.731 | D:\iotest.dat (20GB)
     2 |      1118167040 |       136495 |       8.89 |    1137.46 |    3.374 |     1.660 | D:\iotest.dat (20GB)
     3 |      1122803712 |       137061 |       8.92 |    1142.18 |    3.359 |     1.665 | D:\iotest.dat (20GB)
     4 |      1126236160 |       137480 |       8.95 |    1145.67 |    3.356 |     1.667 | D:\iotest.dat (20GB)
     5 |      1130405888 |       137989 |       8.98 |    1149.91 |    3.343 |     1.657 | D:\iotest.dat (20GB)
     6 |      1109827584 |       135477 |       8.82 |    1128.98 |    3.402 |     1.805 | D:\iotest.dat (20GB)
     7 |      1120346112 |       136761 |       8.90 |    1139.68 |    3.371 |     1.692 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        8937742336 |      1091033 |      71.03 |    9091.99 |    3.380 |     1.700

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       375128064 |        45792 |       2.98 |     381.60 |    0.381 |     0.821 | D:\iotest.dat (20GB)
     1 |       360202240 |        43970 |       2.86 |     366.42 |    0.432 |     0.970 | D:\iotest.dat (20GB)
     2 |       374374400 |        45700 |       2.98 |     380.84 |    0.415 |     1.115 | D:\iotest.dat (20GB)
     3 |       373932032 |        45646 |       2.97 |     380.39 |    0.418 |     1.075 | D:\iotest.dat (20GB)
     4 |       376242176 |        45928 |       2.99 |     382.74 |    0.399 |     1.030 | D:\iotest.dat (20GB)
     5 |       380911616 |        46498 |       3.03 |     387.49 |    0.392 |     0.924 | D:\iotest.dat (20GB)
     6 |       371605504 |        45362 |       2.95 |     378.02 |    0.411 |     0.927 | D:\iotest.dat (20GB)
     7 |       372244480 |        45440 |       2.96 |     378.67 |    0.407 |     0.942 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        2984640512 |       364336 |      23.72 |    3036.15 |    0.407 |     0.979


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.088 |      0.073 |      0.073
   25th |      2.403 |      0.159 |      1.063
   50th |      3.218 |      0.232 |      2.690
   75th |      4.164 |      0.392 |      3.808
   90th |      5.135 |      0.835 |      4.852
   95th |      5.782 |      1.343 |      5.526
   99th |      7.236 |      2.454 |      6.970
3-nines |     11.546 |      4.578 |     10.858
4-nines |     51.643 |     45.915 |     51.217
5-nines |     58.518 |     61.193 |     58.518
6-nines |     59.683 |     63.354 |     63.231
7-nines |     60.946 |     63.354 |     63.354
8-nines |     60.946 |     63.354 |     63.354
9-nines |     60.946 |     63.354 |     63.354
    max |     60.946 |     63.354 |     63.354

Een hele flinke verbetering dus.
Dus de db eens naar de SSD verplaatsen als test.

de 8GB is nu ook 16GB, maar het systeem is daar helemaal niets sneller van geworden.
wordt momenteel maar 2,6GB van de 16GB gebruikt (sqlsrv = 800mb)

[eheijnen]

HellStorm666 schreef op maandag 30 mei 2016 @ 17:27:
diskspd getest nu op de ssd

code:

Command Line: diskspd -b8K -d120 -o4 -t8 -h -r -w25 -L -Z1G -c20G D:\iotest.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    random seed: 0
    path: 'D:\iotest.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        write buffer size: 1073741824
        performing mix test (read/write ratio: 75/25)
        block size: 8192
        using random I/O (alignment: 8192)
        number of outstanding I/O operations: 4
        thread stride size: 0
        threads per file: 8
        using I/O Completion Ports
        IO priority: normal



Results for timespan 1:
*******************************************************************************

actual test time:   120.00s
thread count:       8
proc count:     8

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|   6.71%|   1.61%|    5.10%|  93.29%
   1|  48.59%|   1.53%|   47.06%|  51.40%
   2|   9.61%|   1.73%|    7.88%|  90.39%
   3|   7.81%|   1.59%|    6.23%|  92.18%
   4|   8.87%|   1.30%|    7.57%|  91.13%
   5|   2.21%|   0.57%|    1.64%|  97.79%
   6|   6.85%|   2.05%|    4.80%|  93.15%
   7|   3.25%|   0.72%|    2.54%|  96.75%
-------------------------------------------
avg.|  11.74%|   1.39%|   10.35%|  88.26%

Total IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1504174080 |       183615 |      11.95 |    1530.13 |    2.611 |     2.008 | D:\iotest.dat (20GB)
     1 |      1441112064 |       175917 |      11.45 |    1465.98 |    2.724 |     2.057 | D:\iotest.dat (20GB)
     2 |      1492541440 |       182195 |      11.86 |    1518.30 |    2.632 |     2.005 | D:\iotest.dat (20GB)
     3 |      1496735744 |       182707 |      11.90 |    1522.57 |    2.624 |     1.997 | D:\iotest.dat (20GB)
     4 |      1502478336 |       183408 |      11.94 |    1528.41 |    2.615 |     1.997 | D:\iotest.dat (20GB)
     5 |      1511317504 |       184487 |      12.01 |    1537.40 |    2.600 |     1.978 | D:\iotest.dat (20GB)
     6 |      1481433088 |       180839 |      11.77 |    1507.00 |    2.652 |     2.083 | D:\iotest.dat (20GB)
     7 |      1492590592 |       182201 |      11.86 |    1518.35 |    2.632 |     2.004 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:       11922382848 |      1455369 |      94.75 |   12128.13 |    2.636 |     2.016

Read IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |      1129046016 |       137823 |       8.97 |    1148.53 |    3.351 |     1.717 | D:\iotest.dat (20GB)
     1 |      1080909824 |       131947 |       8.59 |    1099.56 |    3.487 |     1.731 | D:\iotest.dat (20GB)
     2 |      1118167040 |       136495 |       8.89 |    1137.46 |    3.374 |     1.660 | D:\iotest.dat (20GB)
     3 |      1122803712 |       137061 |       8.92 |    1142.18 |    3.359 |     1.665 | D:\iotest.dat (20GB)
     4 |      1126236160 |       137480 |       8.95 |    1145.67 |    3.356 |     1.667 | D:\iotest.dat (20GB)
     5 |      1130405888 |       137989 |       8.98 |    1149.91 |    3.343 |     1.657 | D:\iotest.dat (20GB)
     6 |      1109827584 |       135477 |       8.82 |    1128.98 |    3.402 |     1.805 | D:\iotest.dat (20GB)
     7 |      1120346112 |       136761 |       8.90 |    1139.68 |    3.371 |     1.692 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        8937742336 |      1091033 |      71.03 |    9091.99 |    3.380 |     1.700

Write IO
thread |       bytes     |     I/Os     |     MB/s   |  I/O per s |  AvgLat  | LatStdDev |  file
-----------------------------------------------------------------------------------------------------
     0 |       375128064 |        45792 |       2.98 |     381.60 |    0.381 |     0.821 | D:\iotest.dat (20GB)
     1 |       360202240 |        43970 |       2.86 |     366.42 |    0.432 |     0.970 | D:\iotest.dat (20GB)
     2 |       374374400 |        45700 |       2.98 |     380.84 |    0.415 |     1.115 | D:\iotest.dat (20GB)
     3 |       373932032 |        45646 |       2.97 |     380.39 |    0.418 |     1.075 | D:\iotest.dat (20GB)
     4 |       376242176 |        45928 |       2.99 |     382.74 |    0.399 |     1.030 | D:\iotest.dat (20GB)
     5 |       380911616 |        46498 |       3.03 |     387.49 |    0.392 |     0.924 | D:\iotest.dat (20GB)
     6 |       371605504 |        45362 |       2.95 |     378.02 |    0.411 |     0.927 | D:\iotest.dat (20GB)
     7 |       372244480 |        45440 |       2.96 |     378.67 |    0.407 |     0.942 | D:\iotest.dat (20GB)
-----------------------------------------------------------------------------------------------------
total:        2984640512 |       364336 |      23.72 |    3036.15 |    0.407 |     0.979


  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.088 |      0.073 |      0.073
   25th |      2.403 |      0.159 |      1.063
   50th |      3.218 |      0.232 |      2.690
   75th |      4.164 |      0.392 |      3.808
   90th |      5.135 |      0.835 |      4.852
   95th |      5.782 |      1.343 |      5.526
   99th |      7.236 |      2.454 |      6.970
3-nines |     11.546 |      4.578 |     10.858
4-nines |     51.643 |     45.915 |     51.217
5-nines |     58.518 |     61.193 |     58.518
6-nines |     59.683 |     63.354 |     63.231
7-nines |     60.946 |     63.354 |     63.354
8-nines |     60.946 |     63.354 |     63.354
9-nines |     60.946 |     63.354 |     63.354
    max |     60.946 |     63.354 |     63.354

Een hele flinke verbetering dus.
Dus de db eens naar de SSD verplaatsen als test.

de 8GB is nu ook 16GB, maar het systeem is daar helemaal niets sneller van geworden.
wordt momenteel maar 2,6GB van de 16GB gebruikt (sqlsrv = 800mb)

En dat bij een block-size van 8K.
Als je dat met 256K doet krijg je nog heel andere getallen.

Schrijf alles op wat je doet bij het verplaatsen van de DB zodat je weet wat je gedaan hebt.
Zorg dat je een goede kopei achter de hand hebt.

Je hebt net opgestart. Het geheugengebruik zal nog stijgen.
Dat write-caching zoals eerder gepost kun je ook op de SSD aanzetten.

[Dekaasboer]

HellStorm666 schreef op maandag 30 mei 2016 @ 15:33:
[...]

Ok, hier mijn poging om dit te doen (1e keer dat ik SQL querys draai op een sql server (ken alleen mysql, mariadb enz.)

EDIT:
Heb de hele code in 1x gedraaid. hier de output:

Ok, nu even interpreteren.
Ik verwijder alles waar we toch niks mee doen.

code:

cost threshold for parallelism  0   32767   5   5
max degree of parallelism   0   64  0   0
max server memory (MB)  16  2147483647  2147483647  2147483647
min server memory (MB)  0   2147483647  0   0

Je cost threshold for parralism staat op 5 en je max degree of parralism staat op 0. Dat betekent dat met een hele kleine werklast SQL de query parallel over meerdere cores zal laten lopen.
Verder staat je max en min server memory niet ingesteld. SQL zal geheugen blijven pakken totdat het vol zit en zodra een andere applicatie geheugen nodig heeft zal hij het ook direct allemaal weer afstaan.

Advies:

• cost threshold for parallelism: 50
• max degree of parallelism: 2
• Min server memory: 2000
• Max server memory 4000

code:

NXTdimPDM_ELT   3

De recovery mode van je database staat op simple. Indien transactionele integriteit niet super belangrijk is maakt het ook niet zoveel uit. Let wel. Men denkt vaak dat database op simple zetten de log uitschakelt en dat het daarom sneller gaat maar dat klopt niet. SQL werkt altijd via de logfiles. Echter het groei en backup gedrag is anders. Niks mee doen.

code:

tempdev 0   1024    10  1
templog 1   64  10  1
PSP2009_B   0   146856  128 0
PSP2009_B_log   1   128248  10  1

Je hebt slechts 1 tempdb file. Microsoft raad 1 tempdb per fysieke core (boven de 8 gaan andere regels gelden) Echter aan de logsize te zien wordt het toch weinig gebruikt.

• Maak een 2e tempdb file aan.

Je database is slechts 1,14GB maar heeft een vaste autogrowth van 1MB. Als er data geschreven wordt fragmenteert je database bestand snel. Het is ook raadzaam om de database alvast ruimte te laten inpikken (anti-shrink). Als de datafile vol zit en deze moet uitgebreid worden dat levert dit vertraging op.

• Zet je file size van de database alvast op 2gb
• Zet de autogrowth op 10mb

De log is 1GB. Dat zegt niet zoveel aangezien er waarschijnlijk een minimum grootte staat ingesteld. De logfile staat wel ingesteld om procentueel 10% te groeien. Het is aan te raden om daar een vaste grootte van te maken. (10mb)

• Zet de autogrowth van de logfile van de database op 10mb

code:

CXPACKET    2356824 13408519    8283    587312

Het lijkt er op dat je server vaak staat te wachten op geparaleliseerde opdrachten. Het zetten van cost threshold for parallelism en max degree of parallelism zal hier waarschijnlijk al mee helpen.

code:

AIM_IMPORT_DML  NULL    HEAP    33,4364261168385    22468

Je hebt niet echt last van gefragmenteerde indexes. Echter deze tabel is wel een heap (geen index).

code:

5   49615020,87 2016-05-30 15:37:34.263 JOBSERVER   CREATE INDEX [IX_JOBSERVER_ELEMENT_AIMKEY] ON [NXTdimPDM_ELT].[dbo].[JOBSERVER] ([ELEMENT_AIMKEY])
5   1316461,5   2016-05-30 15:30:13.013 DOCUMENT    CREATE INDEX [IX_DOCUMENT_FILE_LINKNAME] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([FILE_LINKNAME]) INCLUDE ([AIMKEY], [FILE_NAME])
5   302155,14   2016-05-30 11:30:34.460 DOCUMENT    CREATE INDEX [IX_DOCUMENT_PART_NUMBER_FILE_TYPE] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER],[FILE_TYPE])
5   139319,4    2016-05-27 08:43:24.130 ELEMENT CREATE INDEX [IX_ELEMENT_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [ENTITY_TYPE], [SHORT_DESC], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_1_SHORT], [WORLD_GROUP])
5   55232,12    2016-05-30 14:09:21.603 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [CREATE_USER], [OWNER], [OWNER_GROUP], [RIGHTS], [WORLD_GROUP])
[s]5    29083,2 2016-05-30 11:30:34.530 DOCUMENT    CREATE INDEX [IX_DOCUMENT_PART_NUMBER] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER])[/s]
5   27058,5 2016-05-30 14:36:46.980 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP])
5   21030,8 2016-05-25 16:40:00.753 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [CUSTOM_3_NAME], [WORLD_GROUP])
5   20075,88    2016-05-30 14:42:33.300 CONFIGURATION2  CREATE INDEX [IX_CONFIGURATION2_PROFILE] ON [NXTdimPDM_ELT].[dbo].[CONFIGURATION2] ([PROFILE]) INCLUDE ([AIMKEY], [TYPE], [NAME], [VALUE], [PARENT])
5   15748,8 2016-05-30 15:38:01.523 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP])

Er zit wat overlap tussen de suggesties voor indexes.

Ik kom uiteindelijk hier op uit. Dit zou al aardig moeten schelen:

SQL:

CREATE INDEX [IX_DOCUMENT_PART_NUMBER_FILE_TYPE] ON 
[NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER],[FILE_TYPE])
CREATE INDEX [IX_DOCUMENT_FILE_LINKNAME] ON 
[NXTdimPDM_ELT].[dbo].[DOCUMENT] ([FILE_LINKNAME]) INCLUDE ([AIMKEY], [FILE_NAME])
CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON 
[NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [CREATE_USER], [OWNER], [OWNER_GROUP], [RIGHTS], [WORLD_GROUP])

Al de wijzigingen die ik gesuggereerd hebt kan je via de UI doen (klik rechtermuis op de servernaam en op de namen van de databases in de managment studio) dan weet je ook gelijk waar het zit en als het niet werkt dan kan je het zelf ook terug zetten. Dit is allemaal veilig en zal je niet zomaar in de problemen brengen.

Het aanmaken van de indexen is iets anders. Bij sommige pakketten vervalt de garantie als je aan de database rommelt (sharepoint) andere pakketten ondersteunen het niet. Daar moet je altijd de index in het pakket zelf aanmaken (dynamics AX).
Daarom zou ik altijd voordat je indexen aanmaakt eerst met de leverancier van het pakket overleggen en het eerst in een testomgeving proberen.

Als je beide opties niet hebt maak dan eerst een backup van je database en maak dan de indexen aan. Kijk of het programma nog normaal werkt alvorens gebruikers er weer mee te laten werken.
Bewaar het script waarmee je de indexen hebt aangemaakt. Dan kan je ze altijd weer opzoeken en verwijderen.

Nog 1 laatste tip. Voer je wijzigingen stapsgewijs door. Wellicht maakt de ene wijziging het systeem een stuk sneller en de andere iets weer een stuk trager. Dan lijkt het per saldo hetzelfde.

Nog even over SSD's en de werking van SQL.
SQL is geen dom programma. Zelfs versie 2005 is al een geavanceerd pakket. SQL gaat zoveel mogelijk dingen cachen in het geheugen. Een SSD gaat je dus pas helpen als de bottleneck bij het schrijven van data ligt of als de database niet in het geheugen past.

Je kan overigens best snellere hdd's in de server prikken. Echter wat voor netwerk verbinding heb je? Als je bottleneck niet read IOPS is en je hebt er een 1gbit lan achter hangen schiet je natuurlijk niks op met een dikke SSD.

[ Voor 13% gewijzigd door Dekaasboer op 30-05-2016 20:50 ]