Linux memory management has a mechanism: when the system memory overflow, it will select one/several appropriate process kill to maintain system stability.
But the machine after all machines, although it makes every effort to choose those who are really the culprit of the process, but it is an error, or unfair, in the end system or because manslaughter and become incomplete, could not even run the farm. This time you may need to intervene, boot the system to make the right choice. This behavior is controlled by adjustment processes corresponding directory/oom_adj/proc/[PID], in which the value returned is oom_adj-17 ~ 15, when the process is-17 oom_adj, the system will not be killed it,-16 to 15 makes the process of/proc/[PID]/oom_score value exponentially (K * 2 ^ n) increments, which means that they killed the possibility of an exponential form. In addition, the universe's first process (process number 1) init nor in the killing, regardless of its value for how many oom_adj. Originally only the system resource management permissions (CAP_SYS_RESOURCE) process can do value adjustments, oom_adj now if this is the process of improving the possibility of being killed are not needed any special privileges, we really should not be deprived of it suicide or its owner intends to put it onto the cliffs. Prohibition of the process was killed by the specific action is: & nbsproot @ gentux xiaosuo # pgrepdbus-daemon45956664root @ gentux xiaosuo # cat/proc/4595/oom_score559root @ gentux xiaosuo # echo-17 >/proc/4595/oom_adjroot @ gentux xiaosuo # cat/proc/4595/oom_score0 Note: this technique is more dangerous, unless you can 100% sure you ban was killed in the process does not have a problem, or do not try to do stupid set, otherwise the consequences.
No comments:
Post a Comment