RAC LMS processes
Background Processes
From 10g and over, Real Application Cluster databases has two new background processes:
LMON – The Global Enqueue Service Monitor monitors the entire cluster to manage the global enqueues and the cluster resources. LMON manages instance and process failures and the associated recovery for the Global Cache Service (GCS) and Global Enqueue Service (GES). In particular, LMON handles the part of recovery associated with global resources. LMON-provided services are also known as cluster group services (CGS)
LMD – The Global Enqueue Service Daemon is the lock agent process that manages enqueue manager service requests for GCS (Global Cache Service) enqueues to control access to global enqueues and resources. The LMD process also handles deadlock detection and remote enqueue requests. Remote resource requests are the requests originating from another instance. LMS processes serve both consistent and current versions of blocks in cache of local instance to other instances and maintain local part of Global Resource Directory
LMS process priority
Increasing LMS process priority to RT or FX helps. Oracle has already identified this potential issue in release 10g, this issue is taken care of, and LMS processes are running with RT priority. This fixes and alleviates many issues with global cache transfer.
Controlling LMS behaviour
1. _high_priority_processes: Controls processes that will have higher priority and v$parameter specifies this as “High priority process name mask” with default value of LMS*.
2. _os_sched_high_priority: This controls whether OS scheduling high priority is enabled or not, defaults to 1.
Note: Prior to Oracle 10.1, could be configured using _lm_lms parameter, in Oracle 10.1 and above, initial number of LMS processes ified by gcs_server_processes parameter.
Reducing LMS process to a very minimal level also has a bad effect, so do not reduce it to 1. From Version 10g and up, instance reconfiguration is done in parallel and LMS process are involved in instance reconfiguration. If you reduce parallelism to a small number then instance reconfiguration performance can suffer generating another peformance problem, of course this affects object remastering too as the object remastering involves instance reconfiguration, this happens automatically between instances.
Bind LMS ?
I heard binding is another option, bind LMS and LGWR processes to specific processors or processor sets. This should reduce TLB thrashing and improve efficiency of LMS/LGWR processes, unfortunately I have not experience making this change, but it is supposed it works as expected. I think processor binding is only applicable to servers with high numbers of CPUs and has repercussions on availability, making this change requires full understanding of your operating system technology, talk with your sysadmin before decide to put this in production.
Recommended LMS processes
Same number of LMS processes as number of interconnects or number of remote nodes is an excellent starting point. Example, in a four node cluster, three LMS processes per node is usually sufficient, in two nodes configuration, two LMS processes are enough too, both last examples are just to starting, in the feature will be very probable that you need to increase according with your workload.
