SEO

Solaris 2.8, IDS 9.30.UC6W1, Enterprise 6000. We have a new SunFire 6800 and are in the process of ordering 2 3510 storage arrays. We plan to be on 64 bit 9.4x, Solaris 9 before moving to the new server. What is the best way to lay out these large disks - stipe and mirror? Currently, we have a ton of old 2 gig disks with a few 18 and 32s thrown in. We don't have the current disks striped but do have access to Veritas. We are not using nor plan to use RAID5 and will probably go with hardware mirroring. I have the opportunity to start with fresh hardware and would greatly value any suggestions or lessons learned.

sending to informix-list

Well ----

Since you are going to be moving to 9.4, you could just put the whole thing
into a single chunk.... ;-) (Guess you can't tell that I worked on that a
while back...);-)

While I'm being a bit silly, there is some truth to saying this. We've
tried through the years to use all kinds of algorithms to schedule IO.
However, with more recent disk technology, this type of logic a bit
unnecessary. So by putting more in a single larger chunk might actually
lessen the impact of the software IO scheduling by chunk. But that might be
offset by the hardware IO scheduling.

M.P.
"Campbell, John (GE Consumer Finance)" <John.Campbell2@ge.com> wrote in
message news:c013es$akm$1@terabinaries.xmission.com...
>
> Solaris 2.8, IDS 9.30.UC6W1, Enterprise 6000. We have a new SunFire 6800
and are in the process of ordering 2 3510 storage arrays. We plan to be on
64 bit 9.4x, Solaris 9 before moving to the new server. What is the best way
to lay out these large disks - stipe and mirror? Currently, we have a ton
of old 2 gig disks with a few 18 and 32s thrown in. We don't have the
current disks striped but do have access to Veritas. We are not using nor
plan to use RAID5 and will probably go with hardware mirroring. I have the
opportunity to start with fresh hardware and would greatly value any
suggestions or lessons learned.
>
> sending to informix-list

"Madison Pruet" <mpruet@comcast.net> wrote in message
news:4tVUb.241751$na.398369@attbi_s04...
> Well ----
>
> Since you are going to be moving to 9.4, you could just put the whole
thing
> into a single chunk.... ;-) (Guess you can't tell that I worked on that a
> while back...);-)
>
> While I'm being a bit silly, there is some truth to saying this. We've
> tried through the years to use all kinds of algorithms to schedule IO.
> However, with more recent disk technology, this type of logic a bit
> unnecessary. So by putting more in a single larger chunk might actually
> lessen the impact of the software IO scheduling by chunk.

Isn't it likely that the level of indirection introduced by striping will
negate this effect?

Maybe. I haven't fully thought through the problem. Nor have I bench
marked the configurations.

But I do suspect that things such as striping get in the way of all of the
IO scheduling logic that we have in place. So by using a single larger
chunk, basically we should be eliminating the scheduling that we are doing
and thus relying only on the disk scheduling.

There might be a negative side, however, because we might want to pump
through more concurrent IOs. Not sure...



"Neil Truby" <neil.truby@ardenta.com> wrote in message
news:c0189i$11torf$1@ID-162943.news.uni-berlin.de...
> "Madison Pruet" <mpruet@comcast.net> wrote in message
> news:4tVUb.241751$na.398369@attbi_s04...
> > Well ----
> >
> > Since you are going to be moving to 9.4, you could just put the whole
> thing
> > into a single chunk.... ;-) (Guess you can't tell that I worked on that
a
> > while back...);-)
> >
> > While I'm being a bit silly, there is some truth to saying this. We've
> > tried through the years to use all kinds of algorithms to schedule IO.
> > However, with more recent disk technology, this type of logic a bit
> > unnecessary. So by putting more in a single larger chunk might actually
> > lessen the impact of the software IO scheduling by chunk.
>
> Isn't it likely that the level of indirection introduced by striping will
> negate this effect?
>
>

Madison Pruet wrote:
>
> Well ----
>
> Since you are going to be moving to 9.4, you could just put the whole thing
> into a single chunk.... ;-) (Guess you can't tell that I worked on that a
> while back...);-)
>
> While I'm being a bit silly, there is some truth to saying this. We've
> tried through the years to use all kinds of algorithms to schedule IO.
> However, with more recent disk technology, this type of logic a bit
> unnecessary. So by putting more in a single larger chunk might actually
> lessen the impact of the software IO scheduling by chunk. But that might be
> offset by the hardware IO scheduling.
>
> M.P.
> "Campbell, John (GE Consumer Finance)" <John.Campbell2@ge.com> wrote in
> message news:c013es$akm$1@terabinaries.xmission.com...
> >
> > Solaris 2.8, IDS 9.30.UC6W1, Enterprise 6000. We have a new SunFire 6800
> and are in the process of ordering 2 3510 storage arrays. We plan to be on
> 64 bit 9.4x, Solaris 9 before moving to the new server. What is the best way
> to lay out these large disks - stipe and mirror? Currently, we have a ton
> of old 2 gig disks with a few 18 and 32s thrown in. We don't have the
> current disks striped but do have access to Veritas. We are not using nor
> plan to use RAID5 and will probably go with hardware mirroring. I have the
> opportunity to start with fresh hardware and would greatly value any
> suggestions or lessons learned.
> >
> > sending to informix-list

