PUPPLESAN

Distinguished
Dec 20, 2012
20
0
18,510
0
Hi. Please forgive the ignorance.

I want to use an Optane 905p PCIe card on a new build onto an MSI MEG Z390 GODLIKE LGA1151/i9 9900k. In addition to Optane, it will have a 970 Evo Plus 2Tb in M.2 with 32 Gb ram. The question is how should I configure the Optane to best enhance performance? Should it (Optane 905p) be the boot drive? If not, then how SHOULD I configure it. OR... am I totally failing to understand how Optane works?

Thank you very much.
 

USAFRet

Titan
Moderator
Mar 16, 2013
119,539
3,160
159,340
19,360
Sorry: 960 Gb, database server for small medical office, yes (respectively). Thanks
I would probably use the 970 for your OS and all applications (incl the database software).
The Optane for the actual database file(s).

Intel made a big mistake in the naming of the whole optane thing.
There are cache modules, typically 16 or 32GB. Used to be a cache drive for a large HDD.
Then there are actual drive, such as you have. To be used as a drive in its own right.

A bit confusing.
 

PUPPLESAN

Distinguished
Dec 20, 2012
20
0
18,510
0
Confusing indeed. But thank you. I have my doubts whether we'll see any real world improvement in performance (over not using Optane) but I have read that some DBAs use it (Optane) and think it helps. Again, thank you.
 

USAFRet

Titan
Moderator
Mar 16, 2013
119,539
3,160
159,340
19,360
Confusing indeed. But thank you. I have my doubts whether we'll see any real world improvement in performance (over not using Optane) but I have read that some DBAs use it (Optane) and think it helps. Again, thank you.
Right.

You'd have to run 2 identical systems side by side...1 with 970 + 905p and 1 with 970 + 970.
Even then, any difference would only be seen with a LARGE DB workload.
 

PUPPLESAN

Distinguished
Dec 20, 2012
20
0
18,510
0
@USAFRet: We've upgraded to 10 gbase-t and that actually helped a lot because we do have a lot of traffic sometimes. But the other problems is latency and I just thought that maybe Optane could serve it up faster. It will be interesting to see.
 

Maxxify

Distinguished
Aug 12, 2007
332
60
18,990
29
It will be insanely fast for your usage. I've worked with medical systems where there's tons of small files that need to be accessed or processed with minimal delay, and yes latency is the largest factor there, particularly at low queue depth. Whether or not you'd be bottlenecked in noticeable terms by a NAND-based NVMe drive is a different discussion.
 

PUPPLESAN

Distinguished
Dec 20, 2012
20
0
18,510
0
It will be insanely fast for your usage. I've worked with medical systems where there's tons of small files that need to be accessed or processed with minimal delay, and yes latency is the largest factor there, particularly at low queue depth. Whether or not you'd be bottlenecked in noticeable terms by a NAND-based NVMe drive is a different discussion.
Exactly! Every patient visit pulls 142-370 different tables together. Many of them are very, very narrow (few columns) but every patient has a record that has to be queried from each table. DBAs tell me I write bad databases but they may not fully grasp just how much data a doctor needs to see on a single screen at every visit and how unacceptable long lags are to the doctor-patient relationship. Anyway, thanks for the encouragement!
 

USAFRet

Titan
Moderator
Mar 16, 2013
119,539
3,160
159,340
19,360
Exactly! Every patient visit pulls 142-370 different tables together. Many of them are very, very narrow (few columns) but every patient has a record that has to be queried from each table. DBAs tell me I write bad databases but they may not fully grasp just how much data a doctor needs to see on a single screen at every visit and how unacceptable long lags are to the doctor-patient relationship. Anyway, thanks for the encouragement!
Bad DB construction will absolutely impact response. 400 tables is not out of the realm of possibility, but can be an indication of a poorly designed DB.

If that's what you have to work with, fine. Deal with it.
But I've seen far too many such constructions that choke on their own shoelaces, and should be done better. That, however, can cost real money.

And when faced with crappy design, the response time between an Optane and a good NVMe drive may be minimal.
The Optane won't hurt, though.
 

PUPPLESAN

Distinguished
Dec 20, 2012
20
0
18,510
0
Bad DB construction will absolutely impact response. 400 tables is not out of the realm of possibility, but can be an indication of a poorly designed DB.

If that's what you have to work with, fine. Deal with it.
But I've seen far too many such constructions that choke on their own shoelaces, and should be done better. That, however, can cost real money.

And when faced with crappy design, the response time between an Optane and a good NVMe drive may be minimal.
The Optane won't hurt, though.
Healthcare databases are probably better off abandoning SQL but we haven't yet had the courage to do that. We may have to. For the moment we have a chimera that shudders under its own weight and we're trying to keep it all functional. So far, so good. But yes, we have a monster on our hands.
 

ASK THE COMMUNITY