Know more _high_priority_processes   LMS process priority? In release 9i, increasing LMS process priority to RT or FX (with larger CPU quanta scheduling schemes) helps. Oracle Corporation has already identified this potential issue and in release 10g, this issue is taken care of, and LMS processes are running with RT priority. This alleviates many issues with global cache transfer. Two parameters control this behaviour2: a. _high_priority_processes: This controls processes that will have higher priority and v$parameter specifies this as ¡°High priority process name mask¡± with default value of LMS*. b. _os_sched_high_priority: This controls whether OS scheduling high priority is enabled or not and defaults to 1.
  In Oracle11g, it is NOT RECOMMENDED TO USE OS facilities like ¡°chrt¡± or ¡°priocntl¡± to manually manipulate the scheduling classes of Oracle background processes. This is extremely important for Oracle to be able to keep track of which processes are running in RT and which ones are not. Process scheduling classes should only be manipulated using the _HIGH_PRIORITY_PROCESSES parameter as described below.   _HIGH_PRIORITY_PROCESSES is a new underscore parameter that specifies which processes should run in RT class. The default value is “LMS*|VKTM”, meaning that the LMSn and VKTM processes would automatically run in RT at instance startup. If, for some reason you decide to run your LMSn processes in time-sharing scheduling class (TS), change this parameter value to “VKTM”, which means that Oracle will only manipulate the scheduling class for VKTM. _OS_SCHED_HIGH_PRIORITY is another parameter related to process scheduling class manipulation. The default value is 1, and changing this to 0 means that all scheduling class manipulation will be disabled, regardless of the values set for _HIGH_PRIORITY_PROCESSES. We strongly recommend leaving this parameter set to 1, and to only manipulate the scheduling classes using _HIGH_PRIORITY_PROCESSES. If everything were configured correctly, the following messages indicating that VKTM and LMSn are running in RT class would appear in the alert log. Alternatively, you could also use the “ps” command to see which scheduling class each process is running at. VKTM started with pid=3, OS id=14839 at elevated priority LMS0 started with pid=10, OS id=14857 at elevated priority   If you do not see these messages, Oracle has failed to manipulate the scheduling class for some reason. To understand the cause of the failure, check the trace file for each process to see if there is an error. A common cause of failure would be incorrect permissions on the oradism binary. ksesethighpri:(ksb.c:3489) Failed to elevate LMS0's priority from 0 to 1 Error Info: Category(-2), Opname(skgdism_create), Loc(sp.c:1612),\ ErrMsg(Error 0) Dism(-1073762366) Increasing the priority of other, non-RAC related background processes such as DBWR or LGWR is generally not advised unless performed in a benchmark environment