[progress Communities] [progress Openedge Abl] Forum Post: Re: Io Response Discussion

  • Thread starter Thread starter ChUIMonster
  • Start date Start date
Status
Not open for further replies.
C

ChUIMonster

Guest
There's no real point to doing unbuffered reads. ProTop's ioResponse metric is in milliseconds. A SAN is bad for reads because the data is at the wrong end of a cable. The only way to get around the physics of that cable (and the inevitable latency thereof) is to eliminate the cable and use *internal* storage. The best option today is some sort of PCIe SSD option -- that's where those numbers Paul shared with io response of 0.1ms come from. (That system has a FusionIO PCIe card in it). The second best option is a plain old SSD sitting in a drive bay. A long time ago rotating rust was very slow, physically large, of limited capacity and they were expensive. You could only put so much capacity inside a server. In those days the added latency from being at the wrong end of a cable was outweighed by being able to spread the IO across many devices as well as by the fact that the latency was a *much* smaller proportion of the overall IO operation. So SANs were the best that we could do for a while. In today's world a *cheap* SSD can do 200,000 IO ops per second. If those IO ops are at the other end of a cable the overwhelming majority of the time that it takes to get a response is the the latency going across that cable (and through the various disk adapter layers and other shenanigans inside the SAN...) That cheap SSD is also probably more than big enough to hold your database. It does not help to have SSD inside your SAN. That is the wrong place for it and it does not suddenly make your random IO 100x faster. Basically all that does is transfer a large sum of money from your company to the SAN vendor. For database workloads fancy tiered storage is sometimes slightly faster than less fancy SANs. *Slightly* faster. Sometimes. Database read operations are *random*. So it doesn't help to be able to stream sequential data over that cable at gigabits per second -- which is what your network guy probably pays attention to. Copying a file is a streaming sort of operation -- you pay for the latency *once*, with the first block. So it doesn't matter. But with random access you pay for the latency with each and every operation. If you have a database that is constrained by IO (IOW you have already tuned -B and you have reasonably well written queries) the simplest and most cost effective thing that you can do to improve performance is to put the db on an *internal* SSD. It's the closest thing to magic that your users are likely to ever see.

Continue reading...
 
Status
Not open for further replies.
Back
Top