Slower table creation with C-ISAM on newer AIX har
Answered: amber (solid confidence) — The first suggested cause (AIX auditing) was ruled out by the asker; a later, much more detailed reply attributes the slowdown to AIX 7/Power7 SMT and CPU-entitlement tuning, matching the symptoms well, but is never confirmed by the asker.
Advisory only.
Posted in 2015
Topics: Platform-Specific Issues
AIX 5 server vs New AIX 7 server C-ISAM 7.26.UC3 We have tried it both ways. Building this table that has about 370,000 records with 16 indexes, some of which are up 46 characters long, by loading the data, then building the indexes took over 3 and 1/2 hours. Loading and building the indexes simultaneously, it took 19 minutes. This is on a new AIX version 7 box. On their current AIX version 5 box, loading and then building the indexes takes 12 minutes and doing it with each record takes 6 minutes. We have heard that some processes will take longer with the new architecture, but 3 and a half hours is ridiculous. Does anyone have any suggestions as to how we can reduce the processing time on the new server running AIX 7 to be no longer than the time it took on the old hardware running AIX 5? Larry
Larry, Check with the system admin to see if aix auditing is being used. http://www-01.ibm.com/support/docview.wss?uid=isg3T1000212#3 Regards, Mark
Mark, Auditing was not turned on, but thank you for trying. Larry > To: ids@iiug.org > From: mark.jalkiewicz@verizon.net > Subject: Re: Slower table creation with C-ISAM on newer.... [34535] > Date: Thu, 29 Jan 2015 16:36:41 -0500 > > Larry, > > Check with the system admin to see if aix auditing is being used. > > http://www-01.ibm.com/support/docview.wss?uid=isg3T1000212#3 > > Regards, > > Mark > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Larry - Did a large migration/data center move to AIX 7.1 and p7 hardware this summer. Less cores, more threads per core was the pitch as to "performance will be fine." We had quite a few days of somewhat random poor performance. Engine ready queues would hit 200-300 - you can imagine how overall performance of the engine was at that point. We started watching the threads per core on the box. Threads 1 & 2 were very busy, but threads 3 & 4 were nearly asleep. Any oninits getting pushed onto those threads were awful. We finally turned SMT from 4 to 2 (shows as "ON" when it's 2 in lparstat or vmstat (can't remember which for sure), but "4" when set to 4). This appeared to solve the issues. We also had to crank up entitlement from 2 on the old h/w to 8 on the new h/w. Anytime we'd go above our entitlement we'd see more processors being taken from the pool, but the overhead is tremendous according to IBM tech support. We were very surprised that we had to "detune" the new h/w (turn off 2 threads per core), and increase entitlement by 4X. There is a white paper (or two) out there from IBM on this issue. Sorry - don't have the link but it's the SMT that we had to change if you want to google it. Hope this helps - Mark Scranton The Mark Scranton Group "All Informix ... all the time" mark@markscranton.com