Oninit cdi / Archive
Talk to an expert →

HP KAIO Advice

Posted in 2000

Topics: Storage & Space Management, Error Codes & Troubleshooting, Server Administration, Logging & Checkpoints, Versions, Editions & End-of-Life

Tony Flaherty — — source: Informix-list mailing list archive (1991-1998)

Hi, HpUx 10.20 Patched to Dec 99 IDS 7.31.uc7 I've enabled this on my development server. I have a few questions. :o/ Firstly how do people determine the value to use for IFMX_HPKAIO_NUM_REQ ? is it a calculable figure or is it a guestimate. Secondly, My development machine is a humble E25 with only 64Mb of RAM. I had to reduce shared memory parameters significantly before I could get KAIO to work. I think I was running into bug 110290 giving the following in the online log:- 14:12:01 Shared memory segment 0xc0fe6000 could not be forced resident. Fri Mar 17 14:12:15 2000 14:12:15 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' 14:12:22 DR: DRAUTO is 0 (Off) 14:12:23 Informix Dynamic Server Version 7.31.UC5 Software Serial NumberAAC#J860464 14:12:23 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 14:12:24 Assert Failed: kaiothread() ERROR 14:12:24 Informix Dynamic Server Version 7.31.UC5 14:12:24 Who: Session(0, @, 0, 0) Thread(37, kaio, 0, 5) File: kaio.c Line: 2121 14:12:24 stack trace for pid 2070 written to /dbwork/af.40d3d48 14:13:13 See Also: /dbwork/af.40d3d48, shmem.40d3d48.0 14:13:13 Error writing '/dbwork/shmem.40d3d48.0' errno = 28 14:13:13 kaio.c, line 2121, thread 37, proc id 2070, kaiothread() ERROR. 14:13:13 PANIC: Attempting to bring system down 14:13:13 semctl: errno = 22 14:13:13 semctl: errno = 22 14:13:13 semctl: errno = 22 14:13:13 semctl: errno = 22 Once I reduced the shared memory parameters enough so that the memory could be locked it worked:- 14:50:19 Segment locked: addr=0xc1192000, size=27410432 Fri Mar 17 14:50:24 2000 14:50:24 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' 14:50:33 DR: DRAUTO is 0 (Off) 14:50:34 Informix Dynamic Server Version 7.31.UC5 Software Serial NumberAAC#J860464 14:50:35 HPUX Version B.10.20 -> Using flag/select style KAIO 14:50:35 HP KAIO concurrent requests changed from 1000 to 100 14:50:38 Informix Dynamic Server Initialized -- Shared Memory Initialized. 14:50:38 Physical Recovery Started. 14:50:39 Physical Recovery Complete: 0 Pages Restored. 14:50:39 Logical Recovery Started. 14:50:42 Logical Recovery Complete. 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 14:50:43 Onconfig parameter BUFFERS modified from 20000 to 2000. 14:50:43 Onconfig parameter CLEANERS modified from 20 to 10. 14:50:43 Onconfig parameter LRUS modified from 20 to 10. 14:50:43 Onconfig parameter DUMPDIR modified from /dbwork to /data. 14:50:43 Onconfig parameter NUMAIOVPS modified from 30 to 4. 14:50:43 Onconfig parameter SHMVIRTSIZE modified from 20480 to 10240. 14:50:43 Dataskip is now OFF for all dbspaces 14:50:44 On-Line Mode 14:50:46 Checkpoint Completed: duration was 2 seconds. 14:55:52 Checkpoint Completed: duration was 0 seconds. Notice the changes to the onconfig paramaters! My concern here is that I do not have the ability to test this properly before enabling it on my production server. Which obviously is a much beefier setup. Has anyone else encountered this problem and Am I right in saying that this is only a problem if the shared memory cannot be forced resident? TIA -- --------------------------------------- Tony Flaherty aef@mfs.misys.co.uk Analyst Programmer Misys Financial Systems All statements and opinions are my own, Misys don't pay me enough to have opinions on their behalf .

