IDS Forum

Re: IDS 11 on a RedHat VM

Posted By: Art Kagel
Date: Monday, 7 July 2014, at 8:17 a.m.

In Response To: Re: IDS 11 on a RedHat VM (Keith Simmons)

There is some slight improvement in overhead by dividing the SAN structure
into multiple luns on the SAN rather than using a software based LVM to
create the multiple LVs.

Best practice though would be to not use a single massive array but to
break it into three or four arrays so you can isolate high volume tables,
indexes, and logs from each other onto separate sets of spindles and carve
the luns from these. That you you can keep logical and physical log IO
away from each other (since they happen concurrently) as well as your high
volume tables and indexes from the logs and from each other. Lower IO
volume objects can be spread across the four arrays. If your transaction
rates are VERY high, you can spread the logical logs across two luns from
different structures and alternate assigning log files between them so that
while a log file on one lun is being backed up transactions are writing to
a different lun and not competing for throughput or head position.

Now, obviously, if your IO volume isn't high, this isn't an issue, but
since you were performing throughput testing, I'll assume that your
transaction rate is significant.

Art

Art S. Kagel, Principal Consultant
ASK Database Management

Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on the IIUG, nor any other organization with which I am
associated either explicitly, implicitly, or by inference. Neither do
those opinions reflect those of other individuals affiliated with any
entity with which I am affiliated nor those of the entities themselves.

On Mon, Jul 7, 2014 at 4:29 AM, Keith Simmons <smiley73@gmail.com> wrote:

> Art
>
> Many thanks for your insight on this. One further question, if we get some
> bare metal the disk will still come from a SAN, is it best to still allow
> this to be presented as a single 1 Tb disk or as mutiple, smaller disks
> (I've still inclined towards 10 x 100 Gb).
>
> Keith
>
> On 4 July 2014 19:29, Art Kagel <art.kagel@gmail.com> wrote:
>
> > Keith, this is EXACTLY the behavior I would expect from a VM, especially
> an
> > ESX 4 VM. I did extensive testing for a client several years ago on the
> > same systems and not only is the IO throughput fixed on a single VM no
> > matter how many threads are writing to/reading from the disk(s) but on a
> > HUGE machine running multiple VMs gets you the same total throughput
> across
> > all VMs with the average total throughput about the same as the rated
> > throughput of a single 10K spindle and I was testing against RAID10
> arrays
> > with ten 10K drive pairs.
> >
> > Reports from the client since those test indicate that after working with
> > VMWare and EMC^2 for over a year are that if you run the VMs over the
> > vSphere Hypervisor the IO throughput about doubles but is still nailed
> to a
> > ceiling.
> >
> > My recommendation has always been and continues to be that you run
> > Informix, and all databases, on an OS that is running on bare metal.
> >
> > Art
> >
> > Art S. Kagel, Principal Consultant
> > ASK Database Management
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and do not reflect on the IIUG, nor any other organization with which I
> am
> > associated either explicitly, implicitly, or by inference. Neither do
> > those opinions reflect those of other individuals affiliated with any
> > entity with which I am affiliated nor those of the entities themselves.
> >
> > On Fri, Jul 4, 2014 at 12:24 PM, Keith Simmons <smiley73@gmail.com>
> wrote:
> >
> > > Hi all
> > >
> > > We are currently in the process of migrating an 850 (ish) Gb database
> > from
> > > AIX 5/IDS9.4 to a vm server (ESX 4) running Red hat
> > > 2.6.32-431.3.1.el6.x86_64/IDS 11.70.FC7.
> > > New server has the same numbers of CPUs, identical memory and the same
> > > amount of disk.
> > >
> > > Shifting the data across from the existing machine to new one is being
> > doen
> > > by multiple streams of 'UNLOAD TO `pipe` SELECT * FROM' combined with
> > > 'DBLOAD', plus a single stream of ' SELECT * FROM INSERT INTO' for 300
> > > smaller tables (there are around 30 large tables in 6 unload streams).
> > >
> > > Source and target machines are in the same subnet and have 1Gb end to
> end
> > > network plus the data source is an HDR secondary which is NOT used for
> > any
> > > other purpose (such as read-only queries).
> > >
> > > Basically the load performance sucks on anything more than a single
> > stream
> > > and when we have managed a full load, initial testing of the
> application
> > > returns abysmal performance.
> > >
> > > The disks on the source are not stressed in any way (around 25%
> > > utilisation) but the disks on the new server are constantly at 100% but
> > can
> > > only seem to shift some 10 Mb/s.
> > >
> > > The main structural difference between the machines seems to be how the
> > > disk is presented and I am trying to find out what is considered 'best
> > > practise' or how to get some decent performance. The existing server
> has
> > > direct attached (2Gb fibre, redundant path) storage presenting as 27 x
> > 36Gb
> > > disks which are then carved up by AIX LVM into 4 and 8 Gb chunks and
> > > assigned to dbspaces. On the new server there is 1 Tb of SAN disk
> > presented
> > > through a parascsi adapter to the server as a single disk (/dev/sde)
> > which
> > > is then carved up by the RedHat LVM. When loading the data, no matter
> how
> > > many streams run or how many chunks are being hit, the overall
> thoughput
> > > seems to be topping out at 10 Mb/sec.
> > >
> > > I suppose my queston is, is this the best way of presenting this amount
> > of
> > > disk or would it be better to get 10 x 100Gb disks, treat them as
> > separate
> > > spindles and divide the data/indexing between them as I would do on
> > > tranditionally attached disk. Any thoughts, comments, suggestions
> > > gratefully received.
> > >
> > > Keith
> > >
> > > ps I only have limited, view accessto the VM environment as it is
> managed
> > > for us but I do hve full root access to the RedHat environment, I have
> no
> > > visibility on the SAN.
> > >
> > > --089e0115f5183fa01f04fd608efb
> > >
> > >
> > >
> > >
> >
> >
>
> *******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --001a1133a628e0faad04fd624c94
> >
> >
> >
> >
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --047d7bdc1a9ca3739104fd9646b8
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>

--089e0158c29c99771b04fd99764d

Messages In This Thread

• IDS 11 on a RedHat VM
  Keith Simmons -- Friday, 4 July 2014, at 12:24 p.m.
  • Re: IDS 11 on a RedHat VM
    Art Kagel -- Friday, 4 July 2014, at 2:29 p.m.
    • Re: IDS 11 on a RedHat VM
      JON RITSON -- Saturday, 5 July 2014, at 12:51 p.m.
      • Re: IDS 11 on a RedHat VM
        Keith Simmons -- Monday, 7 July 2014, at 3:52 a.m.
    • Re: IDS 11 on a RedHat VM
      Keith Simmons -- Monday, 7 July 2014, at 4:29 a.m.
      • Re: IDS 11 on a RedHat VM
        Art Kagel -- Monday, 7 July 2014, at 8:17 a.m.
        • Re: IDS 11 on a RedHat VM
          rroussey@comcast.net -- Monday, 7 July 2014, at 10:38 a.m.
  • Re: IDS 11 on a RedHat VM
    ERIC VERCELLETTO -- Monday, 14 July 2014, at 1:20 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.