Random read/write en threads en queues

[zonderbloem]

Op mijn werk draaien we een aantal MySQL databases draaien verspreid over twee database servers (laten we zeggen server A & B ). Ik ben me aan het verdiepen in de disk performance en heb een aantal benchmarks gedraaid met Crystal Disk Mark. De performance van beide servers zijn met random read/write met 4 threads en 16 queues vrijwel even hoog. Als ik dezelfde test uitvoer maar nu met 1 thread en 1 queue dan zie ik tussen server A en B een groot verschil in write performance

Server A
4K - 1 thread 1 queue
IOPS read: 4745
IOPS write: 1045
Latency read: 208 ns
Latency write: 950 ns

Server B
4K - 1 thread 1 queue
IOPS read: 4552
IOPS write: 6455
Latency read: 218 ns
Latency write: 150 ns

Wat is belangrijk voor MySQL? Werkt deze applicatie op diskniveau met 1 thread en 1 queue of hoef ik me geen zorgen te maken omdat met 4 threads / 16 queues ongeveer dezelfde performance resultaten oplevert?

[hans_lenze]

Stap 1: doe dit niet met CrystalDiskmark maar met een echte tool zoals Diskspd van Microsoft.
Stap 2: kijk in de documentatie van je applicatie naar de relevante informatie. Bijvoorbeeld https://dev.mysql.com/doc...ptimize-benchmarking.html
Stap 3: zorg ervoor dat je benchmark instellingen overeen komen met je applicatie (hint: 4k block size, 1 thread, 1 queue lijkt niet op MySQL)
Stap 4: voer je benchmark meerdere keren en op meerdere momenten uit, zodat je niet al je beslissingen van één meetpunt afhankelijk maakt waarop Truus de secretaresse druk bezig was ofzo.
Stap 5: bekijk alle resultaten naast elkaar in perspectief en vergeet de toekomstige wijzigingen in applicatie en/of dataformaat niet.
Stap 6: doe dit na elke patch, update of grote wijziging om een beeld te houden van je applicatie performance anders dan "het voelt wat trager vandaag".

[Q]

zonderbloem schreef op maandag 17 februari 2020 @ 22:28:
. Als ik dezelfde test uitvoer maar nu met 1 thread en 1 queue dan zie ik tussen server A en B een groot verschil in write performance

Server A
IOPS write: 1045
Latency write: 950 ns

Server B
IOPS write: 6455
Latency write: 150 ns

Wat is belangrijk voor MySQL? Werkt deze applicatie op diskniveau met 1 thread en 1 queue of hoef ik me geen zorgen te maken omdat met 4 threads / 16 queues ongeveer dezelfde performance resultaten oplevert?

1. Waarom stel je deze vragen niet aan het operations team?
2. Waarom doe je deze benchmarks: welk probleem probeer je op te lossen?
3. Wat is je eigen performance baseline: wat is de norm die moet worden gehaald (Gebruikerservaring/ latency?).
4. Wordt die norm nu al gehaald of niet?
5. Wat vind het ops team van deze resultaten?
6. Is onderzocht of misschien write-through vs write-back is geconfigureerd, of zitten de SSDs vol op server A? Worden enterprise SSDs of consumer SSDs gebruikt? RAID controller misconfiguratie?
7. Zoals hierboven benoemd maar belangrijk dus ik herhaal: was er niet een hoge load op A?

[ Voor 4% gewijzigd door Q op 18-02-2020 12:57 ]

[zonderbloem]

Q schreef op dinsdag 18 februari 2020 @ 12:56:
[...]
1. Waarom stel je deze vragen niet aan het operations team?
2. Waarom doe je deze benchmarks: welk probleem probeer je op te lossen?
3. Wat is je eigen performance baseline: wat is de norm die moet worden gehaald (Gebruikerservaring/ latency?).
4. Wordt die norm nu al gehaald of niet?
5. Wat vind het ops team van deze resultaten?
6. Is onderzocht of misschien write-through vs write-back is geconfigureerd, of zitten de SSDs vol op server A? Worden enterprise SSDs of consumer SSDs gebruikt? RAID controller misconfiguratie?
7. Zoals hierboven benoemd maar belangrijk dus ik herhaal: was er niet een hoge load op A?

Dit gaat om een kleine omgeving en binnen mijn bedrijf hebben we geen operations team/dev ops teams. Ik probeer erachter te komen waarom twee identieke VM's op Hyper-V op de ene server MySQL minder performance geeft dan de andere server. Het is exact dezelfde VM de test is gedaan buiten kantooruren dus er draaide verder geen IO intensieve scripts of aanvragen. Op server A haal ik met een CSV importeren 2400 inserts/sec en op server B maar 230 inserts/sec getest vanaf localhost. Beide servers zijn voorzien van alle updates en write-back cache staat niet ingesteld binnen Windows op beide hosts. Als ik write-back caching in wil schakelen geeft dat een foutmelding dat de SSD disk dit niet ondersteund. De MySQL machine draait nu alleen op host A en de wens is later om op Host B ook te draaien. De servers draaien niet op hoge load. Server A betreft een Dell PowerEdge R730xd en Server B betreft een Dell PowerEdge R740xd.