↪ replying to Tony Flaherty
Carlson@WHSmith — — source: Informix-list mailing list archive (1991-1998)

Tony Flaherty wrote: > > Hi, > > HpUx 10.20 Patched to Dec 99 > > IDS 7.31.uc7 > > I've enabled this on my development server. I have a few questions. :o/ > > Firstly how do people determine the value to use for IFMX_HPKAIO_NUM_REQ ? > is it a calculable figure or is it a guestimate. From what I've seen, I'd presume that it is a guesstimate. Only bump up the numbers if necessary, that sort of thing. > > Secondly, My development machine is a humble E25 with only 64Mb of RAM. I > had to reduce shared memory parameters significantly before I could get KAIO > to work. I think I was running into bug 110290 giving the following in the > online log:- Could be . . . (too bad we can't look up bugs using a real, live bug number. 8-) > > 14:12:01 Shared memory segment 0xc0fe6000 could not be forced resident.> > Fri Mar 17 14:12:15 2000 > > 14:12:15 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' > 14:12:22 DR: DRAUTO is 0 (Off) > 14:12:23 Informix Dynamic Server Version 7.31.UC5 Software Serial Number> AAC#J860464 > 14:12:23 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 > 14:12:24 Assert Failed: kaiothread() ERROR > 14:12:24 Informix Dynamic Server Version 7.31.UC5 > 14:12:24 Who: Session(0, @, 0, 0) > Thread(37, kaio, 0, 5) > File: kaio.c Line: 2121 > 14:12:24 stack trace for pid 2070 written to /dbwork/af.40d3d48 > 14:13:13 See Also: /dbwork/af.40d3d48, shmem.40d3d48.0 > 14:13:13 Error writing '/dbwork/shmem.40d3d48.0' errno = 28 > 14:13:13 kaio.c, line 2121, thread 37, proc id 2070, kaiothread() ERROR. > 14:13:13 PANIC: Attempting to bring system down > 14:13:13 semctl: errno = 22 > > 14:13:13 semctl: errno = 22 > > 14:13:13 semctl: errno = 22 > > 14:13:13 semctl: errno = 22> > Once I reduced the shared memory parameters enough so that the memory could > be locked it worked:- > > 14:50:19 Segment locked: addr=0xc1192000, size=27410432> > Fri Mar 17 14:50:24 2000 > > 14:50:24 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' > 14:50:33 DR: DRAUTO is 0 (Off) > 14:50:34 Informix Dynamic Server Version 7.31.UC5 Software Serial Number> AAC#J860464 > 14:50:35 HPUX Version B.10.20 -> Using flag/select style KAIO > 14:50:35 HP KAIO concurrent requests changed from 1000 to 100 > 14:50:38 Informix Dynamic Server Initialized -- Shared Memory Initialized. > 14:50:38 Physical Recovery Started. > 14:50:39 Physical Recovery Complete: 0 Pages Restored. > 14:50:39 Logical Recovery Started. > 14:50:42 Logical Recovery Complete.> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks > > 14:50:43 Onconfig parameter BUFFERS modified from 20000 to 2000. > 14:50:43 Onconfig parameter CLEANERS modified from 20 to 10. > 14:50:43 Onconfig parameter LRUS modified from 20 to 10. > 14:50:43 Onconfig parameter DUMPDIR modified from /dbwork to /data. > 14:50:43 Onconfig parameter NUMAIOVPS modified from 30 to 4. > 14:50:43 Onconfig parameter SHMVIRTSIZE modified from 20480 to 10240. > 14:50:43 Dataskip is now OFF for all dbspaces > 14:50:44 On-Line Mode > 14:50:46 Checkpoint Completed: duration was 2 seconds. > 14:55:52 Checkpoint Completed: duration was 0 seconds.> > Notice the changes to the onconfig paramaters! BUFFERS cut to 10% of original? Must be a test box. > > My concern here is that I do not have the ability to test this properly > before enabling it on my production server. Which obviously is a much > beefier setup. Has anyone else encountered this problem and Am I right in > saying that this is only a problem if the shared memory cannot be forced > resident? > According to the bug report, the only thing that needs to be reset is the buffers of SHMVIRTSIZE. Which one gets the ax would be something left to testing (or monitoring, etc). -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */

