R
RussellAdams
Guest
Paul Koufalis I had a very similar issue going from p6 to p7 and it turned out to be a UNIX SILENT chmod that was run half a million times. I'm not saying this is your issue, but it's definitely time to think outside the box. Was this a cron job making changes? That would show up as high disk busy due to the IO in the inode table. Paul Koufalis 1. You said you think it's a whole string of jobs run one-after-the-other. Find out how long EACH one takes on the old box vs. the new box. That way we can see if it's a generalized issue or one particular job that is misbehaving. 2. Get some DB stats. Download protop (dbappraise.com/protop.html) and use it to see what's going on. ProTop is much more information-dense than promon. Are these read-intensive or write-intensive batch jobs? 3. Triple-check the DB startup parameters. This could very well be an "oops!" moment. Don't forget BI block size and cluster size. I'll send that to our DBA to check. Paul Koufalis 4. Truss the processes and see if they are doing anything interesting at the kernel level. IBM has a post-truss cruncher that chews up the output and spits out a nice report. That's how we saw the UNIX SILENT issue: abnormally high fork()'s . I intend to. The IBM team has trussed our ndisk, but not the main app. Paul Koufalis 5. Are you running OpenEdge Replication too? No. Paul Koufalis 6. Did you dump and load going from the old box to the new? Or make any changes to the DB like storage area stuff? We reorganized to add many more disks. We have much more IO capacity now, and dedicated filesystems per DB where they were shared before.
Continue reading...
Continue reading...