[ Voor 3% gewijzigd door zonderbloem op 18-02-2020 21:32 ]

[zonderbloem]

hans_lenze schreef op dinsdag 18 februari 2020 @ 10:27:
Stap 1: doe dit niet met CrystalDiskmark maar met een echte tool zoals Diskspd van Microsoft.
Stap 2: kijk in de documentatie van je applicatie naar de relevante informatie. Bijvoorbeeld https://dev.mysql.com/doc...ptimize-benchmarking.html
Stap 3: zorg ervoor dat je benchmark instellingen overeen komen met je applicatie (hint: 4k block size, 1 thread, 1 queue lijkt niet op MySQL)
Stap 4: voer je benchmark meerdere keren en op meerdere momenten uit, zodat je niet al je beslissingen van één meetpunt afhankelijk maakt waarop Truus de secretaresse druk bezig was ofzo.
Stap 5: bekijk alle resultaten naast elkaar in perspectief en vergeet de toekomstige wijzigingen in applicatie en/of dataformaat niet.
Stap 6: doe dit na elke patch, update of grote wijziging om een beeld te houden van je applicatie performance anders dan "het voelt wat trager vandaag".

Stap 3: zorg ervoor dat je benchmark instellingen overeen komen met je applicatie (hint: 4k block size, 1 thread, 1 queue lijkt niet op MySQL)
Dank voor je tips, ik ga morgen eens een uitgebreide benchmark doen met diskspd. Als ik nu een performance verschil van bijna 10x lager op Server B zie getest met thread 1 en queue 1 is dan niet de conclusie dat er iets aan de hand is met de disk performance? Op welke wijze zou ik moeten testen om MySQL IOps na te bootsen?

[Q]

zonderbloem schreef op dinsdag 18 februari 2020 @ 21:30:
[...]


Dit gaat om een kleine omgeving en binnen mijn bedrijf hebben we geen operations team/dev ops teams. Ik probeer erachter te komen waarom twee identieke VM's op Hyper-V op de ene server MySQL minder performance geeft dan de andere server. Het is exact dezelfde VM de test is gedaan buiten kantooruren dus er draaide verder geen IO intensieve scripts of aanvragen. Op server A haal ik met een CSV importeren 2400 inserts/sec en op server B maar 230 inserts/sec getest vanaf localhost. Beide servers zijn voorzien van alle updates en write-back cache staat niet ingesteld binnen Windows op beide hosts. Als ik write-back caching in wil schakelen geeft dat een foutmelding dat de SSD disk dit niet ondersteund. De MySQL machine draait nu alleen op host A en de wens is later om op Host B ook te draaien. De servers draaien niet op hoge load. Server A betreft een Dell PowerEdge R730xd en Server B betreft een Dell PowerEdge R740xd.

Helder verhaal. Zijn ook de SSDs gelijk in beide servers (type/model/firmware/merk/SATA/SAS/NVME)? Draaien de SSDs in RAID en is er een verschil in configuratie tussen de controllers? Kan misschien de batterij van de RAID controller leeg zijn en daarom misschien roet in het eten gooien? Verschil in RAID configuratie? Denk aan RAID mode of stripe/chunk size? Mogelijk moet je een stukje dell management software installeren om de RAID te kunnen configureren/bekijken, als het er al niet op staat. Of via IPMI interface/DRAC.

Er moet gewoon een verschil tussen de servers zijn, en dat het al twee verschillende modellen zijn is interessant.

[ Voor 11% gewijzigd door Q op 18-02-2020 23:19 ]

[zonderbloem]

Ik heb zojuist wat benchmarks uitgevoerd met diskspd.exe van Microsoft. Onderstaand het overzicht tussen de twee servers. Ik heb op alle servers met -Sh 'disble both software caching and hardware write-caching' getest. Opvallend is dat met 1 queue en 1 thread de latency van JIM (server B ) een stuk lager is.

De dik gedrukte letters / onderstreepte tekst in onderstaande afbeelding heb ik getest met diskspd.exe zonder -sh parameter.

[Q]

Tja, dat wist je dankzij je eigen eerdere test met crystaldiskmark + je eigen dB test ook al?

Ik denk dat de antwoorden op de vragen die ik hier boven stel meer kans maken om de oorzaak van het verschil en de eventuele oplossing te achterhalen.

[Q]

Heb je het opgegeven?