By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,609 Members | 2,246 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,609 IT Pros & Developers. It's quick & easy.

Same software, different hardware and abominable performance

P: n/a
Hi,

I read a lot about DB2 INSERT performance here. I have a nice story as
well.

The thing is, I work on 2 installations of DB2 (on completely different
locations) which run on different (but same generation) hardware.
Benchmarking the disk throughput and CPU basically amounts to the same
figures (+/- 10%).

However, the INSERT performance on one server is 20x slower than on the
other ('slowest' server = fastest DB2 performance). And for the life of
me I can't understand why.

Both servers run 'Redhat ES 3 update 4' and 'DB2 8.1 FP9'. On both
servers I've done a clean install of DB2, followed by standard DB
creation, followed by my INSERT benchmark. Result: One server takes
9ms. for every insert, and the other one less than 0.5ms

Now I know there is a lot to tinker to improve performance, but first
I'd like to get the performance of a basic installation roughly the
same (furthermore, a lot of tinkering ammounts to no speed
improvement).

Can someone explain to me how it is possible that performance figures
on two basically equal DB2 installations (from DB and DBM, down to the
sysconf kernel parameters) can show such a difference? And can someone
point me in a direction to look for a solution? I'm sort of at my wits
end.

To make things worse I took an old crappy server from our scrapyard and
installed CentOS 3.3 and 'DB2 8.1 FP9' on it, and it outprerforms the
new server by 9-to-1.

While benchmarking the INSERTS I can see that the IOWAIT figures on
linux' 'top' are very high on the slowest performing server compared to
the fastest performing server. However, when running the disk benchmark
'bonnie' I get roughly the same figures on both servers.

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?

Help?

Nov 12 '05 #1
Share this Question
Share on Google+
35 Replies


P: n/a
<sa*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi,

I read a lot about DB2 INSERT performance here. I have a nice story as
well.

The thing is, I work on 2 installations of DB2 (on completely different
locations) which run on different (but same generation) hardware.
Benchmarking the disk throughput and CPU basically amounts to the same
figures (+/- 10%).

However, the INSERT performance on one server is 20x slower than on the
other ('slowest' server = fastest DB2 performance). And for the life of
me I can't understand why.

Both servers run 'Redhat ES 3 update 4' and 'DB2 8.1 FP9'. On both
servers I've done a clean install of DB2, followed by standard DB
creation, followed by my INSERT benchmark. Result: One server takes
9ms. for every insert, and the other one less than 0.5ms

Now I know there is a lot to tinker to improve performance, but first
I'd like to get the performance of a basic installation roughly the
same (furthermore, a lot of tinkering ammounts to no speed
improvement).

Can someone explain to me how it is possible that performance figures
on two basically equal DB2 installations (from DB and DBM, down to the
sysconf kernel parameters) can show such a difference? And can someone
point me in a direction to look for a solution? I'm sort of at my wits
end.

To make things worse I took an old crappy server from our scrapyard and
installed CentOS 3.3 and 'DB2 8.1 FP9' on it, and it outprerforms the
new server by 9-to-1.

While benchmarking the INSERTS I can see that the IOWAIT figures on
linux' 'top' are very high on the slowest performing server compared to
the fastest performing server. However, when running the disk benchmark
'bonnie' I get roughly the same figures on both servers.

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?

Help?

So, what is the difference in the disk hardware?
Nov 12 '05 #2

P: n/a
sa*********@gmail.com wrote:
Hi,

I read a lot about DB2 INSERT performance here. I have a nice story as
well.

The thing is, I work on 2 installations of DB2 (on completely different
locations) which run on different (but same generation) hardware.
Benchmarking the disk throughput and CPU basically amounts to the same
figures (+/- 10%).

However, the INSERT performance on one server is 20x slower than on the
other ('slowest' server = fastest DB2 performance). And for the life of
me I can't understand why.