Anyone should better wait for 9.40.UC4 before turning on the
large chunk feature using onmode -BC

With the Linux version there is a reported problem with utilities and
the syspthhdr table, which will be solved in 9.40.UC4.

We did not test if this also is a feature of the Solaris versions,
but here is an outline for a simple test setup:

- create a dbspace with a chunk > 2GB
- create & populate a table therein
- do more than one inplace ALTER (we did 1 rename column,
then we did add some new columns)
so that you have 3 metadat-versions with all pages in version 0,
no pages in version 1, and no pages in version 2.
and here you are: look into oncheck -pe output, if you can see any
information about this very chunk.
Check sysptnhdr and friends
Try to do a dummy update to have your tables pages in version 0
and have a single page version only.

We stopped our migration at this point and are waiting for 9.40.UC4

Sorry that I do not have the case# ready here.

Apart from this mentioned finding, I had no trouble at all
with the big chunks in 3 weeks of testing.

On the other hand, I personally do not find it
more elegant to use the large chunk feature, as I used
very huge dbspaces based on 2GB chunks for a very long
time, but this may be a matter of taste.

This is the configuration we tested on:
V9.40.UC2 on SuSE 8.2 (with upgrading to glib 3.5.9) on
a PeeCee having 2 Escalade controllers from www.3ware.com,
1 configured to a RAID5 (1 spare, 3+1 160 GB) and
1 configured to a RAID10 (2 times 1+1 160 GB) long thin
stipes, stripe size 1 MB

*very* nice performance for the EURO, as the
PC including 9 x 160 GB was 4K EURO + vat.

Better read performance from reading off 3 disks
from RAID5 (reading from 3 disks on Raid5 vs. reading
from 2 disks from RAID10 due to the configuration)
Read performance ratio was - like expected - 3:2
in abs figures: 118 MB/sec:81 MB/sec or
59.000 pages/sec : 40.500 pg/sec
[note: read ahead is 4 pages]

heavy write penalty when writing to the RAID5 -
as expected, like 3:1

Will be able to test on a 3x(1+1) RAID10 of 250 GB
disks very soon.

And now the message after all this brabbelling:

The performance did not change on either way
comparing large chunks to 2B chunks. Tables
sitting in large chunks had almost exactly the
same lsc pg/sec thruput, and reading index based
in such way, that we pulled the table like this:
1st pg, last pg, pg 2, pg n-1 and so forth.....
also had the same performance.

But then, if you *really* are in for performance
you must go for SOLID STATE disks and nothing else.


dic_k
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe

"Richard Kofler" <richard.kofler@chello.at> wrote in message
news:4024A3A8.55CCC976@chello.at...

>> Anyone should better wait for 9.40.UC4 before turning on the
> large chunk feature using onmode -BC
>
> With the Linux version there is a reported problem with utilities and
> the syspthhdr table, which will be solved in 9.40.UC4.

Do you have the bug number?
From my own experience 9.40 is worth waiting for because it is said to fix
two bugs we found in our testing:
- slow index builds on a no-logging database and, more importantly:
- reversion from 9.4 fails

> On the other hand, I personally do not find it
> more elegant to use the large chunk feature, as I used
> very huge dbspaces based on 2GB chunks for a very long
> time, but this may be a matter of taste.

This is my view too. However, Jonathan Leffler posted an interesting
contribution a few weeks ago proposing that larger chunks will equate toi
superior i/o performance for certain types of query/operation.

I need to emphasize that I have not tested this idea and have no idea if it
is a good idea or not. At this point, it is just a thought. I haven't
tested it at all.

M.P.
"Madison Pruet" <mpruet@comcast.net> wrote in message
news:4tVUb.241751$na.398369@attbi_s04...
> Well ----
>
> Since you are going to be moving to 9.4, you could just put the whole
thing
> into a single chunk.... ;-) (Guess you can't tell that I worked on that a
> while back...);-)
>
> While I'm being a bit silly, there is some truth to saying this. We've
> tried through the years to use all kinds of algorithms to schedule IO.
> However, with more recent disk technology, this type of logic a bit
> unnecessary. So by putting more in a single larger chunk might actually
> lessen the impact of the software IO scheduling by chunk. But that might
be
> offset by the hardware IO scheduling.
>
> M.P.
> "Campbell, John (GE Consumer Finance)" <John.Campbell2@ge.com> wrote in
> message news:c013es$akm$1@terabinaries.xmission.com...
> >
> > Solaris 2.8, IDS 9.30.UC6W1, Enterprise 6000. We have a new SunFire 6800
> and are in the process of ordering 2 3510 storage arrays. We plan to be
on
> 64 bit 9.4x, Solaris 9 before moving to the new server. What is the best
way
> to lay out these large disks - stipe and mirror? Currently, we have a ton
> of old 2 gig disks with a few 18 and 32s thrown in. We don't have the
> current disks striped but do have access to Veritas. We are not using nor
> plan to use RAID5 and will probably go with hardware mirroring. I have
the
> opportunity to start with fresh hardware and would greatly value any
> suggestions or lessons learned.
> >
> > sending to informix-list
>
>