large disks

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?