Both servers run 'Redhat ES 3 update 4' and 'DB2 8.1 FP9'. On both
servers I've done a clean install of DB2, followed by standard DB
creation, followed by my INSERT benchmark. Result: One server takes
9ms. for every insert, and the other one less than 0.5ms

Now I know there is a lot to tinker to improve performance, but first
I'd like to get the performance of a basic installation roughly the
same (furthermore, a lot of tinkering ammounts to no speed
improvement).

Can someone explain to me how it is possible that performance figures
on two basically equal DB2 installations (from DB and DBM, down to the
sysconf kernel parameters) can show such a difference? And can someone
point me in a direction to look for a solution? I'm sort of at my wits
end.

To make things worse I took an old crappy server from our scrapyard and
installed CentOS 3.3 and 'DB2 8.1 FP9' on it, and it outprerforms the
new server by 9-to-1.

While benchmarking the INSERTS I can see that the IOWAIT figures on
linux' 'top' are very high on the slowest performing server compared to
the fastest performing server. However, when running the disk benchmark
'bonnie' I get roughly the same figures on both servers.

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?

Help?

Disc controller? Check the batteries of the write memory.
We had that with a benchmark a while ago. Suddenly write performance
dropped because the drive I/O would be fully synchronized (smart card
though - instead of crapping out it did the best it could with what it
got).

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #3

P: n/a
The faster server has 2 mirrored disks on an on board SCSI controller
(Dell motherboard). The slower server uses a disk cabinet with raid 1+0
and its own SCSI controller to talk to the mother-board SCSI
controller.

Disk IO benchmark bonnie (FWIW) shows similar performance with a slight
advantage to the disk cabinet.

Nov 12 '05 #4

P: n/a
<sa*********@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
The faster server has 2 mirrored disks on an on board SCSI controller
(Dell motherboard). The slower server uses a disk cabinet with raid 1+0
and its own SCSI controller to talk to the mother-board SCSI
controller.

Disk IO benchmark bonnie (FWIW) shows similar performance with a slight
advantage to the disk cabinet.

Also check the registry variables. I think it is db2set -all (but not sure).
Nov 12 '05 #5

P: n/a
Well, the HW disk cache on the fastest server is off (default). The
crappy server I used to test locally (which is still 9x faster) also
off.

Does the linux-cache know about the HW cache of a SCSI controller?

Nov 12 '05 #6

P: n/a
The only thing that db2set -all returns (on all servers) is:

DB2COMM=tcpip

Nov 12 '05 #7

P: n/a
DB2 insert logic (greatly simplified) generally follows:
1. Update data in buffer pool
2. Write log record
3. Return to application with SQLCODE=0. Application continues at 1.
4. Write data from data pool asychronously, in bulk

If you are not tuned to support using delayed write with page cleaners
then each data block must be physically written out to disk before
returning to the application. This can easily show up as a 20:1 decrease
in performance. Check for tuning parameter differences between the systems.

Try running the job on both systems taking a database snapshot before
and after the job to see what is happening with I/O. Look carefully at
counts and average durations for synchronous and asynchronous I/O. You
will hopefully see differences that will head you down the right path to
correcting this.

Phil Sherman

sa*********@gmail.com wrote:
Hi,

I read a lot about DB2 INSERT performance here. I have a nice story as
well.

The thing is, I work on 2 installations of DB2 (on completely different
locations) which run on different (but same generation) hardware.
Benchmarking the disk throughput and CPU basically amounts to the same
figures (+/- 10%).

However, the INSERT performance on one server is 20x slower than on the
other ('slowest' server = fastest DB2 performance). And for the life of
me I can't understand why.

Both servers run 'Redhat ES 3 update 4' and 'DB2 8.1 FP9'. On both
servers I've done a clean install of DB2, followed by standard DB
creation, followed by my INSERT benchmark. Result: One server takes
9ms. for every insert, and the other one less than 0.5ms

Now I know there is a lot to tinker to improve performance, but first
I'd like to get the performance of a basic installation roughly the
same (furthermore, a lot of tinkering ammounts to no speed
improvement).

Can someone explain to me how it is possible that performance figures
on two basically equal DB2 installations (from DB and DBM, down to the
sysconf kernel parameters) can show such a difference? And can someone
point me in a direction to look for a solution? I'm sort of at my wits
end.

To make things worse I took an old crappy server from our scrapyard and
installed CentOS 3.3 and 'DB2 8.1 FP9' on it, and it outprerforms the
new server by 9-to-1.

While benchmarking the INSERTS I can see that the IOWAIT figures on
linux' 'top' are very high on the slowest performing server compared to
the fastest performing server. However, when running the disk benchmark
'bonnie' I get roughly the same figures on both servers.

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?

Help?

Nov 12 '05 #8

P: n/a
Sounds to me like its potentially the number of spindles, depending on
how many you have in the disk cabinet. Especially since you only have
2xdisks@RAID 1 on your newest server. Thats not alot of throughput,
especially if the OS sits on this too. How many drives have you got in
the disk cabinet and what are they? Does this server have seperate
areas for the OS and DB2?

Nov 12 '05 #9

P: n/a
The raid 1+0 has 4 disks (mirrored and striped). The OS and everything
else sits on a different disk. We designed the disk cabinet to have a
single physical raid 1+0 set for the database only. Optionally the logs
are written to their own physical raid set. This helps a little, but
still 20x slower than the other server, and 9x slower than the crappy
server.

We thought we had the setup rather well thought out...

Nov 12 '05 #10

P: n/a
I will check the DB snapshots. However, I'd expect similar behaviour
from two out-of-the-box (non-tweaked) simple installs. Or am I thinking
too simple now?

Nov 12 '05 #11

P: n/a
Ian
sa*********@gmail.com wrote:

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?


Are you sure your buffer pools are identical between the two databases?

Nov 12 '05 #12

P: n/a
Are you sure the DDL you use to set up the bench mark is running the
same? Are you adding any RI or check constraints? Are you placing any
tables in append mode or are there any MDC tables? Are there
differences in the tablespace DDL for SMS vs DMS,number of containers,
or page size and extentsize?

Nov 12 '05 #13

P: n/a
Out-of-the-box systems are notorious for exhibiting less than optimal
performance. Default tuning parameters are designed to virtually
guarantee the system will work on any hardware configuration but will
rarely yield adequate performance. RAID, and attached storage devices
are definitely areas where appropriate tuning is required to obtain the
performance that DB2 is capable of giving.

As mentioned in Ian's post (07/05, 11:11), buffer pool size will be a
significant factor.

I'd strongly recommend using DMS storage for RAID devices because you
can match DB2's use of physical disk storage to the hardware; making
optimum use of the performance capabilities of RAID. A bad mismatch here
can make a 2:1 difference in performance.

Phil Sherman
sa*********@gmail.com wrote:
I will check the DB snapshots. However, I'd expect similar behaviour
from two out-of-the-box (non-tweaked) simple installs. Or am I thinking
too simple now?

Nov 12 '05 #14

P: n/a
sa*********@gmail.com wrote:
Hi,


Are your sysctl settings in order?

-R-
Nov 12 '05 #15

P: n/a
Different MINCOMMIT can influence heavily batch results.

Bernard Dhooghe

sa*********@gmail.com wrote:
Hi,

I read a lot about DB2 INSERT performance here. I have a nice story as
well.

The thing is, I work on 2 installations of DB2 (on completely different
locations) which run on different (but same generation) hardware.
Benchmarking the disk throughput and CPU basically amounts to the same
figures (+/- 10%).

However, the INSERT performance on one server is 20x slower than on the
other ('slowest' server = fastest DB2 performance). And for the life of
me I can't understand why.