↪ replying to Carlson@WHSmith
Tony Flaherty — — source: Informix-list mailing list archive (1991-1998)

. Carlson@WHSmith wrote in message <38D27B49.D5E1019C@bellsouth.net>... >Tony Flaherty wrote: >> >> Hi, >> >> HpUx 10.20 Patched to Dec 99 >> >> IDS 7.31.uc7 >> >> I've enabled this on my development server. I have a few questions. :o/ >> >> Firstly how do people determine the value to use for IFMX_HPKAIO_NUM_REQ ? >> is it a calculable figure or is it a guestimate. > >From what I've seen, I'd presume that it is a guesstimate. Only bump up >the numbers if necessary, that sort of thing. > >> >> Secondly, My development machine is a humble E25 with only 64Mb of RAM. I >> had to reduce shared memory parameters significantly before I could get KAIO >> to work. I think I was running into bug 110290 giving the following in the >> online log:- > >Could be . . . (too bad we can't look up bugs using a real, live bug >number. 8-) >> >> 14:12:01 Shared memory segment 0xc0fe6000 could not be forced resident.>> >> Fri Mar 17 14:12:15 2000 >> >> 14:12:15 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' >> 14:12:22 DR: DRAUTO is 0 (Off) >> 14:12:23 Informix Dynamic Server Version 7.31.UC5 Software SerialNumber >> AAC#J860464 >> 14:12:23 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 >> 14:12:24 Assert Failed: kaiothread() ERROR >> 14:12:24 Informix Dynamic Server Version 7.31.UC5 >> 14:12:24 Who: Session(0, @, 0, 0) >> Thread(37, kaio, 0, 5) >> File: kaio.c Line: 2121 >> 14:12:24 stack trace for pid 2070 written to /dbwork/af.40d3d48 >> 14:13:13 See Also: /dbwork/af.40d3d48, shmem.40d3d48.0 >> 14:13:13 Error writing '/dbwork/shmem.40d3d48.0' errno = 28 >> 14:13:13 kaio.c, line 2121, thread 37, proc id 2070, kaiothread() ERROR. >> 14:13:13 PANIC: Attempting to bring system down >> 14:13:13 semctl: errno = 22 >> >> 14:13:13 semctl: errno = 22 >> >> 14:13:13 semctl: errno = 22 >> >> 14:13:13 semctl: errno = 22>> >> Once I reduced the shared memory parameters enough so that the memory could >> be locked it worked:- >> >> 14:50:19 Segment locked: addr=0xc1192000, size=27410432>> >> Fri Mar 17 14:50:24 2000 >> >> 14:50:24 Event alarms enabled. ALARMPROG = '/usr/informix/etc/log_full.sh' >> 14:50:33 DR: DRAUTO is 0 (Off) >> 14:50:34 Informix Dynamic Server Version 7.31.UC5 Software SerialNumber >> AAC#J860464 >> 14:50:35 HPUX Version B.10.20 -> Using flag/select style KAIO >> 14:50:35 HP KAIO concurrent requests changed from 1000 to 100 >> 14:50:38 Informix Dynamic Server Initialized -- Shared MemoryInitialized. >> 14:50:38 Physical Recovery Started. >> 14:50:39 Physical Recovery Complete: 0 Pages Restored. >> 14:50:39 Logical Recovery Started. >> 14:50:42 Logical Recovery Complete.>> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks >> >> 14:50:43 Onconfig parameter BUFFERS modified from 20000 to 2000. >> 14:50:43 Onconfig parameter CLEANERS modified from 20 to 10. >> 14:50:43 Onconfig parameter LRUS modified from 20 to 10. >> 14:50:43 Onconfig parameter DUMPDIR modified from /dbwork to /data. >> 14:50:43 Onconfig parameter NUMAIOVPS modified from 30 to 4. >> 14:50:43 Onconfig parameter SHMVIRTSIZE modified from 20480 to 10240. >> 14:50:43 Dataskip is now OFF for all dbspaces >> 14:50:44 On-Line Mode >> 14:50:46 Checkpoint Completed: duration was 2 seconds. >> 14:55:52 Checkpoint Completed: duration was 0 seconds.>> >> Notice the changes to the onconfig paramaters! > >BUFFERS cut to 10% of original? Must be a test box. :o)) > >> >> My concern here is that I do not have the ability to test this properly >> before enabling it on my production server. Which obviously is a much >> beefier setup. Has anyone else encountered this problem and Am I right in >> saying that this is only a problem if the shared memory cannot be forced >> resident? >> > >According to the bug report, the only thing that needs to be reset is >the buffers of SHMVIRTSIZE. Which one gets the ax would be something >left to testing (or monitoring, etc). Yep, I sorta reduced the others to keep them roughly in line with the (new) sixe of the instance. Generally there's only me using it anyway. I had to reduce sizes until the memory could be locked in memory before it worked. before I had more memory allocated to IDS than existed in the box!! As an aside does anyone know how uptodate the online bug list is at informix.com? > >-- >John Carlson >Informix DBA >WHSmith USA > >#include std_disclaimer.h /* These are my opinions, not my company's >opinion */ -- --------------------------------------- Tony Flaherty aef@mfs.misys.co.uk Analyst Programmer Misys Financial Systems All statements and opinions are my own, Misys don't pay me enough to have opinions on their behalf

