| Resolution | MUX in general terms:
- -mux is a non-documented database startup parameter used to disable/enable certain latch functionality and may be used when debugging latch issues.
- mux latches are a special latching mechanism used to synchronize access to memory tables such as, lock tables and buffer management tables, at a finer granularity than without mux latching.
- The access is synchronized at the hash chain level rather than at the hash table level.
- mux latching is only ever available when -spin is enabled, which is by default in later OpenEdge releases on Enterprise databases. Whether -spin is enabled or not can be determined by reviewing the database log file messages during database startup. The "Current Spin Lock Tries (-spin)" message that shows the value of the -spin startup parameter. If it's greater than 0 then -spin is enabled.
-spin and -mux are two different latching mechanismsTo understand -mux 0 to disable mux latching, we also need to include -spin in the discussion.
Locking underlies all database functions. Among the complete set of spinlocks used by the database there is one group that governs access to the RM chain, a key structure used to manage blocks in memory. The concept is to use an interleaved set of spinlocks rather than a single one - this allows locking operations to be spread more evenly across the chain and thus reduce any bottleneck on access to blocks by database functions.
Using "-mux 0" turns off the use of this interleaved set of locks and reverts behavior to a single spinlock governing the entire chain, thereby reducing the number of spinlocks in play. There is a performance impact as a result, but the reasoning behind setting " -mux 0 " is to investigate if it high rates of lock contention may be exposing a timing window in the Progress code.
Running "-spin <value>" and "-mux 0" will not turn off -spin.
- -mux 0 introduces the dropping out the use of a small set of the total number of latches in the database.
- With -mux 0, there are still a lot of spinlocks still being used when the -spin parameter is in use.
- The system will continue to use the -spin latching algorithm but will perform larger grained synchronization of these tables thereby decreasing concurrency.
- Most users see a degradation in performance when going from -spin to -spin with -mux 0 and it is possible on some systems that using -mux 0 would be intolerable.
Running without -spin, means that absolutely no high-speed spinlocks will be used.
- -spin -0" uses operating semaphores instead, using the mtlatch() and mtunlatch() routines, which also means that the mux latches are no longer involved at all.
- When -spin is set system semaphores are used, using the mtlkmux() and mtfrmux() routines, which is why there is a performance gain in using it, (maybe as much as 20%).
The advice and earlier information surrounding -mux0, when it was first introduced, was related to issues with later releases of the Progress 9.1C version on SCO platforms. At that time Progress worked directly with Unixware developers to make a small change to our spinlock code to assure that we gave guaranteed correct operation on Xeon processors. The problem initially, was that some operations were changed by Intel to no longer be atomic (executed as one entity). The changes were made, and code reviewed by Unixware and have since been a part of later Progress versions. Since then, we have not seen the type of problems that triggered the previous investigations.
In Progress 9.1C, the -mux 0 startup parameter was introduced to address the spinlock investigation. Since Progress 9.1D, we further improved the performance of locking and there should be no need to use the -mux 0 startup parameter. |
|
|---|