Both servers run 'Redhat ES 3 update 4' and 'DB2 8.1 FP9'. On both
servers I've done a clean install of DB2, followed by standard DB
creation, followed by my INSERT benchmark. Result: One server takes
9ms. for every insert, and the other one less than 0.5ms

Now I know there is a lot to tinker to improve performance, but first
I'd like to get the performance of a basic installation roughly the
same (furthermore, a lot of tinkering ammounts to no speed
improvement).

Can someone explain to me how it is possible that performance figures
on two basically equal DB2 installations (from DB and DBM, down to the
sysconf kernel parameters) can show such a difference? And can someone
point me in a direction to look for a solution? I'm sort of at my wits
end.

To make things worse I took an old crappy server from our scrapyard and
installed CentOS 3.3 and 'DB2 8.1 FP9' on it, and it outprerforms the
new server by 9-to-1.

While benchmarking the INSERTS I can see that the IOWAIT figures on
linux' 'top' are very high on the slowest performing server compared to
the fastest performing server. However, when running the disk benchmark
'bonnie' I get roughly the same figures on both servers.

My common sense tells me there are 2 possibilities: Disk hardware or
DB2. But DB2 is not that system-low-level right?

Help?


Nov 12 '05 #16

P: n/a
Yes, the bufferpools are exactly the same.

Nov 12 '05 #17

P: n/a
The sysctl settings are the same on both servers. I tested with the
standard (RHEL install sysctl) and the (IMO) DB2 enhancements:

kernel.msgmni = 1024
kernel.sem = 250 128000 32 1024
kernel.msgmax = 65536

with exactly the same results.

Nov 12 '05 #18

P: n/a
The MINCOMMIT is the same on both servers: 1. Any other setting in my
previous experiences makes things slower.

Nov 12 '05 #19

P: n/a
Phil, do you mean a GET SNAPSHOT FOR DB ... or a DBM snapshot?

Nov 12 '05 #20

P: n/a
>Are you sure the DDL you use to set up the bench mark is running the
same? Are you adding any RI or check constraints? Are you placing any
tables in append mode or are there any MDC tables? Are there
differences in the tablespace DDL for SMS vs DMS,number of containers,
or page size and extentsize?


Everything is the same:

install DB2 8.1 + FP9
CREATE DB ...
CREATE TABLE ...
run benchmark (java app or simple IMPORT FROM ...)

The crapy server is 9x faster than the new fast server.

I understand that tuning can make a difference, but this difference is
ridiculous, since both servers are 'out of the box'.

Nov 12 '05 #21

P: n/a
sa*********@gmail.com wrote:
Are you sure the DDL you use to set up the bench mark is running the
same? Are you adding any RI or check constraints? Are you placing any
tables in append mode or are there any MDC tables? Are there
differences in the tablespace DDL for SMS vs DMS,number of containers,
or page size and extentsize?

Everything is the same:

install DB2 8.1 + FP9
CREATE DB ...
CREATE TABLE ...
run benchmark (java app or simple IMPORT FROM ...)

The crapy server is 9x faster than the new fast server.

I understand that tuning can make a difference, but this difference is
ridiculous, since both servers are 'out of the box'.

Have you tried playing with the db2pd (aka DB2 version of onstats) tool?

Cheers
Serge
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #22

P: n/a
>Have you tried playing with the db2pd (aka DB2 version of onstats) tool?

I'm not familiar with that tool. We'll look into that. Mondat one of
your IBM-colleagues is passing by to try to help us on the matter.

Nov 12 '05 #23

P: n/a
sa*********@gmail.com wrote:
Phil, do you mean a GET SNAPSHOT FOR DB ... or a DBM snapshot?

Get snapshot for database - it shows counts for what has happened since
the database was started. The difference between the counts shows the
activity over the interval.

Phil Sherman
Nov 12 '05 #24