↪ replying to Tony Flaherty
glyn_lewis@my-deja.com — — source: Informix-list mailing list archive (1991-1998)

In article <953556966.13870.0.nnrp-03.c1ed1f69@news.demon.co.uk>, "Tony Flaherty" <aef@mfs.misys.co.uk> wrote: > > . > Carlson@WHSmith wrote in message <38D27B49.D5E1019C@bellsouth.net>... > >Tony Flaherty wrote: > >> > >> Hi, > >> > >> HpUx 10.20 Patched to Dec 99 > >> > >> IDS 7.31.uc7 > >> > >> I've enabled this on my development server. I have a few questions. :o/ > >> > >> Firstly how do people determine the value to use for IFMX_HPKAIO_NUM_REQ > ? > >> is it a calculable figure or is it a guestimate. > > > >From what I've seen, I'd presume that it is a guesstimate. Only bump up > >the numbers if necessary, that sort of thing. > > > >> > >> Secondly, My development machine is a humble E25 with only 64Mb of RAM. > I > >> had to reduce shared memory parameters significantly before I could get > KAIO > >> to work. I think I was running into bug 110290 giving the following in > the > >> online log:- > > > >Could be . . . (too bad we can't look up bugs using a real, live bug > >number. 8-) > >> > >> 14:12:01 Shared memory segment 0xc0fe6000 could not be forced resident. > >> > >> Fri Mar 17 14:12:15 2000 > >> > >> 14:12:15 Event alarms enabled. ALARMPROG = > '/usr/informix/etc/log_full.sh' > >> 14:12:22 DR: DRAUTO is 0 (Off) > >> 14:12:23 Informix Dynamic Server Version 7.31.UC5 Software Serial > Number > >> AAC#J860464 > >> 14:12:23 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 > >> 14:12:24 Assert Failed: kaiothread() ERROR > >> 14:12:24 Informix Dynamic Server Version 7.31.UC5 > >> 14:12:24 Who: Session(0, @, 0, 0) > >> Thread(37, kaio, 0, 5) > >> File: kaio.c Line: 2121 > >> 14:12:24 stack trace for pid 2070 written to /dbwork/af.40d3d48 > >> 14:13:13 See Also: /dbwork/af.40d3d48, shmem.40d3d48.0 > >> 14:13:13 Error writing '/dbwork/shmem.40d3d48.0' errno = 28 > >> 14:13:13 kaio.c, line 2121, thread 37, proc id 2070, kaiothread() ERROR. > >> 14:13:13 PANIC: Attempting to bring system down > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> Once I reduced the shared memory parameters enough so that the memory > could > >> be locked it worked:- > >> > >> 14:50:19 Segment locked: addr=0xc1192000, size=27410432 > >> > >> Fri Mar 17 14:50:24 2000 > >> > >> 14:50:24 Event alarms enabled. ALARMPROG = > '/usr/informix/etc/log_full.sh' > >> 14:50:33 DR: DRAUTO is 0 (Off) > >> 14:50:34 Informix Dynamic Server Version 7.31.UC5 Software Serial > Number > >> AAC#J860464 > >> 14:50:35 HPUX Version B.10.20 -> Using flag/select style KAIO > >> 14:50:35 HP KAIO concurrent requests changed from 1000 to 100 > >> 14:50:38 Informix Dynamic Server Initialized -- Shared Memory > Initialized. > >> 14:50:38 Physical Recovery Started. > >> 14:50:39 Physical Recovery Complete: 0 Pages Restored. > >> 14:50:39 Logical Recovery Started. > >> 14:50:42 Logical Recovery Complete. > >> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks > >> > >> 14:50:43 Onconfig parameter BUFFERS modified from 20000 to 2000. > >> 14:50:43 Onconfig parameter CLEANERS modified from 20 to 10. > >> 14:50:43 Onconfig parameter LRUS modified from 20 to 10. > >> 14:50:43 Onconfig parameter DUMPDIR modified from /dbwork to /data. > >> 14:50:43 Onconfig parameter NUMAIOVPS modified from 30 to 4. > >> 14:50:43 Onconfig parameter SHMVIRTSIZE modified from 20480 to 10240. > >> 14:50:43 Dataskip is now OFF for all dbspaces > >> 14:50:44 On-Line Mode > >> 14:50:46 Checkpoint Completed: duration was 2 seconds. > >> 14:55:52 Checkpoint Completed: duration was 0 seconds. > >> > >> Notice the changes to the onconfig paramaters! > > > >BUFFERS cut to 10% of original? Must be a test box. > > :o)) > > > > >> > >> My concern here is that I do not have the ability to test this properly > >> before enabling it on my production server. Which obviously is a much > >> beefier setup. Has anyone else encountered this problem and Am I right > in > >> saying that this is only a problem if the shared memory cannot be forced > >> resident? > >> > > > >According to the bug report, the only thing that needs to be reset is > >the buffers of SHMVIRTSIZE. Which one gets the ax would be something > >left to testing (or monitoring, etc). > > Yep, I sorta reduced the others to keep them roughly in line with the (new) > sixe of the instance. Generally there's only me using it anyway. > > I had to reduce sizes until the memory could be locked in memory before it > worked. before I had more memory allocated to IDS than existed in the box!! > > As an aside does anyone know how uptodate the online bug list is at > informix.com? > > > > >-- > >John Carlson > >Informix DBA > >WHSmith USA > > > >#include std_disclaimer.h /* These are my opinions, not my company's > >opinion */ > > -- > --------------------------------------- > Tony Flaherty aef@mfs.misys.co.uk > Analyst Programmer > Misys Financial Systems > All statements and opinions are my own, > Misys don't pay me enough to have opinions > on their behalf > > Hi Tony, KAIO on HP-UX, my advice don't bother with it. On 10.20 HP-UX's implementation of KIO is a cludge - no doubt the HP guys out their will be outraged by this!! I tried it with 7.20 a year or two back and found that performance actually dipped by around 30%. This was on a K220 ramped up with as many processors and as much memoery as could fit in the damn thing. We also had as many full height SCSI controllers as could be fitted and it still ran like a dog. Good old fashioned AIO performed much better. I have never seen anything reported by HP or Informix that this bug has been fixed. The project used large transaction volumes (1.5 million rows) against a large database (5+ million rows in the heavy hit tables) so is quite realistic. We had to kill the job when using KAIO as it simply never finished. Also watch out for NOAGE as setting this will result in Informix hogging the CPU. Adjust the nice values of the vp's instead. Also watch the number of virtual segments, any more than three in HP-UX results in the engine spending more time doing memory management than servicing SQL requests - especially bad if you have a lot of SPL. Hope this helps. Slainte, Glyn Sent via Deja.com http://www.deja.com/ Before you buy.

