![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#11
| |||
| |||
|
|
I would love to cut my load times in half, but the load needs to run unattended so it looks like this option is out unless I'm missing it can run unattended... please tes all first on a test box... as informix: set lrumin and maxdirty to 99 in $ONCONFIG bounce the engine. dbaccess sysmaster <<! -- WARNING CHECK THE CODE may contain a bug.. create procedure generatechkpt() define dirty decimal (4,3); while (1=1) select ( sum(lru_nmod) / sum ( lru_nfree + lru_nmod )) into dirty from syslrus ; if (dirty < 0.75 ) then system "sleep 1"; else system "onmode -c"; end if end while ; end procedure; execute procedure generatechkpt(); ! run your load when done do onmode -c set lrumin and maxdirty back to what it was and bounce your engine. regarding onconfig: grab 1 GB for bufferecache at least; BUFFERS 250000 # Maximum number of shared buffers PHYSFILE 40000 # Physical log file size (Kbytes) i do not want a checkpoint when this becomes 75 % full so use onparams to set the size to 1 GB or 1.5 GB. You should be safe since you are on 7.31.UD7. if all is raw and KAIO set NUMAIOVPS to 4 max or to 2. PHYSBUFF 512 # Physical log buffer size (Kbytes) LOGBUFF 512 # Logical log buffer size (Kbytes) contain a "TEXT" column and thus would not work with HPL (or at least we couldn't get it to work). it does work in deluxe as someone else stated, and yes you can increase your buffer cache it will help!!!!! also the above hack spl will help. i also see > Informix Dynamic Server Version 7.31.UD7 -- On-Line (CKPT REQ) -- -->> checkpoint request.. how long are your checkpoints??? can your disks cope??? i sure hope no raid 5; ask Art why. Superboer. On 19 jun, 04:19,johneevo<johne... (AT) gmail (DOT) com> wrote: On Jun 11, 3:07 am, Superboer <superbo... (AT) t-online (DOT) de> wrote: Hi Superboer, Thanks for the reply. You should be able to speed this up. I have been told that we have 4 GB of memory on this box. BUFFERS 75000 # Maximum number of shared buffers 4 GB available and only 75000*4k=300MB of buffer cache.. i would make this bigger and therefor increase PHYSFILE 40000 # Physical log file size (Kbytes) NUMAIOVPS 36 # Number of IO vps changed CSA 05/3/06 Any suggestions on what the increase the the BUFFERS to. And I guess there is some ratio that the BUFFERS to PHYSFILE should be set to. If this is correct would you mind tell me what that ratio is? Are you using kernel io??? onstat -g ioa will tell. Yes it appears that we are using kernel io if I am reading the onstat - g ioa otput correctly. The kio lines have the majority the reads and writes. if so decrease NUMAIOVPS if using cooked files then consider raw please Any suggestions on that the decrease the NUMAIOVPS to? Or is this just a trail and error type of tuning? PHYSBUFF 64 # Physical log buffer size (Kbytes) bigger. LOGBUFF 64 # Logical log buffer size (Kbytes) bigger. I'm sorry, but once again, any suggestions on what to increase these buffers to? During the load it may be interesting to see what the db is doing, so an onstat -p may help... Here is the onstat -p output while the load is running. This was taken while the HPL portion was running. Informix Dynamic Server Version 7.31.UD7 -- On-Line (CKPT REQ) -- Up 01:47:2 6 -- 873952 Kbytes Blocked:CKPT Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 1389715 7807595 27016290 94.86 1038143 2602162 2919803 64.44 isamtot open start read write rewrite delete commit rollbk 53729641 130660 148793 12402936 35365788 3679 13512 5474 139 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 3789.28 409.72 356 725 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 709578 0 15464370 0 0 580 1856 11850 ixda-RA idx-RA da-RA RA-pgsused lchwaits 79 1 255074 255136 57787 also you state dbimport/???? if load/unload, make sure that indexes are created after data is loaded. I'll check on this, but I believe these are rather small tables. The contain a "TEXT" column and thus would not work with HPL (or at least we couldn't get it to work). Also you could consider generating your own checkpoints setting lrumax and min dirty to 99, check buffer cache if 75 % dirty then do a onmode -c (i have cut load times have in half using this......) I would love to cut my load times in half, but the load needs to run unattended so it looks like this option is out unless I'm missing the boat completely with your comment here. John |
#12
| |||
| |||
|
|
Yes, if in deluxe mode, you are not really getting the full benefit of HPL, just some parallel input files. |
#13
| |||
| |||
|
|
The HPL process (and I found out we are using the Express mode not the Deluxe mode like I first thought) is taking about 4 hrs to load the 10GB of data, then another 3 hrs to create rowids (we needed to |
|
On Jun 19, 3:05 am, Superboer <superbo... (AT) t-online (DOT) de> wrote: Hi Superboer, Thanks for helping me with this. Last night I changed the BUFFERS to 400000 and increased LRUS and CLEANERS to 99 for each and this did not speed things up. So tonight I am going to try also make some of the changes that you suggested, lowering NUMAIOVPS from 36 to 4 and increasing the PHYSBUFF and LOGBUFF from 64 to 512 for each I'm not ready yet to try the "generatechkpt" stored proc (although I might be soon...) I figure I'll just try a few things at a time and see what if any affect they have. I should probably give a little more info on the overall time things are taking to run, since me first post probably gave the impression that the HPL process is taking 10+ hrs. The HPL process (and I found out we are using the Express mode not the Deluxe mode like I first thought) is taking about 4 hrs to load the 10GB of data, then another 3 hrs to create rowids (we needed to remove them before running HPL since these tables are fragmented), 1 hr to enable contraints etc. and then 2hrs for table stats. Do you still think we can speed this up, or is this the best we can get using the version that we have? John I would love to cut my load times in half, but the load needs to run unattended so it looks like this option is out unless I'm missing it can run unattended... please tes all first on a test box... as informix: set lrumin and maxdirty to 99 in $ONCONFIG bounce the engine. dbaccess sysmaster <<! -- WARNING CHECK THE CODE may contain a bug.. create procedure generatechkpt() define dirty decimal (4,3); while (1=1) select ( sum(lru_nmod) / sum ( lru_nfree + lru_nmod )) into dirty from syslrus ; if (dirty < 0.75 ) then system "sleep 1"; else system "onmode -c"; end if end while ; end procedure; execute procedure generatechkpt(); ! run your load when done do onmode -c set lrumin and maxdirty back to what it was and bounce your engine. regarding onconfig: grab 1 GB for bufferecache at least; BUFFERS 250000 # Maximum number of shared buffers PHYSFILE 40000 # Physical log file size (Kbytes) i do not want a checkpoint when this becomes 75 % full so use onparams to set the size to 1 GB or 1.5 GB. You should be safe since you are on 7.31.UD7. if all is raw and KAIO set NUMAIOVPS to 4 max or to 2. PHYSBUFF 512 # Physical log buffer size (Kbytes) LOGBUFF 512 # Logical log buffer size (Kbytes) contain a "TEXT" column and thus would not work with HPL (or at least we couldn't get it to work). it does work in deluxe as someone else stated, and yes you can increase your buffer cache it will help!!!!! also the above hack spl will help. i also see > Informix Dynamic Server Version 7.31.UD7 -- On-Line (CKPT REQ) -- -->> checkpoint request.. how long are your checkpoints??? can your disks cope??? i sure hope no raid 5; ask Art why. Superboer. On 19 jun, 04:19,johneevo<johne... (AT) gmail (DOT) com> wrote: On Jun 11, 3:07 am, Superboer <superbo... (AT) t-online (DOT) de> wrote: Hi Superboer, Thanks for the reply. You should be able to speed this up. I have been told that we have 4 GB of memory on this box. BUFFERS 75000 # Maximum number of shared buffers 4 GB available and only 75000*4k=300MB of buffer cache.. i would make this bigger and therefor increase PHYSFILE 40000 # Physical log file size (Kbytes) NUMAIOVPS 36 # Number of IO vps changed CSA 05/3/06 Any suggestions on what the increase the the BUFFERS to. And I guess there is some ratio that the BUFFERS to PHYSFILE should be set to. If this is correct would you mind tell me what that ratio is? Are you using kernel io??? onstat -g ioa will tell. Yes it appears that we are using kernel io if I am reading the onstat - g ioa otput correctly. The kio lines have the majority the reads and writes. if so decrease NUMAIOVPS if using cooked files then consider raw please Any suggestions on that the decrease the NUMAIOVPS to? Or is this just a trail and error type of tuning? PHYSBUFF 64 # Physical log buffer size (Kbytes) bigger. LOGBUFF 64 # Logical log buffer size (Kbytes) bigger. I'm sorry, but once again, any suggestions on what to increase these buffers to? During the load it may be interesting to see what the db is doing, so an onstat -p may help... Here is the onstat -p output while the load is running. This was taken while the HPL portion was running. Informix Dynamic Server Version 7.31.UD7 -- On-Line (CKPT REQ) -- Up 01:47:2 6 -- 873952 Kbytes000 Blocked:CKPT Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 1389715 7807595 27016290 94.86 1038143 2602162 2919803 64.44 isamtot open start read write rewrite delete commit rollbk 53729641 130660 148793 12402936 35365788 3679 13512 5474 139 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 3789.28 409.72 356 725 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 709578 0 15464370 0 0 580 1856 11850 ixda-RA idx-RA da-RA RA-pgsused lchwaits 79 1 255074 255136 57787 also you state dbimport/???? if load/unload, make sure that indexes are created after data is loaded. I'll check on this, but I believe these are rather small tables. The contain a "TEXT" column and thus would not work with HPL (or at least we couldn't get it to work). Also you could consider generating your own checkpoints setting lrumax and min dirty to 99, check buffer cache if 75 % dirty then do a onmode -c (i have cut load times have in half using this......) I would love to cut my load times in half, but the load needs to run unattended so it looks like this option is out unless I'm missing the boat completely with your comment here. John |
#14
| |||||
| |||||
|
|
if you set lrumax and mindirty to 99 you have to generate your own checkpoints!!!! if you do not want to generate checkpoints you may want to set lrumaxdirty to 10 and set mindirty to say 5 or smaller. |
|
400000 for BUFFERS means 4 * 400000 = 1.6 GB of buffer cache.... assume you have that memory. |
|
4 hours for 10 GB is afwul. what are your disks doing???? create rowids i assume you set pdpriority and have that configured properly... |
|
3 hours are LONGGGG post the onconfig also check your disks if they are 100 % busy.. also how long are checkpoints taking??? |
|
some time ago i used HPL in express mode and reloaded a 100 GB table on a sun which took only 1 hour. |
#15
| |||||
| |||||
|
|
This how we are setting pdqpriority from the shell file: export MAX_PDQPRIORITY=100 PSORT_NPROCS=6 PDQPRIORITY=100 FET_BUF_SIZE=32767 |
|
I apologize but I don't know how to check how busy the disks are nor on ex sun |
|
how long the checkpoints are taking. how long checkpoints are taking, have a look in your log file (onstat - |
|
1 hour?!?!?! Did that include indexes and constraints? No only data load, indexes where created later using pdq etc. |
|
When we started with HPL the loading of the data was only taking seconds but re-enabling the indexes and constraints is where things slowed down. John |
#16
| |||
| |||
|
|
(i do assume if you create a backup you use onbar -b -w or external backup??) |
|
on ex sun iostat -dx <sampletime> < nr samples> or sar -d <sampletime> < nr samples on aix afaicr there is a utitlity called topas which also displays iostats.... aix should also have sar and if i am not mistaken iostat??? how long the checkpoints are taking. how long checkpoints are taking, have a look in your log file (onstat - m) |
|
1 hour?!?!?! Did that include indexes and constraints? No only data load, indexes where created later using pdq etc. I would create a script and set pdq etc after HPL. HPL attempts to set pdq, but you do not have full controll. |
#17
| |||
| |||
|
|
On Jun 22, 3:06 am, Superboer <superbo... (AT) t-online (DOT) de> wrote: Hi Superboer, |
|
on aix afaicr there is a utitlity called topas which also displays iostats.... aix should also have sar and if i am not mistaken iostat??? how long the checkpoints are taking. how long checkpoints are taking, have a look in your log file (onstat - m) Sorry I should have mentioned that we are running aix on an RS-6000. I will run sar during the next import on Saturday night. I'll check the checkpoints then also. |
#18
| ||||||||
| ||||||||
|
|
Once you get that all worked out, post the following if it's still not good: onstat -p (including the time since stats were zero'd). I'm not sure if I included the time since stats wer zero'd (I ran |
|
onstat -D Informix Dynamic Server Version 7.31.UD7 -- On-Line (CKPT REQ) -- |
|
onstat -P |
|
onstat -g iov |
|
onstat -F |
|
onstat -R |
|
onstat -g iof |
|
And the update ONCONFIG (or onstat -c output). We'll see if we can help more. Art S. Kagel |
#19
| |||
| |||
|
|
export MAX_PDQPRIORITY=100 PSORT_NPROCS=6 PDQPRIORITY=100 FET_BUF_SIZE=32767 |