P: n/a
sa*********@gmail.com wrote:
The faster server has 2 mirrored disks on an on board SCSI controller
(Dell motherboard). The slower server uses a disk cabinet with raid 1+0
and its own SCSI controller to talk to the mother-board SCSI
controller.

Disk IO benchmark bonnie (FWIW) shows similar performance with a slight
advantage to the disk cabinet.

What's the blocksize of the RAID10 array versus the pagesize for the
database? If these are a mismatch it will cause extra physical IOs that are
wasted. Also, later you state that the caches on the two faster machines
are off and that the disk array cache is on. This can slow things because
DB2 will be writing to the drives in O_SYNC mode for safety and the forced
write cache flush is more expensive than the direct-to-disk write you are
getting on the other two machines with write cache off.

Art S. Kagel
Nov 12 '05 #25

P: n/a
sa*********@gmail.com wrote:
The faster server has 2 mirrored disks on an on board SCSI controller
(Dell motherboard). The slower server uses a disk cabinet with raid 1+0
and its own SCSI controller to talk to the mother-board SCSI
controller.

Disk IO benchmark bonnie (FWIW) shows similar performance with a slight
advantage to the disk cabinet.


Hi Sacha,
My 2 cents:
I am not familiar with the bonnie benchmark, but does it write records with
the same lengrth as DB2?
Also, could the disk of the slowest machine be fragmented?
Are you using DMS or SMS tablespaces?
--
Message posted via http://www.dbmonster.com
Nov 12 '05 #26

P: n/a
>Get snapshot for database - it shows counts for what has happened since
the database was started. The difference between the counts shows the
activity over the interval.


Ok, I did this. The most notable differences are all the write times.
For the tablespace that is being used the folowing was output:

Old written off DELL server:

Tablespace name = USERSPACE1
Tablespace ID = 2
Tablespace Type = System managed space
Tablespace Content Type = Any data
Tablespace Page size (bytes) = 4096
Tablespace Extent size (pages) = 32
Automatic Prefetch size enabled = Yes
Buffer pool ID currently in use = 1
Buffer pool ID next startup = 1
Using automatic storage = No
File system caching = Yes
Tablespace State = 0x'00000000'
Detailed explanation:
Normal
Tablespace Prefetch size (pages) = 32
Total number of pages = 5217
Number of usable pages = 5217
Number of used pages = 5217
Minimum Recovery Time =
Number of quiescers = 0
Number of containers = 1

Container Name =
/mnt/Seagate33G/db2inst1/NODE0000/SQL00001/SQLT0002.0
Container ID = 0
Container Type = Path
Total Pages in Container = 5217
Usable Pages in Container = 5217
Stripe Set = 0
Container is accessible = Yes

Buffer pool data logical reads = 103091
Buffer pool data physical reads = 10
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
Asynchronous pool data page reads = 0
Buffer pool data writes = 1642
Asynchronous pool data page writes = 621
Buffer pool index logical reads = 0
Buffer pool index physical reads = 0
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Asynchronous pool index page reads = 0
Buffer pool index writes = 0
Asynchronous pool index page writes = 0
Total buffer pool read time (millisec) = 0
Total buffer pool write time (millisec) = 1182
Total elapsed asynchronous read time = 0
Total elapsed asynchronous write time = 506
Asynchronous data read requests = 0
Asynchronous index read requests = 0
No victim buffers available = 109
Direct reads = 0
Direct writes = 8192
Direct read requests = 0
Direct write requests = 32
Direct reads elapsed time (ms) = 0
Direct write elapsed time (ms) = 211
Number of files closed = 0
Data pages copied to extended storage = 0
Index pages copied to extended storage = 0
Data pages copied from extended storage = 0
Index pages copied from extended storage = 0
For the new state-of-the-art IBM server:

