[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: The -hashLatchFactor parameter in Service Pack 11.7.3

Status
Not open for further replies.
U

unguyen

Guest
Hi George, This is a our sample results for BHT latch (-hashLatchFactor) testing on Linux64 platform with Progress version 117.3. (Please see the attachment) For the database setup: 1. we created an empty database and then loaded a .df file to create schema for 2 tables: Customer and Order. Their data and indexes located on type II areas 2. Created 1,050,000 records for table order. 3. backed up the database for testing. Test cases: For each test case, we started the database with -B 200000 -spin 1000 -lruskips 100 -semsets 93 -hash -hashLatchFactor We started the DB with 10 different cases, and we only changed one value for each case: EX: case 1: -hash 1000 -hashLatchFactor 5 case 2: -hash 1000 -hashLatchFactor 10 case 3: -hash 1000 -hashLatchFactor 100 case 4: -hash 10000 -hashLatchFactor 100 ... preloaded the buffer pool, and used Customer table as a gate to make ensure all clients started at the same point. We launched 20 self-service clients simultaneously to query table Order in 2 ways: - randomly: 20 clients read (NO LOCK) randomly in its' assigned range based on OrderNum: client 1 can read randomly from OrderNum 100,000 - 149,999 client 2 can read randomly from OrderNum 200,000 - 249,999 ... - sequential access: 20 clients read (NO LOCK) on the same 100 records with OrderNum between 900,000 to 900,100 Each client read 1 million times. While all clients were reading data, test script would snapshot promon every 3 seconds to open the Latch Count page (R&D -> debghb -> 6 -> 11) and recorded the "naps/sec" for BHT. Average "naps/sec" would be calculated for each case after that case was done. Please see the attached spreadsheet recording the "naps/sec" (the bigger number, the more contention) For random access scenarios, with same -B and -hash, we can see increasing the -hashLatchFactor can help to reduce the contention. For sequential access scenarios, with same -B and -hash, naps/sec is similar when increasing the -hashLatchFactor, because the users are contenting on the same blocks. Beside the -hashLatchFactor, from the result, we can see increasing the -hash will also help, because the -hashLatchFactor depends on the -hash. To conclude, there are a lot of factors to consider the right value for -hashLatchFactor. It depends on: - data allocation - number of users accessing the BHT - queries - buffer pool, BHT's size ... In general, user can monitor the promon screen, check the contention ("naps/sec") for the BHT to determine what value of -hashLatchFactor is right for his/her environment. (Please visit the site to view this file)

Continue reading...
 
Status
Not open for further replies.
Top