Re: Cached reads too low

I don't think you can make any inferences about your rates. The engine has been up for just one-and-a-half hours, and during this time you've run multiple imports (maybe - it's not clear from your post), and UPDATE STATISTICS which, depending upon the level, may have read all your data, none of which would be cached, to build its distributions. You can't really tell until you have a normal level of activity on the server. BTW, given v7.24 on HP-UX 10.20, have you set RESIDENT=1? You could be in the shite if you haven't. And don't try to use KAIO. Neil Truby Londis Stores Hampton Hill, UK Tony Flaherty wrote in message <922031675.11227.2.nnrp-06.c1ed1f69@news.demon.co.uk>... >Hi, > Since reorganising my system I'm getting cached read percentage too low >warnings in oncockpit, > >onstat -p> >INFORMIX-OnLine Version 7.24.UC5 -- On-Line -- Up 01:36:32 -- 176712 >Kbytes > >Profile >dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >146970 147006 477366 69.21 827 1547 9559 91.35 > >isamtot open start read write rewrite delete commit >rollbk >244897 26751 43226 108688 239 8427 239 2574 0 > >ovloc ovuserthread ovbuff usercpu syscpu numckpts flushes >0 0 0 245.21 90.87 6 56 > >bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans >281 0 355403 0 0 0 30 >1585 > >ixda-RA idx-RA da-RA RA-pgsused lchwaits >979 0 57 964 431 > >onconfig attached. > >I have twelve smallish database across five disks. I've created each >database in its own dbspace and each dbspace has one chunk, I moved them by >dbexporting and then dbimporting into the new dbspaces, editing the schema >to change the extent info as necessary. One database has some tables in a >seperate dbspace on a seperate disk for performance reasons. I've increased >NUMAIOVPS from 4 to 10, as the manual suggests two per disk. > >The only other significant changes made during the reorg are; >* Added mirroring for rootdbs, llog dbs and physlog dbs >* added multiple temp dbspaces on different disks. > >I'm not sure if I'm getting anomalous readings as I'm the only user on the >system, I'm running oncockpit and have run update statistics on each >database. During the update statistics the SHM buffers monitor in oncockpit >stayed low but the disk activity rocketed. > > >OnLine 7.24.UC5 >HP-UX 10.20 > >-- >--------------------------------------- >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 > >. > > >

What's wrong with using KAIO with HP-UX 10.20 and 7.24? We've had it set for years 7.23, 7.24, 7.30 with out problems. Scott Kolaya Fleet Services Albany, NY Neil Truby wrote in message <7d3ic0$dt5$1@taliesin.netcom.net.uk>... >I don't think you can make any inferences about your rates. The engine has >been up for just one-and-a-half hours, and during this time you've run >multiple imports (maybe - it's not clear from your post), and UPDATE >STATISTICS which, depending upon the level, may have read all your data, >none of which would be cached, to build its distributions. > >You can't really tell until you have a normal level of activity on the >server. > >BTW, given v7.24 on HP-UX 10.20, have you set RESIDENT=1? You could be in >the shite if you haven't. And don't try to use KAIO. > >Neil Truby >Londis Stores >Hampton Hill, UK > >Tony Flaherty wrote in message ><922031675.11227.2.nnrp-06.c1ed1f69@news.demon.co.uk>... >>Hi, >> Since reorganising my system I'm getting cached read percentage too low >>warnings in oncockpit, >> >>onstat -p>> >>INFORMIX-OnLine Version 7.24.UC5 -- On-Line -- Up 01:36:32 -- 176712 >>Kbytes >> >>Profile >>dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >>146970 147006 477366 69.21 827 1547 9559 91.35 >> >>isamtot open start read write rewrite delete >commit >>rollbk >>244897 26751 43226 108688 239 8427 239 2574 0 >> >>ovloc ovuserthread ovbuff usercpu syscpu numckpts flushes >>0 0 0 245.21 90.87 6 >56 >> >>bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans >>281 0 355403 0 0 0 30 >>1585 >> >>ixda-RA idx-RA da-RA RA-pgsused lchwaits >>979 0 57 964 431 >> >>onconfig attached. >> >>I have twelve smallish database across five disks. I've created each >>database in its own dbspace and each dbspace has one chunk, I moved them by >>dbexporting and then dbimporting into the new dbspaces, editing the schema >>to change the extent info as necessary. One database has some tables in a >>seperate dbspace on a seperate disk for performance reasons. I've >increased >>NUMAIOVPS from 4 to 10, as the manual suggests two per disk. >> >>The only other significant changes made during the reorg are; >>* Added mirroring for rootdbs, llog dbs and physlog dbs >>* added multiple temp dbspaces on different disks. >> >>I'm not sure if I'm getting anomalous readings as I'm the only user on the >>system, I'm running oncockpit and have run update statistics on each >>database. During the update statistics the SHM buffers monitor in >oncockpit >>stayed low but the disk activity rocketed. >> >> >>OnLine 7.24.UC5 >>HP-UX 10.20 >> >>-- >>--------------------------------------- >>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 >> >>. >> >> >> > >

I have set RESIDENT = 1 but I get a message saying that this is not supported! :o( I have not yet had chance to check the machine specific release notes. -- --------------------------------------- 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 . Neil Truby wrote in message <7d3ic0$dt5$1@taliesin.netcom.net.uk>... >I don't think you can make any inferences about your rates. The engine has >been up for just one-and-a-half hours, and during this time you've run >multiple imports (maybe - it's not clear from your post), and UPDATE >STATISTICS which, depending upon the level, may have read all your data, >none of which would be cached, to build its distributions. > >You can't really tell until you have a normal level of activity on the >server. > >BTW, given v7.24 on HP-UX 10.20, have you set RESIDENT=1? You could be in >the shite if you haven't. And don't try to use KAIO. > >Neil Truby >Londis Stores >Hampton Hill, UK > >Tony Flaherty wrote in message ><922031675.11227.2.nnrp-06.c1ed1f69@news.demon.co.uk>... >>Hi, >> Since reorganising my system I'm getting cached read percentage too low >>warnings in oncockpit, >> >>onstat -p>> >>INFORMIX-OnLine Version 7.24.UC5 -- On-Line -- Up 01:36:32 -- 176712 >>Kbytes >> >>Profile >>dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >>146970 147006 477366 69.21 827 1547 9559 91.35 >> >>isamtot open start read write rewrite delete >commit >>rollbk >>244897 26751 43226 108688 239 8427 239 2574 0 >> >>ovloc ovuserthread ovbuff usercpu syscpu numckpts flushes >>0 0 0 245.21 90.87 6 >56 >> >>bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans >>281 0 355403 0 0 0 30 >>1585 >> >>ixda-RA idx-RA da-RA RA-pgsused lchwaits >>979 0 57 964 431 >> >>onconfig attached. >> >>I have twelve smallish database across five disks. I've created each >>database in its own dbspace and each dbspace has one chunk, I moved them by >>dbexporting and then dbimporting into the new dbspaces, editing the schema >>to change the extent info as necessary. One database has some tables in a >>seperate dbspace on a seperate disk for performance reasons. I've >increased >>NUMAIOVPS from 4 to 10, as the manual suggests two per disk. >> >>The only other significant changes made during the reorg are; >>* Added mirroring for rootdbs, llog dbs and physlog dbs >>* added multiple temp dbspaces on different disks. >> >>I'm not sure if I'm getting anomalous readings as I'm the only user on the >>system, I'm running oncockpit and have run update statistics on each >>database. During the update statistics the SHM buffers monitor in >oncockpit >>stayed low but the disk activity rocketed. >> >> >>OnLine 7.24.UC5 >>HP-UX 10.20 >> >>-- >>--------------------------------------- >>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 >> >>. >> >> >> > >

In article <VAiJ2.166$Hs2.321@typhoon.nycap.rr.com>, "Scott Kolaya" <skolaya1@nycap.rr.com> wrote: > What's wrong with using KAIO with HP-UX 10.20 and 7.24? > > We've had it set for years 7.23, 7.24, 7.30 with out problems. > > Scott Kolaya > Fleet Services > Albany, NY > Absolutely agree. What impact KAIO has on caching ? With best regards, Juri Dovgart, Bank's "Ukraine" System Administrator. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

When we upgraded from v7.13 -> v7.24 UC6 we had all sorts of problems. Firstly we had a five week hiatus whereby our server would freeze. After weeks of low grade HP and Informix investigation, beefed up when some bigger customers and banks started having identical problems, it was finally HP who told us that there was a known problem and that we must set RESIDENT=1. This did, in conjunction with a few HP-UX patches, fix our problem. Then we went live, and ran into a bug in Informix v7.24 that makes KAIO operations run extremely slowly (and I mean a factor of ten slower than UNIX I/O) . Of course, Tech Support didn't tell us about until AFTER we'd gone live, and endured three days of performance hell. I can give you the bug number of you like. Perhaps it just relates to v7.24 UC6. It's certainly fixed in v7.30, and was not present in v7.13. Or perhaps you're experiencing the slow i/o on your v7.24 servers but not noticing it? regards Neil Scott Kolaya wrote in message ... >What's wrong with using KAIO with HP-UX 10.20 and 7.24? > >We've had it set for years 7.23, 7.24, 7.30 with out problems. > >Scott Kolaya >Fleet Services >Albany, NY > >Neil Truby wrote in message <7d3ic0$dt5$1@taliesin.netcom.net.uk>... >>I don't think you can make any inferences about your rates. The engine has >>been up for just one-and-a-half hours, and during this time you've run >>multiple imports (maybe - it's not clear from your post), and UPDATE >>STATISTICS which, depending upon the level, may have read all your data, >>none of which would be cached, to build its distributions. >> >>You can't really tell until you have a normal level of activity on the >>server. >> >>BTW, given v7.24 on HP-UX 10.20, have you set RESIDENT=1? You could be in >>the shite if you haven't. And don't try to use KAIO. >> >>Neil Truby >>Londis Stores >>Hampton Hill, UK >> >>Tony Flaherty wrote in message >><922031675.11227.2.nnrp-06.c1ed1f69@news.demon.co.uk>... >>>Hi, >>> Since reorganising my system I'm getting cached read percentage too >low >>>warnings in oncockpit, >>> >>>onstat -p>>> >>>INFORMIX-OnLine Version 7.24.UC5 -- On-Line -- Up 01:36:32 -- 176712 >>>Kbytes >>> >>>Profile >>>dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >>>146970 147006 477366 69.21 827 1547 9559 >91.35 >>> >>>isamtot open start read write rewrite delete >>commit >>>rollbk >>>244897 26751 43226 108688 239 8427 239 2574 0 >>> >>>ovloc ovuserthread ovbuff usercpu syscpu numckpts flushes >>>0 0 0 245.21 90.87 6 >>56 >>> >>>bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans >>>281 0 355403 0 0 0 30 >>>1585 >>> >>>ixda-RA idx-RA da-RA RA-pgsused lchwaits >>>979 0 57 964 431 >>> >>>onconfig attached. >>> >>>I have twelve smallish database across five disks. I've created each >>>database in its own dbspace and each dbspace has one chunk, I moved them >by >>>dbexporting and then dbimporting into the new dbspaces, editing the schema >>>to change the extent info as necessary. One database has some tables in a >>>seperate dbspace on a seperate disk for performance reasons. I've >>increased >>>NUMAIOVPS from 4 to 10, as the manual suggests two per disk. >>> >>>The only other significant changes made during the reorg are; >>>* Added mirroring for rootdbs, llog dbs and physlog dbs >>>* added multiple temp dbspaces on different disks. >>> >>>I'm not sure if I'm getting anomalous readings as I'm the only user on the >>>system, I'm running oncockpit and have run update statistics on each >>>database. During the update statistics the SHM buffers monitor in >>oncockpit >>>stayed low but the disk activity rocketed. >>> >>> >>>OnLine 7.24.UC5 >>>HP-UX 10.20 >>> >>>-- >>>--------------------------------------- >>>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 >>> >>>. >>> >>> >>> >> >> > >

>Absolutely agree. What impact KAIO has on caching ? None of course. But see my reply to the previous message in the thread. Neil

Here's the stuff I got from Tech Support: ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- -- >ere is a performance bug which affects Informix on HP/UX with kernel >AIO specifically. >It is fixed from 7.24.UC8. >Since there are various problems with kernel AIO on HP/UX, if you are >using kernel AIO you could see if turning it off will help with your >performance problem. > > >Bug: 92132 HP KAIO HAS A SIGNIFICANT I/O BOTTLENECK WHICH CAN CAUSE 30% >TO 75% IN PERFORMANCE > > >Description: >The general symptom of the problem is that HP KAIO (native kernel >async I/O) is *much* slower than Informix AIO. The impact is >anywhere from 30% to >100% slowdown in disk I/O. > >The problem lies in the server's I/O polling mechanism. When the >server issues an I/O request through KAIO, it must poll the HP-UX >asynchronous driver to determine when the request has been >fulfilled. If a request has not yet been filled, the I/O thread may >choose to go to sleep for 10 milliseconds before checking the request >status again. Up through ODS 7.1, the I/O thread would sleep using a >select() system call. This was changed in 7.2 to use the newer and >lighter nanosleep() system call. Performance tests showed this was >lighter on the CPU, and still gave us the desired sleep behavior. >Sometime after 7.2 was released (we believe), nanosleep() was changed >to correctly conform to its IEEE standard. One of the impacts is >that we can no longer sleep for just 10 milliseconds. On average, >the I/O thread is now sleeping for almost twice that long (when it >does not need to) and this is why we believe KAIO performance has >gotten so much worse ---------------------------------------------------------------------------- ------------------------------------------------------------------------ dua1@my-dejanews.com wrote in message <7d4vjm$3e1$1@nnrp1.dejanews.com>... >In article <VAiJ2.166$Hs2.321@typhoon.nycap.rr.com>, > "Scott Kolaya" <skolaya1@nycap.rr.com> wrote: >> What's wrong with using KAIO with HP-UX 10.20 and 7.24? >> >> We've had it set for years 7.23, 7.24, 7.30 with out problems. >> >> Scott Kolaya >> Fleet Services >> Albany, NY >> >Absolutely agree. What impact KAIO has on caching ? > >With best regards, Juri Dovgart, >Bank's "Ukraine" System Administrator. > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

In article <7d5k7j$suo$1@taliesin.netcom.net.uk>, Neil Truby <ntruby@netcomuk.co.uk> writes >Here's the stuff I got from Tech Support: Check the FAQ at ww.smooth1.demon.co.uk. It includes a section on HP-UX and KAIO. There were several methods of KAIO used and 7.30 uses the best method.. >>Absolutely agree. What impact KAIO has on caching ? >> >>With best regards, Juri Dovgart, >>Bank's "Ukraine" System Administrator. >> >>-----------== Posted via Deja News, The Discussion Network ==---------- >>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own > > -- David Williams