Tablespace name = USERSPACE1
Tablespace ID = 2
Tablespace Type = System managed space
Tablespace Content Type = Any data
Tablespace Page size (bytes) = 4096
Tablespace Extent size (pages) = 32
Automatic Prefetch size enabled = Yes
Buffer pool ID currently in use = 1
Buffer pool ID next startup = 1
Using automatic storage = No
File system caching = Yes
Tablespace State = 0x'00000000'
Detailed explanation:
Normal
Tablespace Prefetch size (pages) = 192
Total number of pages = 2081
Number of usable pages = 2081
Number of used pages = 2081
Minimum Recovery Time =
Number of quiescers = 0
Number of containers = 1

Container Name =
/mnt/data/db2inst1/NODE0000/SQL00003/SQLT0002.0
Container ID = 0
Container Type = Path
Total Pages in Container = 2081
Usable Pages in Container = 2081
Stripe Set = 0
Container is accessible = Yes

Buffer pool data logical reads = 103063
Buffer pool data physical reads = 0
Buffer pool temporary data logical reads = 0
Buffer pool temporary data physical reads = 0
Asynchronous pool data page reads = 0
Buffer pool data writes = 2026
Asynchronous pool data page writes = 1005
Buffer pool index logical reads = 0
Buffer pool index physical reads = 0
Buffer pool temporary index logical reads = 0
Buffer pool temporary index physical reads = 0
Asynchronous pool index page reads = 0
Buffer pool index writes = 0
Asynchronous pool index page writes = 0
Total buffer pool read time (millisec) = 0
Total buffer pool write time (millisec) = 19226
Total elapsed asynchronous read time = 0
Total elapsed asynchronous write time = 9895
Asynchronous data read requests = 0
Asynchronous index read requests = 0
No victim buffers available = 670
Direct reads = 0
Direct writes = 8192
Direct read requests = 0
Direct write requests = 32
Direct reads elapsed time (ms) = 0
Direct write elapsed time (ms) = 3175
Number of files closed = 0
Data pages copied to extended storage = 0
Index pages copied to extended storage = 0
Data pages copied from extended storage = 0
Index pages copied from extended storage = 0
It is obvious from the "Total buffer pool write time", "Total elapsed
asynchronous write time" and "Direct write elapsed time" that the
supposedly new server is taking way more time than the ols server. Does
this mean the disk is the problem?

Nov 12 '05 #27

P: n/a
Hoi Anton,

It's SMS on all servers, not fragmented (freshly installed on empty
partitions).

I don't know if Bonnie uses 4K records, but probably not.

Could that amount in such a big difference?

Nov 12 '05 #28

P: n/a
I made the assumption that you did a fresh start of the database before
running the application and took these after running the application on
both.

1. Container sizes - It appears that the new system is only 40% as large
os the old system. SMS space grows as needed to hold the data. If you
are growing the space to handle inserts; then the data areas must be
formatted by udb before use. Constantly extending the space can add
significantly to execution time. If space is available on the old system
from prior (maybe months ago) deletes; then you don't have this time on
the old system.

2. Write times - The direct write numbers are significant. Both cases
had 32 requests that wrote 8192 physical (usually 512 byte) sectors or
256 sectors (128k) per request. The elapsed times differ enough to
indicate a problem with the new system's disk drives.

3. The new system had 25% more writes (buffer pool data writes) than the
old. Your description of the environment makes this a hint of tablespace
expansion too.

4. The asynchronous write data also indicates a disk problem. The old
system averaged .815ms for each of the asynchronous writes while the new
took 9.84ms for each.

5. No Victim Buffers Available - the higher number here for the new
system, when compared to the old system, indicates an overall slower
write process.

Another possible issue when measuring inserts is distribution of
freespace in the table. If the new system is freshly reorged and
compacted so there isn't room for inserts then each insert will cause
page splits further decreasing performance. Inserts at the end of a
table are a special case and are, to the best of my recollection,
handled with a special mechanism that avoids splits.

I'd take a long look at the connection between the new disks and the
system. It appears that its quite slow - especially when writing large
quantities of data (asynchronous writes).