↪ replying to Tony Flaherty
glyn_lewis@my-deja.com — — source: Informix-list mailing list archive (1991-1998)

In article <953556966.13870.0.nnrp-03.c1ed1f69@news.demon.co.uk>, "Tony Flaherty" <aef@mfs.misys.co.uk> wrote: > > . > Carlson@WHSmith wrote in message <38D27B49.D5E1019C@bellsouth.net>... > >Tony Flaherty wrote: > >> > >> Hi, > >> > >> HpUx 10.20 Patched to Dec 99 > >> > >> IDS 7.31.uc7 > >> > >> I've enabled this on my development server. I have a few questions. :o/ > >> > >> Firstly how do people determine the value to use for IFMX_HPKAIO_NUM_REQ > ? > >> is it a calculable figure or is it a guestimate. > > > >From what I've seen, I'd presume that it is a guesstimate. Only bump up > >the numbers if necessary, that sort of thing. > > > >> > >> Secondly, My development machine is a humble E25 with only 64Mb of RAM. > I > >> had to reduce shared memory parameters significantly before I could get > KAIO > >> to work. I think I was running into bug 110290 giving the following in > the > >> online log:- > > > >Could be . . . (too bad we can't look up bugs using a real, live bug > >number. 8-) > >> > >> 14:12:01 Shared memory segment 0xc0fe6000 could not be forced resident. > >> > >> Fri Mar 17 14:12:15 2000 > >> > >> 14:12:15 Event alarms enabled. ALARMPROG = > '/usr/informix/etc/log_full.sh' > >> 14:12:22 DR: DRAUTO is 0 (Off) > >> 14:12:23 Informix Dynamic Server Version 7.31.UC5 Software Serial > Number > >> AAC#J860464 > >> 14:12:23 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 12 > >> 14:12:24 Assert Failed: kaiothread() ERROR > >> 14:12:24 Informix Dynamic Server Version 7.31.UC5 > >> 14:12:24 Who: Session(0, @, 0, 0) > >> Thread(37, kaio, 0, 5) > >> File: kaio.c Line: 2121 > >> 14:12:24 stack trace for pid 2070 written to /dbwork/af.40d3d48 > >> 14:13:13 See Also: /dbwork/af.40d3d48, shmem.40d3d48.0 > >> 14:13:13 Error writing '/dbwork/shmem.40d3d48.0' errno = 28 > >> 14:13:13 kaio.c, line 2121, thread 37, proc id 2070, kaiothread() ERROR. > >> 14:13:13 PANIC: Attempting to bring system down > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> 14:13:13 semctl: errno = 22 > >> > >> Once I reduced the shared memory parameters enough so that the memory > could > >> be locked it worked:- > >> > >> 14:50:19 Segment locked: addr=0xc1192000, size=27410432 > >> > >> Fri Mar 17 14:50:24 2000 > >> > >> 14:50:24 Event alarms enabled. ALARMPROG = > '/usr/informix/etc/log_full.sh' > >> 14:50:33 DR: DRAUTO is 0 (Off) > >> 14:50:34 Informix Dynamic Server Version 7.31.UC5 Software Serial > Number > >> AAC#J860464 > >> 14:50:35 HPUX Version B.10.20 -> Using flag/select style KAIO > >> 14:50:35 HP KAIO concurrent requests changed from 1000 to 100 > >> 14:50:38 Informix Dynamic Server Initialized -- Shared Memory > Initialized. > >> 14:50:38 Physical Recovery Started. > >> 14:50:39 Physical Recovery Complete: 0 Pages Restored. > >> 14:50:39 Logical Recovery Started. > >> 14:50:42 Logical Recovery Complete. > >> 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks > >> > >> 14:50:43 Onconfig parameter BUFFERS modified from 20000 to 2000. > >> 14:50:43 Onconfig parameter CLEANERS modified from 20 to 10. > >> 14:50:43 Onconfig parameter LRUS modified from 20 to 10. > >> 14:50:43 Onconfig parameter DUMPDIR modified from /dbwork to /data. > >> 14:50:43 Onconfig parameter NUMAIOVPS modified from 30 to 4. > >> 14:50:43 Onconfig parameter SHMVIRTSIZE modified from 20480 to 10240. > >> 14:50:43 Dataskip is now OFF for all dbspaces > >> 14:50:44 On-Line Mode > >> 14:50:46 Checkpoint Completed: duration was 2 seconds. > >> 14:55:52 Checkpoint Completed: duration was 0 seconds. > >> > >> Notice the changes to the onconfig paramaters! > > > >BUFFERS cut to 10% of original? Must be a test box. > > :o)) > > > > >> > >> My concern here is that I do not have the ability to test this properly > >> before enabling it on my production server. Which obviously is a much > >> beefier setup. Has anyone else encountered this problem and Am I right > in > >> saying that this is only a problem if the shared memory cannot be forced > >> resident? > >> > > > >According to the bug report, the only thing that needs to be reset is > >the buffers of SHMVIRTSIZE. Which one gets the ax would be something > >left to testing (or monitoring, etc). > > Yep, I sorta reduced the others to keep them roughly in line with the (new) > sixe of the instance. Generally there's only me using it anyway. > > I had to reduce sizes until the memory could be locked in memory before it > worked. before I had more memory allocated to IDS than existed in the box!! > > As an aside does anyone know how uptodate the online bug list is at > informix.com? > > > > >-- > >John Carlson > >Informix DBA > >WHSmith USA > > > >#include std_disclaimer.h /* These are my opinions, not my company's > >opinion */ > > -- > --------------------------------------- > Tony Flaherty aef@mfs.misys.co.uk > Analyst Programmer > Misys Financial Systems > All statements and opinions are my own, > Misys don't pay me enough to have opinions > on their behalf > > Hi Tony, KAIO on HP-UX, my advice don't bother with it. On 10.20 HP-UX's implementation of KIO is a cludge - no doubt the HP guys out their will be outraged by this!! I tried it with 7.20 a year or two back and found that performance actually dipped by around 30%. This was on a K220 ramped up with as many processors and as much memoery as could fit in the damn thing. We also had as many full height SCSI controllers as could be fitted and it still ran like a dog. Good old fashioned AIO performed much better. I have never seen anything reported by HP or Informix that this bug has been fixed. The project used large transaction volumes (1.5 million rows) against a large database (5+ million rows in the heavy hit tables) so is quite realistic. We had to kill the job when using KAIO as it simply never finished. Also watch out for NOAGE as setting this will result in Informix hogging the CPU. Adjust the nice values of the vp's instead. Also watch the number of virtual segments, any more than three in HP-UX results in the engine spending more time doing memory management than servicing SQL requests - especially bad if you have a lot of SPL. Hope this helps. Slainte, Glyn Sent via Deja.com http://www.deja.com/ Before you buy.

Glossary