[SOLVED] Optane 905p PCIe: How to Use Best

[PUPPLESAN]

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]

What size is the Optane?
What do you use the system for?
Have you already purchased the Optane?

 

[PUPPLESAN]

Sorry: 960 Gb, database server for small medical office, yes (respectively). Thanks

 

[USAFRet]

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]

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]

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.

 

[Maxxify]

Optane is low latency and has incredible low queue depth performance which makes it very responsive for just about anything. Example. Also excellent steady state performance since the memory is write-in-place. And especially both.

 

[PUPPLESAN]

@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.

 

[PUPPLESAN]

Optane is low latency and has incredible low queue depth performance which makes it very responsive for just about anything. Example. Also excellent steady state performance since the memory is write-in-place. And especially both.

That's what attracted me to the idea (low latency).

 

[Maxxify]

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]

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]

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]

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.