Forum Post: RE: 11.3.2: default -omsize & high number of MTL_OM latches

  • Thread starter Thread starter Richard Banville
  • Start date Start date
Status
Not open for further replies.
R

Richard Banville

Guest
To avoid om “paging”, you can increase the -omsize at runtime using the increaseto options of proutil. To avoid OM latching, yes, increase the –omsize at startup. All data access to the database (table, index, lob) goes through a mapping layer to determine the location of the object being requested. Objects that do not fit in the primary om cache will spill over to the secondary om cache. The secondary cache can page entries and maintains an LRU list of items in the cache. If everything fits in the primary om cache, there is no latching. Any lookup in the secondary cache requires latching for synchronization. Thus all data mapping of objects whose mapping information is in the secondary cache is single threaded. This can cause a bottleneck when accessing data. It is not possible to tell you the expected performance gain for your deployment however, it is something that should be addressed. From: toomaskask [mailto:bounce-toomaskask@community.progress.com] Sent: Thursday, October 16, 2014 11:41 AM To: TU.OE.RDBMS@community.progress.com Subject: [Technical Users - OE RDBMS] 11.3.2: default -omsize & high number of MTL_OM latches 11.3.2: default -omsize & high number of MTL_OM latches Thread created by toomaskask Hi! Just checked one of our databases and found that number of MTL_OM latches is pretty high: _Latch-Name _Latch-Lock _Latch-Wait latch/sec MTL_OM 4483906701 6844 4,483,906,701 MTL_OM 4483914640 6844 7,939 MTL_OM 4483922014 6844 7,374 MTL_OM 4483927715 6844 5,701 MTL_OM 4483933176 6844 5,461 MTL_OM 4483937684 6844 4,508 MTL_OM 4483941763 6844 4,079 MTL_OM 4483948088 6844 6,325 MTL_OM 4483969421 6844 21,333 MTL_OM 4484037072 6844 67,651 MTL_OM 4484104383 6844 67,311 MTL_OM 4484112012 6844 7,629 MTL_OM 4484117447 6844 5,435 MTL_OM 4484185073 6844 67,626 MTL_OM 4484206032 6844 20,959 MTL_OM 4484327023 6844 120,991 MTL_OM 4484353623 6844 26,600 Actual number of _storageobject records is 1600. Should I set -omsize to 2048 and expect something? Lower load? Increase in speed? Because of nature of our systems, it's almost impossible to set up full proper test environment, so I can change parameters only in production system. wbr, Toomas Stop receiving emails on this subject. Flag this post as spam/abuse.

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