C
ChUIMonster
Guest
Latching is extremely sensitive to cpu affinity. 128 CPUs is a very, very bad thing for a database server. A server with 128 CPUs probably makes a great web server. It is not an appropriate database server. Aside from that... Noticing that you have possibly excessive latch timeouts is just the first step. You then need to know *which* latch is responsible. Your corrective actions will vary depending on whether the issue is excessive LRU waits or MTX waits. Or BHT waits. Or one of the BF latches. It can also depend on what version of OpenEdge you are running. Once you know which latch is involved (hopefully just one will stick out) you might be able to "treat the symptoms" via -spin or -lruskips or something simple like that. On the other hand you might not. If it is MTX, for instance, then you probably have to do something like stop using RAID5 on a SAN for your bi file. Ultimately you want to get to the problem behind the problem. In many cases this is going to be the behavior of 4gl code. For instance, a very frequent driver of excessive latch requests is 4gl code that is hammering on a small set of records. So you probably want to correlate latch requests with table and index activity at the detailed table and index level. And then you probably want to tie that back to particular user sessions if it is narrowly focused activity, or you want to find the frequently used bits of code that are responsible. I should mention that ProTop does many of these things for you and would save you a lot of development time. And has nice pretty Grafana charts too. wss.com/.../
Continue reading...
Continue reading...