Optimizing IDS for SSD

Does anyone know of plans by IBM to have an optimize_for_SSD switch in the onconfig? The reason that I ask is that it seems that many of the issues that we've traditionally dealt with become moot once the engine truly understand the performance implications of SSD. Do we still care about read ahead pages? Since we're no longer waiting for disks to spin into place, my assumption is that there is no read head reorientation gain? How might SSDs with close to zero latency affect my choices for polling threads and CPU VPs? Since we can now have LUNs with hundreds of thousands of IOPS, should we consider defining our disks raw, but no longer care about defining as many chunks? e.g. Is it reasonable to create an entire database on a single raw chunk because that raw chunk has the IOPS to handle the queries? I'm thinking about a single chunk for data and another for indexes in a 300+ table 3TB database. Is that a bad thought? Thanks!

You might not care about read ahead pages quite as much, but you still want them for optimal performance. Even with SSD, the CPU is still faster than the channel transfer rate. So if you have queries that are doing sequential scans, you'd still be able to keep the CPU 100% busy examining the rows by using read ahead. I would still have more than two chunks because I would want as much parallelism during the checkpoints. I'd consider having at least as many chunks that will be getting dirty as I had CPUs. Madison Pruet Retired and Loving it On Monday, July 11, 2016 7:05 AM, ANTHONY LANDRY <tony@clerk.org> wrote: Does anyone know of plans by IBM to have an optimize_for_SSD switch in the onconfig? The reason that I ask is that it seems that many of the issues that we've traditionally dealt with become moot once the engine truly understand the performance implications of SSD. Do we still care about read ahead pages? Since we're no longer waiting for disks to spin into place, my assumption is that there is no read head reorientation gain? How might SSDs with close to zero latency affect my choices for polling threads and CPU VPs? Since we can now have LUNs with hundreds of thousands of IOPS, should we consider defining our disks raw, but no longer care about defining as many chunks? e.g. Is it reasonable to create an entire database on a single raw chunk because that raw chunk has the IOPS to handle the queries? I'm thinking about a single chunk for data and another for indexes in a 300+ table 3TB database. Is that a bad thought? Thanks! ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Am 11.07.2016 17:03, schrieb ANTHONY LANDRY: > Does anyone know of plans by IBM to have an optimize_for_SSD switch in the > onconfig? > > The reason that I ask is that it seems that many of the issues that we've > traditionally dealt with become moot once the engine truly understand the > performance implications of SSD. > > Do we still care about read ahead pages? Since we're no longer waiting for > disks to spin into place, my assumption is that there is no read head > reorientation gain? > > How might SSDs with close to zero latency affect my choices for polling > threads and CPU VPs? > > Since we can now have LUNs with hundreds of thousands of IOPS, should we > consider defining our disks raw, but no longer care about defining as many > chunks? e.g. Is it reasonable to create an entire database on a single raw > chunk because that raw chunk has the IOPS to handle the queries? > > I'm thinking about a single chunk for data and another for indexes in a 300+ > table 3TB database. Is that a bad thought? > > Thanks! > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > Here is what I have found in the past, using INFORMIX 11.5 to 12.10.xC6 and benchmarking it on SSD setups of many a kind. - there is no such thing as zero latency. - it depends on details like - what is your operating system and how clever is you I/O system's scheduler - what type of SSDs we talking about - how are the SSDs connected (SAN via fibre channel, iSCSI and what not ... vs direct attachment to your hopefully 2 or 3 PCIe Gen3 controllers, 16 lanes each) - how fast is your main memory, how many memory channels you have to access memory in parallel and full duplex - are you running the database(s) in one or more VMs or containers? - how fast is your Hypervisor when it comes to I/O - on enterprise all-SSD-systems I HAVE SEEN RAID 5 and RAID 6 which is horrible. Art can & will tell more about this - if not using a form of raw type access, you will see latency of a file system or block access layer. You might even see updates of your metadata on the file access layer(s) for accessing and recording the last access time (1++ writes per read! in the subsystem) this list goes on and on and on ..... - speaking about LUNs: every LUN gives you a buffer/window to queue open (that is started, but not finished) I/O requests. If the window is full your application (here: INFORMIX) has to wait. Therefore more LUNs is better until you have enough LUNs. Too many LUNs is not as good, as every LUN needs some housekeeping activity, what needs the Kernal running on a CPU thread. Summary: Without very many details, I am not able to hint you what you have to test and how to test to see reality. Reality in contrast to marketing bli-blub sometimes is looking nasty. As a matter of fact, INFORMIX cached reads from the bufferpool in all cases I investigated were faster by a magnitude or more when compared to real fast, direct and easy SSD setups. Yes, I also tested setups having read speeds of 4x 80K IOPS in the datasheet. It still is a fairly complicated matter, how fast you will run when you are I/O bound or have indetified I/O bottlenecks dic_k --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus