Pmon
|
Description
|
---|---|
MME cur num of locks
|
Current number of MME locks.
Increasing values can indicate an application locking issue.
Locking for the in-memory engine is handled separately to locking in the disk-based engine.
|
MME max num of locks
|
Peak number of MME locks (since startup).
Increasing values can indicate an application locking issue.
Use this counter in conjunction with the MME cur num of locks counter to watch for an excessive number of locks.
|
MME cur num of lock chains
|
Current no. MME hash buckets.
A lock chain occurs when the lock hash table has a conflict and additional locks are added to the hash entry as additional entries. This addition can slow down lock lookup because it has to first find the chain entry in the hash table, then parse the subsequent entries.
Subtracting the value of this counter from the MME cur num of locks counter gives the number of additional hash entries in the hash table. A large number of additional hash entries degrades performance. In this case, consider increasing the MME.LockHashSize parameter.
|
MME max num of lock chains
|
Peak no. MME hash buckets (since startup)
|
MME longest lock chain path
|
MME: longest hash overflow path
|
MME mem used by tuples
|
MME memory allocated to tuples in kilobytes.
Tuples are an internal version of MME rows. This counter is the amount of memory needed to store all the rows of the in-memory tables. The counter value can be correlated to the total number of rows to determine the average row size (including overhead).
|
MME mem used by indexes
|
MME memory allocated to indexes in kilobytes.
Higher than expected values could indicate unnecessary indexes.
|
MME mem used by page structs
|
MME memory allocated to the shadow structures in kilobytes.
A page struct is the overhead needed for storing MME table and index data.
|
MME page splits
|
Number of MME page splits
|
MME page joins
|
Number of MME page joins
|
MME unnec mutexed searches
|
Number of MME rows fetched while unnecessarily in exclusive mode
|
MME nonmatched (RO)
|
Number of MME rows that did not match search criteria fetched in shared mode
|
MME nonmatched (EXCL)
|
Number of MME rows that did not match search criteria fetched in exclusive mode
|
MME inserts with x gate
|
Number of inserts done in exclusive mode. Insert switches from shared mode to exclusive mode for example, when the insert causes index node split.
|
MME deletes with x gate
|
Number of MME deletes performed in exclusive mode
|
MME hotspot protection
|
Number of times an MME search enters exclusive mode to access a hotspot
|
MME index key inserts
|
Total number of insert operations on in-memory tables, including keys inserted during a database recovery (not accurate1).
Note An UPDATE operation translates to delete then insert in MME tables.
|
MME index key deletes
|
Total number of delete operations on in-memory tables (not accurate1).
Note An UPDATE operation translates to delete then insert in MME tables.
|
MME bnode resizes
|
Number of times a MME bnode has been resized
|
MME vtrie mutex collisions
|
Number of times optimistic mutexing in vtrie has collided (not accurate1, congestion2).
An increase in this counter means that several threads are trying to update the same information and are getting blocked.
|
MME vtrie version colls
|
Number of times a version check in vtrie has collided (not accurate1, congestion2).
For an update operation, a vtrie node gets a version update structure added to it. When another application views the same data that is currently being updated, the vtrie update structure is read, which results in a "vtrie version collision."
A high value might mean that a "hot" section of data is being updated and read often. Specifically, values in the thousands or tens of thousands along with a significantly smaller number of updates can indicate a problem in the application, perhaps with more frequent commits.
|
MME vtrie vertical splits
|
Number of times a search path in vtrie has been vertically split by a key insert (not accurate1)
|
MME vtrie new branches
|
Number of times a new branch has been added to a vtrie node (not accurate1)
The approximate branching factor of the vtrie can be calculated as
(MME vtrie new branches - MME vtrie branch deletes) / (MME vtrie vertical splits - MME vtrie vertical joins) + 2.
This branching factor is only for the vtrie part of the index, the bnode leaf level branching factor cannot be estimated.
|
MME vtrie vertical joins
|
Number of times a key delete from vtrie has caused a node on the search path to be deleted (not accurate1)
|
MME vtrie branch deletes
|
Number of times a key delete from vtrie has caused a branch to be removed from a vtrie node (not accurate1)
|
MME vtrie search retries
|
Number of vtrie search retries per second
|
MME vtrie insert retries
|
Number of times a vtrie insert has been retried because of a collision (not accurate1, congestion2)
|
MME vtrie delete retries
|
Number of times a vtrie delete has been retried because of a collision (not accurate1, congestion2)
|
MME bnode mutex collisions
|
Number of times bnode accesses have caused a mutex collision (not accurate1, congestion2)
|
MME bnode version colls
|
Number of times bnode accesses have failed because of a version collision (not accurate1, congestion2)
|
MME purge invalidations
|
Number of purge invalidations per second
|
MME ffmem privctx init
|
Internal use only
|
MME ffmem privctx done
|
Internal use only
|
MME ffmem purge
|
How frequently in seconds the purge routine is called
|
MME ffmem purge step
|
How frequently in seconds the purge step routine is called
|