Anduvimos investigando por diferentes foros y así tener para ti la respuesta a tu inquietud, si continúas con preguntas puedes dejar la duda y te contestamos porque estamos para servirte.
Solución:
Solución 1:
Puede encontrar la documentación en man 5 proc (o en kernel.org):
/proc/sys/vm/overcommit_memory This file contains the kernel virtual memory accounting mode. Values are: 0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very weak, leading to the risk of getting a process "OOM-killed". In mode 2 (available since Linux 2.6), the total virtual address space that can be allocated (CommitLimit in /proc/mem‐ info) is calculated as CommitLimit = (total_RAM - total_huge_TLB) * overcommit_ratio / 100 + total_swap
La respuesta simple es que establecer overcommit en 1 preparará el escenario para que cuando un programa llame a algo como malloc() para asignar un trozo de memoria (man 3 malloc), siempre tendrá éxito, independientemente de que el sistema sepa que no tendrá toda la memoria que se solicita.
El concepto subyacente a entender es la idea de memoria virtual. Los programas ven un espacio de direcciones virtuales que puede o no estar asignado a la memoria física real. Al deshabilitar la verificación de compromiso excesivo, le dice al sistema operativo que suponga que siempre hay suficiente memoria física para hacer una copia de seguridad del espacio virtual.
Ejemplo
Para resaltar por qué esto a veces puede ser importante, eche un vistazo a las guías de Redis sobre por qué vm.overcommit_memory debe establecerse en 1 para ello.
Solución 2:
Esta es una vieja pregunta con una respuesta bien establecida, pero creo que hay más para agregar.
En primer lugar, cuando vm.overcommit_memory = 0la vm.overcommit_ratio el valor es irrelevante. El núcleo utilizará un algoritmo heurístico para sobrecargar la memoria, de modo que su amarok al proceso se le puede asignar más memoria de la que está disponible.
cuando configuras vm.overcommit_memory a 2la vm.overcommit_ratio el valor se vuelve relevante. De forma predeterminada, este valor se establece en 50, lo que significa que el sistema solo asignaría hasta el 50% de su RAM (más intercambio). Esto explica por qué no puede iniciar programas que estaban bien cuando vm.overcommit_memory = 0 – porque hay menos de 500 MB de memoria asignable (suponiendo que no haya intercambio).
Cuando lo configuras 300está permitiendo que el sistema asigne hasta el 300% de su RAM (más el intercambio, si corresponde), razón por la cual el CommitLimit valor en /proc/meminfo es tan alto
A pesar de que vm.overcommit_memory = 2 generalmente se usa para evitar el compromiso excesivo, aquí lo está usando para limitar la cantidad que se puede comprometer en exceso. Configurándolo en 300 es peligroso ya que su sistema no tiene 5171884 kB de memoria y, por lo tanto, según la cantidad de espacio de intercambio que tenga, el sistema usará el intercambio (que es lento) o se quedará sin memoria por completo.
Como qué amarok utiliza más memoria cuando vm.overcommit_memory = 2 – esto es probablemente porque amarok funciona mejor con más memoria, pero también está bien con menos. Entonces, la lógica del programa puede intentar asignar 2 GB de memoria inicialmente, pero si falla, intente con 1 GB.
valoraciones y comentarios
Puedes estimular nuestra ocupación poniendo un comentario y puntuándolo te estamos agradecidos.