solidDB Help : solidDB reference : solidDB ADMIN COMMAND syntax : PERFMON LIST : MME counters
  
MME counters
The pmon MME counters are described in the following table:
 
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
Go up to
PERFMON LIST