dbimport, stripped disk

We are doing dbimport, it is extremely slow. The job was done with only 3 hours with IDS10 UC4 on the same platform EXCEPT the disk allocation. Now, the disk is stripped, i.e., each chunk is composed by several disks. The following are some info. Sounds we have IO bottle neck problem, don't we? We doubt the stripped disk may be the reason....., since system shows all disks are 100% busy. Any suggestions? Thanks, Frank AIX 5.3 informix@klaus $ onstat -g ath IBM Informix Dynamic Server Version 10.00.UC5 -- On-Line (CKPT REQ) -- Up 4 days 00:13:47 -- 1976112 KbytesBlocked:CKPT Threads: tid tcb rstcb prty status vp-class name 2 b083cd78 0 2 sleeping forever 6lio lio vp 0 3 b083cec0 0 2 sleeping forever 7pio pio vp 0 4 b0882968 0 2 sleeping forever 8aio aio vp 0 5 b08a0968 0 2 sleeping forever 9msc msc vp 0 6 b08d6968 0 2 sleeping forever 10aio aio vp 1 7 b08f4b70 b02e5018 4 sleeping secs: 1 4cpu main_loop() 8 b08a0c68 0 2 running 11soc soctcppoll 9 b08a0eb8 0 2 running 12soc soctcppoll 10 b08d6bb8 0 2 sleeping forever 1cpu sm_poll 11 b09589f0 0 3 sleeping forever 1cpu soctcplst 12 b0975578 0 3 sleeping forever 1cpu sm_listen 13 b0995018 0 2 sleeping secs: 1 4cpu sm_discon 14 b09951a0 b02e5524 2 sleeping forever 3cpu flush_sub(0) 15 b0995328 b02e5a30 2 sleeping secs: 1 4cpu flush_sub(1) 16 b09954b0 b02e5f3c 2 sleeping forever 1cpu flush_sub(2) 17 b0995638 b02e6448 2 sleeping forever 5cpu flush_sub(3) 18 b09957c0 b02e6954 2 sleeping forever 4cpu flush_sub(4) 19 b0995948 b02e6e60 2 sleeping forever 3cpu flush_sub(5) 20 b0995ad0 b02e736c 2 sleeping forever 3cpu flush_sub(6) 21 b0995c58 b02e7878 2 sleeping forever 4cpu flush_sub(7) 22 b0995de0 b02e7d84 2 sleeping forever 4cpu flush_sub(8) 23 b0a56018 b02e8290 2 sleeping forever 3cpu flush_sub(9) 24 b0a561a0 b02e879c 2 sleeping forever 5cpu flush_sub(10) 25 b0a56328 b02e8ca8 2 sleeping forever 3cpu flush_sub(11) 26 b0a564b0 b02e91b4 2 sleeping forever 4cpu flush_sub(12) 27 b0a56638 b02e96c0 2 sleeping forever 5cpu flush_sub(13) 28 b0a567c0 b02e9bcc 2 sleeping forever 3cpu flush_sub(14) 29 b0a56948 b02ea0d8 2 sleeping forever 5cpu flush_sub(15) 30 b0a56ad0 b02ea5e4 2 sleeping forever 3cpu flush_sub(16) 31 b0a56c58 b02eaaf0 2 sleeping forever 3cpu flush_sub(17) 32 b0a56de0 b02eaffc 2 sleeping forever 3cpu flush_sub(18) 33 b0b29018 b02eb508 2 sleeping forever 5cpu flush_sub(19) 34 b0b291a0 b02eba14 2 sleeping forever 1cpu flush_sub(20) 35 b0b29328 b02ebf20 2 sleeping forever 4cpu flush_sub(21) 36 b0b294b0 b02ec42c 2 sleeping forever 5cpu flush_sub(22) 37 b0b29638 b02ec938 2 sleeping forever 4cpu flush_sub(23) 38 b0b297e8 b02ece44 2 sleeping forever 3cpu flush_sub(24) 39 b0b299c8 b02ed350 2 sleeping forever 3cpu flush_sub(25) 40 b0b29ba8 b02ed85c 2 sleeping forever 3cpu flush_sub(26) 41 b0b29d88 b02edd68 2 sleeping forever 3cpu flush_sub(27) 42 b0be7018 b02ee274 2 sleeping forever 4cpu flush_sub(28) 43 b0be71f8 b02ee780 2 sleeping forever 3cpu flush_sub(29) 44 b0be73d8 b02eec8c 2 sleeping forever 3cpu flush_sub(30) 45 b0be75b8 b02ef198 2 sleeping forever 3cpu flush_sub(31) 46 b0be7798 b02ef6a4 2 sleeping forever 3cpu flush_sub(32) 47 b0be7978 b02efbb0 2 sleeping forever 3cpu flush_sub(33) 48 b0be7b58 b02f00bc 2 sleeping forever 3cpu flush_sub(34) 49 b0be7d38 b02f05c8 2 sleeping forever 5cpu flush_sub(35) 50 b0c90018 b02f0ad4 2 sleeping forever 5cpu flush_sub(36) 51 b0c901f8 b02f0fe0 2 sleeping forever 3cpu flush_sub(37) 52 b0c903d8 b02f14ec 2 sleeping forever 5cpu flush_sub(38) 53 b0c905b8 b02f19f8 2 sleeping forever 1cpu flush_sub(39) 54 b0c90798 b02f1f04 2 sleeping forever 3cpu flush_sub(40) 55 b0c90978 b02f2410 2 sleeping forever 3cpu flush_sub(41) 56 b0c90b58 b02f291c 2 sleeping forever 5cpu flush_sub(42) 57 b0c90d38 b02f2e28 2 sleeping forever 1cpu flush_sub(43) 58 b0d39018 b02f3334 2 sleeping forever 5cpu flush_sub(44) 59 b0d391f8 b02f3840 2 sleeping forever 5cpu flush_sub(45) 60 b0d393d8 b02f3d4c 2 sleeping forever 3cpu flush_sub(46) 61 b0d395b8 b02f4258 2 sleeping forever 5cpu flush_sub(47) 62 b0d39798 b02f4764 2 sleeping forever 3cpu flush_sub(48) 63 b0d39978 b02f4c70 2 sleeping forever 4cpu flush_sub(49) 64 b0d39b58 b02f517c 2 sleeping forever 3cpu flush_sub(50) 65 b0d39d38 b02f5688 2 sleeping forever 1cpu flush_sub(51) 66 b0de3018 b02f5b94 2 sleeping forever 5cpu flush_sub(52) 67 b0de31f8 b02f60a0 2 sleeping forever 5cpu flush_sub(53) 68 b0de33d8 b02f65ac 2 sleeping forever 3cpu flush_sub(54) 69 b0de35b8 b02f6ab8 2 sleeping forever 3cpu flush_sub(55) 70 b0de3798 b02f6fc4 2 sleeping forever 4cpu flush_sub(56) 71 b0de3978 b02f74d0 2 sleeping forever 4cpu flush_sub(57) 72 b0de3b58 b02f79dc 2 sleeping forever 3cpu flush_sub(58) 73 b0de3d38 b02f7ee8 2 sleeping forever 4cpu flush_sub(59) 74 b0e8c018 b02f83f4 2 sleeping forever 4cpu flush_sub(60) 75 b0e8c1f8 b02f8900 2 sleeping forever 4cpu flush_sub(61) 76 b0e8c3d8 b02f8e0c 2 sleeping forever 4cpu flush_sub(62) 77 b0e8c5b8 b02f9318 2 sleeping secs: 1 4cpu flush_sub(63) 78 b0e8c798 0 4 running 1cpu kaio 79 b102b4e8 b02f9824 3 sleeping secs: 1 4cpu aslogflush 80 b102bb00 b02f9d30 1 sleeping secs: 24 1cpu btscanner_0 82 b10ea318 0 4 running 4cpu kaio 96 b1d41960 0 4 running 3cpu kaio 97 b1d41bb8 0 4 running 5cpu kaio 99 b1e72208 b02fac54 4 sleeping secs: 1 1cpu onmode_mon 102 b1e723e8 b02fa748 2 cond wait bp_cond 1cpu bf_priosweep() 105 b1d41780 0 2 slee

Yunyao (Frank) Qu wrote: > We are doing dbimport, it is extremely slow. > The job was done with only 3 hours with IDS10 UC4 on the same platform > EXCEPT the disk allocation. > > Now, the disk is stripped, i.e., each chunk is composed by several disks. > > The following are some info. > > Sounds we have IO bottle neck problem, don't we? We doubt the stripped > disk may be the reason....., since system shows all disks are 100% > busy. Any suggestions? If all of the drives are 100% busy then that IS INDEED your bottleneck! Art S. Kagel > > Thanks, > Frank <SNIP> > - >

Yunyao (Frank) Qu wrote: > We are doing dbimport, it is extremely slow. > The job was done with only 3 hours with IDS10 UC4 on the same platform > EXCEPT the disk allocation. > > Now, the disk is stripped, i.e., each chunk is composed by several disks. > > The following are some info. > > Sounds we have IO bottle neck problem, don't we? We doubt the stripped > disk may be the reason....., since system shows all disks are 100% > busy. Any suggestions? If all of the drives are 100% busy then that IS INDEED your bottleneck! Art S. Kagel > > Thanks, > Frank <SNIP> > - >