IDS Forum

Re: Optimizing IDS for SSD

Posted By: Richard Kofler
Date: Monday, 11 July 2016, at 1:30 p.m.

In Response To: Optimizing IDS for SSD (ANTHONY LANDRY)

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

Messages In This Thread

• Optimizing IDS for SSD
  ANTHONY LANDRY -- Monday, 11 July 2016, at 11:03 a.m.
  • Re: Optimizing IDS for SSD
    Madison Pruet -- Monday, 11 July 2016, at 12:28 p.m.
  • Re: Optimizing IDS for SSD
    Richard Kofler -- Monday, 11 July 2016, at 1:30 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.