Posteriormente a consultar especialistas en la materia, programadores de diversas ramas y maestros hemos dado con la solución al problema y la compartimos en este post.
Solución:
Solución 1:
kswapd gestiona el espacio de intercambio en respuesta a demandas de memoria superiores a las físicamente disponibles para todos procesos.
Es independiente del proceso, solo está interesado en a qué páginas se accede y cuándo (es más complejo que esto, por supuesto, pero para simplificar las cosas, también podemos verlo de esta manera).
Entonces el real la pregunta es “¿qué procesos tienen la mayor carga en la memoria que hacen que kswapd necesite paginar todo el tiempo”.
Eso se responde más fácilmente usando ‘superior’ y cambiando al modo de clasificación de uso de memoria.
Solución 2:
Puede crear un script… pero también puede hacerlo a través de la parte superior
Corre arriba y luego presiona O seguido por pags después ingresar
Ahora todos los procesos están ordenados por uso de intercambio y puede ver cuáles lo están usando
Solución 3:
Si tiene Ubuntu 15.10 o superior, esto puede ser el resultado de un error, especialmente si su sistema es una máquina virtual que carece de una partición de intercambio (por ejemplo, AWS EC2). El problema existe en otras distribuciones, pero, al momento de escribir, no está claro si la misma solución funciona universalmente.
Una solución temporal:
sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot
Tenga en cuenta que esto deshabilitará la adición en caliente de RAM/CPU para máquinas virtuales Xen e Hyper-V.
Solución 4:
También parece haber un error en kswapd en algún lugar, con suerte solo en kernels más antiguos.
Casi todos los días, kswapd se vuelve loco al azar en algunas máquinas en un clúster más grande (sin embargo, con un kernel no actual). CPU al 100 % en ambos procesos kswapd. No hay otros procesos en ejecución (excepto ssh shell), mucha RAM libre (más de 700 MB) y no se usa SWAP en absoluto. No swapin, no swapout también.
Nada explica todavía, por qué una máquina en particular es golpeada y otra no. Parece que no es completamente aleatorio, ya que generalmente afecta a más de una máquina en un período de tiempo corto. Parece que las máquinas, que están inactivas, así como las máquinas que están bajo alta presión, tienen menos (!) probabilidades de ser afectadas por el efecto. Por lo tanto, tiene que hacer algo con la carga de trabajo y solo funciona si la máquina no está inactiva ni muy ocupada.
Si el problema surge, ya nada ayuda. Matar todos los procesos (que no se volvieron imposibles de matar), desmontar todos los sistemas de archivos, nada. kswapd todavía se mantiene al 100% de la CPU. Sospecho que hay una carrera de spinlock en los núcleos SMP, pero también es probable que me equivoque.
Quizás vea mi respuesta serverfault.com/questions/316995/#493257
Notas:
- El reinicio de las máquinas afectadas a menudo falla porque el proceso de apagado comienza a colgarse en alguna parte.
- No hay conexión directa a Internet. Las causas externas son poco probables.
- Parece depender del tipo de carga de trabajo que procesan las máquinas desde la perspectiva de la carga, porque tenemos máquinas que nunca se vieron afectadas (todavía).
- Lo siento, no puedo ser más específico sobre lo que hacemos y por qué.
- Sí, estoy especulando. Porque es un efecto extremadamente desconcertante, hoy.
valoraciones y reseñas
Recuerda que puedes optar por la opción de decir si te fue útil.