Phil Sherman

sa*********@gmail.com wrote:
Get snapshot for database - it shows counts for what has happened since
the database was started. The difference between the counts shows the
activity over the interval.

Ok, I did this. The most notable differences are all the write times.
For the tablespace that is being used the folowing was output:

Nov 12 '05 #29

P: n/a
sa*********@gmail.com wrote:
Hoi Anton,

It's SMS on all servers, not fragmented (freshly installed on empty
partitions).

I don't know if Bonnie uses 4K records, but probably not.

Could that amount in such a big difference?


--
Sacha,
One of the differences between SMS and DMS tablespaces is that DMS has
preallocated space, while SMS
grows all the time when records are inserted. Maybe it is worthwhile to do
some tests on DMS and see if this improves performance or not on your slow
machine.
Message posted via DBMonster.com
http://www.dbmonster.com/Uwe/Forums....m-db2/200507/1
Nov 12 '05 #30

P: n/a
I did one simple test with DMS with the same slow result. In fact
everything I try to tune DB2 (table APPEND ON, DB2_PARALLEL_IO,
increase bufferpools, tune tablespaces) doesn't help a thing.

I now have one of the servers on hand, so I'm testing with various
RAID(less) configurations to see what happens.

I wonder if the HostRAID or IBM Server Raid SCSI driver (not included
with RHEL 3.0) could be the problem...

Nov 12 '05 #31

P: n/a
> I'd take a long look at the connection between the new disks and the
system. It appears that its quite slow - especially when writing large
quantities of data (asynchronous writes).


We had to install HostRaid (Adaptec) drivers and IBM Server Raid
drivers not included in the RHEL 3.0 distribution. Perhaps these are
the problem? I have one of those machines on hand now so I'm first
testing without this RAID stuff and work my way up to the disk cabinet.

Somethings indeed very fishy with the way DB2 accesses the disks.

Nov 12 '05 #32

P: n/a
Hi people,

We tracked it down. It was (as always) a combination of misinformation
false assumptions.

As it turns out the fastest server I have does (must) indeed have it's
HW cache on on the PERC raid controller. Testing the IBM machine hands
on shows there is no HW cache in the machine at all. We tested against
another DELL we have here with similar set-up as the IBM, but with PERC
controller with HW cache, and when the HW cache is disabled on the DELL
the performance is similar.

With cache: 5000 inserts p/sec
W/o cache: 250 inserts p/sec

For our application the risc involving HW cache is acceptable.
Therefore we are going to enable (or buy) a cache for the DB disk
cabinet.

Thanks all for your help. I for one learned a lot from this exercise,
hopefully I haven't wasted anyones time.

Nov 12 '05 #33

P: n/a
Hi,

It turned out that there wasn't any HW cache at all. They are enabling
it now to speed things up.

Nov 12 '05 #34

P: n/a
Try setting up a little program to write a few hundred 128k records to
disk. Include timing code to get accurate run times and average a half a
dozen runs on each environment. This should give you current speeds and
targets for improvements. It's a lot easier to run something like this
than a full database run.

Good luck.

Phil Sherman
sa*********@gmail.com wrote:

We had to install HostRaid (Adaptec) drivers and IBM Server Raid
drivers not included in the RHEL 3.0 distribution. Perhaps these are
the problem? I have one of those machines on hand now so I'm first
testing without this RAID stuff and work my way up to the disk cabinet.

Somethings indeed very fishy with the way DB2 accesses the disks.

Nov 12 '05 #35

P: n/a
sa*********@gmail.com wrote:

Thanks all for your help. I for one learned a lot from this exercise,
hopefully I haven't wasted anyones time.


I for one found this to be an interesting thread.
It contains useful information, and useful information is never a waste :)

-R-
Nov 12 '05 #36

This discussion thread is closed

Replies have been disabled for this discussion.