performantie mssql database 2014

[Yarisken]

Hallo,

We hebben hier een database van ongeveer 40GB. Sommige transacties duren redelijk lang.
Ik was aan het kijken om de performantie te tunen en ik kwam uit op "in memory OLTP".

MSDN: In-Memory OLTP (In-Memory Optimization)

Zijn er mensen die hiermee ervaring hebben ?

[kelvin46]

1. De link waar je naar verwijst is bedoeld voor SQL 2016
2. Wat is redelijk lang.

Iets meer informatie geven mag wel. Waar draait de Server op? Welk OS is geïnstalleerd? Wat voor hardware is er aanwezig?

[Gomez12]

Om maar even in dezelfde trant als TS te blijven : ja, die mensen zijn er.

Je zal toch echt een heleboel meer moeten vertellen over wat er gebeurt en wat er ongewenst is voordat er iets zinnigs over valt te discussieren (en dan nog een heleboel meer voordat je op OLTP uitkomt maargoed).

Met een 40GB dbase zou mijn 1e blinde optimalisatie zijn : Stouw er 64 / 128 GB geheugen in zodat gewoon je hele dbase in memory past. Met de huidige geheugenprijzen kan er amper een uurtje consultancy vanaf en consultancy heeft minder effect.

Het probleem (zoals ik het bekijk) is een beetje : Als je serieus voor In-Memory OLTP in aanmerking kwam dan had je al een heel traject doorlopen en had je dat traject grofweg in je TS gepost.
Nu post je niets in je TS wat mij doet vermoeden dat je gegoogled hebt op slow sql-server oid en dat daaruit OLTP kwam.

[Yarisken]

Gomez12 schreef op donderdag 08 september 2016 @ 14:46:
Om maar even in dezelfde trant als TS te blijven : ja, die mensen zijn er.

Je zal toch echt een heleboel meer moeten vertellen over wat er gebeurt en wat er ongewenst is voordat er iets zinnigs over valt te discussieren (en dan nog een heleboel meer voordat je op OLTP uitkomt maargoed).

Met een 40GB dbase zou mijn 1e blinde optimalisatie zijn : Stouw er 64 / 128 GB geheugen in zodat gewoon je hele dbase in memory past. Met de huidige geheugenprijzen kan er amper een uurtje consultancy vanaf en consultancy heeft minder effect.

Het probleem (zoals ik het bekijk) is een beetje : Als je serieus voor In-Memory OLTP in aanmerking kwam dan had je al een heel traject doorlopen en had je dat traject grofweg in je TS gepost.
Nu post je niets in je TS wat mij doet vermoeden dat je gegoogled hebt op slow sql-server oid en dat daaruit OLTP kwam.

De server draait virtueel op windows server 2012 R2 op een esxi machine met onderliggend netapp storage. Geen flash.

Een test van dezelfde database en een upload met een lokale SSD schijf geeft ongeveer 20seconden dat de upload duurt. Op ons systeem duurt het ongeveer een minuut.
Ik was aan het zoeken naar een mogelijkheid om de server in memory te draaien, zoals jij aangeeft. Ik kwam , via google, ook uit op in memory oltp. Onderliggen op SSD schijf is nu niet mogelijk.
Ik zal er is 64GB in stouwen :-)

[Xiphalon]

Ik zou eens gaan meten.

Er kunnen een aantal verschillende bottlenecks zijn, die moet je eerst uitzoeken en oplossen. Zomaar willekeurig oplossingen er tegen aangooien is vaak een recept voor meer problemen. Al dan niet later als niemand meer de configuratie begrijpt en er niet meer aan durft te zitten.

[Montaner]

Hoeveel geheugen heeft je machine? Hoeveel CPU's? Wat is de overige load terwijl je dit aan het doen bent? Welke acties voer je uit? Heb je je queryplan al bekeken? Je geeft tot op heden echt waardeloze informatie.

[Question Mark]

Yarisken schreef op donderdag 08 september 2016 @ 14:38:
Ik was aan het kijken om de performantie te tunen

Waar zit je huidige bottleneck nu?

hint: meten is weten

[sig69]

Yarisken schreef op donderdag 08 september 2016 @ 22:16:
[...]

Een test van dezelfde database en een upload met een lokale SSD schijf geeft ongeveer 20seconden dat de upload duurt. Op ons systeem duurt het ongeveer een minuut.

Uh? Wat? Upload?

Ik zal er is 64GB in stouwen :-)

Geheugen kost geen drol dus dat is de makkelijkste en goedkoopste optie. Hou wel in je achterhoofd dat het misschien geen enkel verschil maakt.

[Yarisken]

Het gaat over het inladen van data. Mijn vermoeden is gewoon tekort aan I/O maar ik zal eerst, zoals hier al gezegd, eens gaan meten :-).
Ik ben geen dba'er dus voor mij is het uitzoeken.
Ik kom hier nog op terug als ik resultaten heb van mijn metingen.