Re: oom-killer no funciona como debería. [SOLUCIONADO]

2017-04-18 Por tema luis gil 
El problema estaba en una excesiva fragmentación de la caché de RAM. Con
estos comandos, lanzados como root, solucionado:

sync && echo 3 > /proc/sys/vm/drop_caches

sync hace que se graben de la RAM a disco las operaciones pendientes de
escritura y el segundo realiza un borrado de la caché de RAM. Se vuelve a
rehacer al poco tiempo. No es un comando muy intrusivo. Puede provocar una
ralentización temporal del sistema pero se recupera enseguida.

Lo he puesto en la cron para que se ejecute una vez al día y ya lleva 7
días sin un sólo oom-killer y realizando la carga de datos sin problemas.

Gracias a todos.


El 11 de abril de 2017, 20:57, Santiago Vila  escribió:

> On Mon, Apr 10, 2017 at 11:31:59AM +0200, luis gil wrote:
>
> > ¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2?
>
> Lo que dije sobre 1:2 era solamente un ejemplo.
>
> Mientras las aplicaciones hagan overcommit, se debe poner swap para
> compensar.
>
> > Mi RAM es de 32 G. Me parece excesivo una swap de ese tamaño.
>
> Todo depende de las aplicaciones que estés usando. Si tus aplicaciones
> "piden" 64 GB de memoria pero solamente usan 32 GB "normalmente", más
> vale que tengas esos 32 GB adicionales en swap para el día en que
> realmente quieran usar la memoria que han pedido.
>
> > Según había leído por ahí en varios sitios (no he encontrado mucha
> > información sobre este tema), cuando pones el overcommit_memory a 2, se
> > fija un nivel de memoria RAM a partir del cual se empiezan a matar
> > procesos.
>
> No es exacto. Se fija un nivel de memoria comprometida *total* a
> partir del cual se empiezan a matar procesos.
>
> Si este nivel es inferior a la cantidad de swap más la cantidad de
> RAM, entonces los procesos morirán antes de que comprometas toda la
> memoria disponible (swap + RAM) lo cual es un desperdicio.
>
> Por este motivo el valor del porcentaje, para que tenga sentido,
> debería ser >= 100.
>
> Estamos hablando de la memoria "comprometida", esa que a menudo supera
> con creces la memoria realmente utilizada.
>
> > Este nivel se calcula realizando la siguiente operación Cantidad
> > SWAT + Cantidad RAM * ratio / 100. Poniendo el ratio a 75 el nivel se
> queda
> > un poco por debajo de la RAM, de esta forma se consigue que el sistema no
> > empiece a swapear.
>
> Tampoco es exacto. Para que el swap se utilice lo menos posible
> hay otro parámetro llamado swappiness.
>
> Lo que quieres no es que no utilice el swap, sino que los procesos no
> mueran por falta de memoria "total".
>
> > [...]
>
> De nada sirve monitorizar la memoria usada por Apache cada 5 minutos
> si un atacante externo puede lanzar en dos o tres minutos tantas
> peticiones http que el sistema se quede sin memoria entre una
> observación y la siguiente.
>
> En mi caso, empecé a interesarme por este tema el día que alguien
> lanzó 2000 peticiones http a páginas PHP inexistentes en menos de tres
> minutos a un servidor que tenía con Apache en modo prefork.
> El servidor hizo "cataplof".
>
> Debería ser imposible, por *diseño* (no solamente tomando mediciones
> experimentales y monitorizaciones varias), que la memoria necesaria
> pueda crecer indefinidamente porque así lo provoque algo externo.
>
> Por eso recomiendo PHP-FPM + nginx.
>
>
> Por cierto, el incidente de United Airlines de ayer me ha recordado
> esta analogía de Andries Brouwer sobre lo absurdo que es el OOM killer:
>
> https://lwn.net/Articles/104179/
>
> A veces la realidad supera la ficción.
>
>

Re: oom-killer no funciona como debería.

2017-04-11 Por tema Santiago Vila 
On Mon, Apr 10, 2017 at 11:31:59AM +0200, luis gil wrote:

> ¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2?

Lo que dije sobre 1:2 era solamente un ejemplo.

Mientras las aplicaciones hagan overcommit, se debe poner swap para compensar.

> Mi RAM es de 32 G. Me parece excesivo una swap de ese tamaño.

Todo depende de las aplicaciones que estés usando. Si tus aplicaciones
"piden" 64 GB de memoria pero solamente usan 32 GB "normalmente", más
vale que tengas esos 32 GB adicionales en swap para el día en que
realmente quieran usar la memoria que han pedido.

> Según había leído por ahí en varios sitios (no he encontrado mucha
> información sobre este tema), cuando pones el overcommit_memory a 2, se
> fija un nivel de memoria RAM a partir del cual se empiezan a matar
> procesos.

No es exacto. Se fija un nivel de memoria comprometida *total* a
partir del cual se empiezan a matar procesos.

Si este nivel es inferior a la cantidad de swap más la cantidad de
RAM, entonces los procesos morirán antes de que comprometas toda la
memoria disponible (swap + RAM) lo cual es un desperdicio.

Por este motivo el valor del porcentaje, para que tenga sentido,
debería ser >= 100.

Estamos hablando de la memoria "comprometida", esa que a menudo supera
con creces la memoria realmente utilizada.

> Este nivel se calcula realizando la siguiente operación Cantidad
> SWAT + Cantidad RAM * ratio / 100. Poniendo el ratio a 75 el nivel se queda
> un poco por debajo de la RAM, de esta forma se consigue que el sistema no
> empiece a swapear.

Tampoco es exacto. Para que el swap se utilice lo menos posible
hay otro parámetro llamado swappiness.

Lo que quieres no es que no utilice el swap, sino que los procesos no
mueran por falta de memoria "total".

> [...]

De nada sirve monitorizar la memoria usada por Apache cada 5 minutos
si un atacante externo puede lanzar en dos o tres minutos tantas
peticiones http que el sistema se quede sin memoria entre una
observación y la siguiente.

En mi caso, empecé a interesarme por este tema el día que alguien
lanzó 2000 peticiones http a páginas PHP inexistentes en menos de tres
minutos a un servidor que tenía con Apache en modo prefork.
El servidor hizo "cataplof".

Debería ser imposible, por *diseño* (no solamente tomando mediciones
experimentales y monitorizaciones varias), que la memoria necesaria
pueda crecer indefinidamente porque así lo provoque algo externo.

Por eso recomiendo PHP-FPM + nginx.


Por cierto, el incidente de United Airlines de ayer me ha recordado
esta analogía de Andries Brouwer sobre lo absurdo que es el OOM killer:

https://lwn.net/Articles/104179/

A veces la realidad supera la ficción.

Re: oom-killer no funciona como debería.

2017-04-10 Por tema Felix Perez 
El día 10 de abril de 2017, 6:31, luis gil  escribió:
> Hola Santiago. Lo primero gracias por responder. Antes de que respondieras,
> ya había cambiado el overcommit_memory a 2 con el ratio a 75. Te comento
> dentro de tu correo:
>
> El 8 de abril de 2017, 13:52, Santiago Vila  escribió:
>>
>> On Thu, Apr 06, 2017 at 11:49:18PM +0200, luis gil wrote:
>>
>> > ¿Alguien se ha visto en
>> > la necesidad de modificar este parámetro? ¿le ha funcionado?
>>
>> Sí y sí.
>>
>> Pero hay otras cosas interesantes que se pueden hacer además de poner
>> el parámetro ese a 2.
>>
>> - Asegúrate de que tienes suficiente swap. Por ejemplo, si tus
>> aplicaciones hacen overcommit en proporción de 1:2 (es decir, piden el
>> doble de la memoria que realmente necesitan), entonces lo lógico sería
>> tener una partición de swap del mismo tamaño que la RAM. De lo
>> contrario estás infrautilizando la RAM.
>
>
> ¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2? Mi
> RAM es de 32 G. Me parece excesivo una swap de ese tamaño.
>
>>
>>
>> - Si pones vm.overcommit_memory = 2, pon también vm.overcommit_ratio = 100
>> como mínimo. De lo contrario estás infrautilizando la RAM de nuevo.
>>
>
> Según había leído por ahí en varios sitios (no he encontrado mucha
> información sobre este tema), cuando pones el overcommit_memory a 2, se fija
> un nivel de memoria RAM a partir del cual se empiezan a matar procesos. Este
> nivel se calcula realizando la siguiente operación Cantidad SWAT + Cantidad
> RAM * ratio / 100. Poniendo el ratio a 75 el nivel se queda un poco por
> debajo de la RAM, de esta forma se consigue que el sistema no empiece a
> swapear. Al menos así lo he entendido yo en la documentación que he
> encontrado. Me puedo equivocar.
>
> Te paso el estado de la memoria justo antes de un oom-killer y justo
> después:
>
> lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e
> Committed_AS -e MemTotal -e SwapTotal -e SwapFree
> MemTotal:   33270104 kB
> MemFree:17961848 kB
> SwapTotal:   7079928 kB
> SwapFree:7072288 kB
> CommitLimit:32032504 kB
> Committed_AS:4819852 kB
> lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e
> Committed_AS -e MemTotal -e SwapTotal -e SwapFree
> MemTotal:   33270104 kB
> MemFree:21839200 kB
> SwapTotal:   7079928 kB
> SwapFree:7072288 kB
> CommitLimit:32032504 kB
> Committed_AS:3661152 kB
>
> En estos momentos el overcommit_memory estaba puesto a 0 (probé a ponerlo a
> 2 pero ocurría lo mismo así que lo dejé como estaba) y el ratio a 75. Se ve
> como el CommitLimit es 32032504, coincidiendo con la fórmula, aunque como el
> overcommit_memory está puesto a 0 no aplica, sólo lo hace si esta a
> 2.También se ve como la memoria libre sube de 17 a 21 G después del
> oom-killer. La swap ni la toca.
>
> Cuando ocurrió este oom-killer estaba ejecutando una sentencia LOAD DATA
> LOCAL INFILE de un fichero csv de 1,5 G a través de la aplicación php. Esta
> carga se viene haciendo todos los días desde hace varios años, aunque el
> fichero es un poco más grande cada día (quizás se ha alcanzado algún límite,
> aunque no sé cual). Al tercer o cuarto intento carga el fichero. Como se
> puede apreciar la memoria libre en el momento del oom-killer es de más de
> 17G. No tiene sentido. O estoy monitorizando mal la memoria o la gestión de
> memoria no funciona como yo me creo.
>
> También pensé que a lo mejor la memoria que se estaba llenando es la Low,
> pero este es su estado antes y después del mismo oom-killer:
>
> lacuqui@Homer3:~$ free -lm
>  total   used   free sharedbuffers cached
> Mem: 32490  14968  17521  0  2  12999
> Low:   620358261
> High:31870  14609  17260
> -/+ buffers/cache:   1966  30523
> Swap: 6913  7   6906
> lacuqui@Homer3:~$ free -lm
>  total   used   free sharedbuffers cached
> Mem: 32490  11172  21317  0  4  10414
> Low:   620357262
> High:31870  10814  21055
> -/+ buffers/cache:753  31736
> Swap: 6913  7   6906
>
> La memoria Low libre ronda los 260M. La tengo monitorizada cada 5 mn y nunca
> ha bajado de 190M.
>
>
>>
>> - Si estás usando Apache en modo fork, considera usar otros modos.
>> En particular debes asegurarte de que una avalancha de visitas
>> no pueda elevar la memoria usada por Apache sin ningún límite.
>> (Hay parámetros para esas cosas si los sabes buscar).
>
>
> La memoria que utiliza apache la monitorizo con el siguiente comando
>
> ps -C apache2 -o rss --no-headers | awk '{ sum += $1 } END { print sum/1024
> }'
>
> cada 5 mn. El número de usuarios lo tengo limitado a 150. Pocas veces llega
> a tantos usuarios y en esos casos la memoria que

Re: oom-killer no funciona como debería.

2017-04-10 Por tema luis gil 
Hola Santiago. Lo primero gracias por responder. Antes de que respondieras,
ya había cambiado el overcommit_memory a 2 con el ratio a 75. Te comento
dentro de tu correo:

El 8 de abril de 2017, 13:52, Santiago Vila  escribió:

> On Thu, Apr 06, 2017 at 11:49:18PM +0200, luis gil wrote:
>
> > ¿Alguien se ha visto en
> > la necesidad de modificar este parámetro? ¿le ha funcionado?
>
> Sí y sí.
>
> Pero hay otras cosas interesantes que se pueden hacer además de poner
> el parámetro ese a 2.
>
> - Asegúrate de que tienes suficiente swap. Por ejemplo, si tus
> aplicaciones hacen overcommit en proporción de 1:2 (es decir, piden el
> doble de la memoria que realmente necesitan), entonces lo lógico sería
> tener una partición de swap del mismo tamaño que la RAM. De lo
> contrario estás infrautilizando la RAM.
>

¿Como puedo saber si mis aplicaciones hacen overcommit en proporción 1:2?
Mi RAM es de 32 G. Me parece excesivo una swap de ese tamaño.


>
> - Si pones vm.overcommit_memory = 2, pon también vm.overcommit_ratio = 100
> como mínimo. De lo contrario estás infrautilizando la RAM de nuevo.
>
>
Según había leído por ahí en varios sitios (no he encontrado mucha
información sobre este tema), cuando pones el overcommit_memory a 2, se
fija un nivel de memoria RAM a partir del cual se empiezan a matar
procesos. Este nivel se calcula realizando la siguiente operación Cantidad
SWAT + Cantidad RAM * ratio / 100. Poniendo el ratio a 75 el nivel se queda
un poco por debajo de la RAM, de esta forma se consigue que el sistema no
empiece a swapear. Al menos así lo he entendido yo en la documentación que
he encontrado. Me puedo equivocar.

Te paso el estado de la memoria justo antes de un oom-killer y justo
después:

lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e
Committed_AS -e MemTotal -e SwapTotal -e SwapFree
MemTotal:   33270104 kB
MemFree:17961848 kB
SwapTotal:   7079928 kB
SwapFree:7072288 kB
CommitLimit:32032504 kB
Committed_AS:4819852 kB
lacuqui@Homer3:~$ cat /proc/meminfo  | grep -e MemFree -e CommitLimit -e
Committed_AS -e MemTotal -e SwapTotal -e SwapFree
MemTotal:   33270104 kB
MemFree:21839200 kB
SwapTotal:   7079928 kB
SwapFree:7072288 kB
CommitLimit:32032504 kB
Committed_AS:3661152 kB

En estos momentos el overcommit_memory estaba puesto a 0 (probé a ponerlo a
2 pero ocurría lo mismo así que lo dejé como estaba) y el ratio a 75. Se ve
como el CommitLimit es 32032504, coincidiendo con la fórmula, aunque como
el  overcommit_memory está puesto a 0 no aplica, sólo lo hace si esta a
2.También se ve como la memoria libre sube de 17 a 21 G después del
oom-killer. La swap ni la toca.

Cuando ocurrió este oom-killer estaba ejecutando una sentencia LOAD DATA
LOCAL INFILE de un fichero csv de 1,5 G a través de la aplicación php. Esta
carga se viene haciendo todos los días desde hace varios años, aunque el
fichero es un poco más grande cada día (quizás se ha alcanzado algún
límite, aunque no sé cual). Al tercer o cuarto intento carga el fichero.
Como se puede apreciar la memoria libre en el momento del oom-killer es de
más de 17G. No tiene sentido. O estoy monitorizando mal la memoria o la
gestión de memoria no funciona como yo me creo.

También pensé que a lo mejor la memoria que se estaba llenando es la Low,
pero este es su estado antes y después del mismo oom-killer:

lacuqui@Homer3:~$ free -lm
 total   used   free sharedbuffers cached
Mem: 32490  14968  17521  0  2  12999
Low:   620358261
High:31870  14609  17260
-/+ buffers/cache:   1966  30523
Swap: 6913  7   6906
lacuqui@Homer3:~$ free -lm
 total   used   free sharedbuffers cached
Mem: 32490  11172  21317  0  4  10414
Low:   620357262
High:31870  10814  21055
-/+ buffers/cache:753  31736
Swap: 6913  7   6906

La memoria Low libre ronda los 260M. La tengo monitorizada cada 5 mn y
nunca ha bajado de 190M.



> - Si estás usando Apache en modo fork, considera usar otros modos.
> En particular debes asegurarte de que una avalancha de visitas
> no pueda elevar la memoria usada por Apache sin ningún límite.
> (Hay parámetros para esas cosas si los sabes buscar).
>

La memoria que utiliza apache la monitorizo con el siguiente comando

ps -C apache2 -o rss --no-headers | awk '{ sum += $1 } END { print sum/1024
}'

cada 5 mn. El número de usuarios lo tengo limitado a 150. Pocas veces llega
a tantos usuarios y en esos casos la memoria que ocupa apache es de 1,3 G
en total. Entiendo que esto incluye la memoria que está ocupando php 


>
> - Si no estás usando PHP-FPM como forma de que funcione PHP, considera
> usarlo en lugar de lo que estés usando. Esto ayuda muchísimo a que la
> cantidad de

Re: oom-killer no funciona como debería.

2017-04-08 Por tema Santiago Vila 
On Thu, Apr 06, 2017 at 11:49:18PM +0200, luis gil wrote:

> ¿Alguien se ha visto en
> la necesidad de modificar este parámetro? ¿le ha funcionado?

Sí y sí.

Pero hay otras cosas interesantes que se pueden hacer además de poner
el parámetro ese a 2.

- Asegúrate de que tienes suficiente swap. Por ejemplo, si tus
aplicaciones hacen overcommit en proporción de 1:2 (es decir, piden el
doble de la memoria que realmente necesitan), entonces lo lógico sería
tener una partición de swap del mismo tamaño que la RAM. De lo
contrario estás infrautilizando la RAM.

- Si pones vm.overcommit_memory = 2, pon también vm.overcommit_ratio = 100
como mínimo. De lo contrario estás infrautilizando la RAM de nuevo.

- Si estás usando Apache en modo fork, considera usar otros modos.
En particular debes asegurarte de que una avalancha de visitas
no pueda elevar la memoria usada por Apache sin ningún límite.
(Hay parámetros para esas cosas si los sabes buscar).

- Si no estás usando PHP-FPM como forma de que funcione PHP, considera
usarlo en lugar de lo que estés usando. Esto ayuda muchísimo a que la
cantidad de RAM en uso se mantenga dentro de unos límites.

- Una vez que estés usando PHP-FPM, si lo único que necesitas de
Apache es que sirva ficheros y funcione PHP, considera además usar
nginx en lugar de Apache, suele gastar menos memoria.

Re: oom-killer no funciona como debería.

2017-04-06 Por tema claudio menet 
Hola! Nunca me paso algo parecido pero también estuve investigando y lo que
pude encontrar es similar a lo que comentas. Aparentemente es algo bastante
común y sucede cuando los parámetros relacionados a la configuración de
memoria de mysql están configurados de tal manera que mysql aloca más
memoria de la que físicamente el kernel mediante el oom-killer está
dispuesta a permitirle utilizar. Mientras mysql no utilice físicamente la
memoria alocada el oom-killer no actúa pero cuando mysql pasa a utilizar la
memoria alocada superando el umbral definido para el oom-killer
automáticamente se convierte en candidato para ser matado.

Yo investigaría más por el lado de los parámetros de configuración de
memoria en mysql.

Te dejo un link que me pareció muy interesante donde el dueño del artículo
hace un ejemplo alocando memoria en dos procesos con un programa sencillo y
muestra como oom-killer decide que proceso matar.

https://www.psce.com/blog/2012/05/31/mysql-oom-killer-and-everything-related/

Espero te sea de utilidad.

Saludos!

El 6 de abril de 2017, 18:49, luis gil  escribió:

> Hola otra vez. He estado investigando y según parece el problema que tengo
> es con el overcommit, es decir reservar más memoria para los procesos que
> la que realmente existe físicamente. Se basa en que los procesos suelen
> reservar más memoria de la que realmente hacen uso posteriormente. El
> overcommit permite aprovechar mejor la memoria. El problema surge cuando
> los procesos efectivamente utilizan la memoria que han reservado y superan
> la memoria física existente. En ese caso el sistema llama a oom-killer para
> liberar memoria.
>
> Por lo que he entendido de la información que he encontrado, el overcommit
> tiene 3 modos de funcionamiento: 0, 1 y 2. Por defecto, y el que tengo yo
> configurado, es el 0. Este modo utiliza un algoritmo heurístico para
> determinar cuando hay que lanzar el oom-killer y según parece en mi sistema
> lo está lanzando antes de tiempo, ya que lo lanza cuando hay en torno a 20
> G libres de memoria de 32 G del total. El modo 1 elimina el overcommit, lo
> que puede provocar un kernel panic y el consiguiente bloqueo del sistema.
> El modo 2 no utiliza un algoritmo heurístico, sino que llama al oom-killer
> cuando el uso de la RAM llega a un nivel determinado. O así lo he entendido
> yo de la información que he encontrado. Mi intención es configurar el
> overcommit a 2 y forzar así el uso de más memoria. ¿Alguien se ha visto en
> la necesidad de modificar este parámetro? ¿le ha funcionado?
>
> Un saludo y gracias.
>
>
> El 3 de abril de 2017, 11:09, luis gil 
> escribió:
>
>> Gracias Oswaldo.
>>
>> He estado mirando la configuración de Apache y he encontrado alguna cosa
>> mejorable.
>>
>> De todas maneras aunque Apache estuviera mal configurado y utilizase más
>> memoria de la que debería entiendo que la debería de ver reflejada en la
>> memoria libre.
>>
>> Ahora se acaba de reiniciar mysql otra vez. Cuando lo ha hecho se estaba
>> subiendo un fichero al mysql desde un formulario de la web y cargándolo en
>> una tabla de mysql. El fichero ocupa 1,15 G. En el primer correo no
>> disponía de la salida de vmstat para pegarlo, pero ahora sí, ejecutándose
>> cada 3 sg sale lo siguiente:
>>
>> procs ---memory-- ---swap-- -io -system--
>> cpu
>>
>>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy
>> id wa
>>
>>  3  1   9852 15138904   5320 1313599200   239 18743 3750 4352 11
>> 0 88  1
>>
>>  4  0   9852 15113336   5404 131622600087  7967 3130 3862 13
>> 0 86  1
>>
>>  4  0   9852 15072972   5688 1319556400   532  9706 3708 3503 15
>> 1 84  1
>>
>>  3  0   9852 15040076   5760 132253280080 12579 4180 4988 11
>> 0 88  1
>>
>>  5  0   9852 15017408   5800 132532120031 12678 4164 4459 19
>> 1 80  0
>>
>>  3  1   9852 14992168   5924 132835800080 13179 5154 6640  9
>> 0 90  1
>>
>>  2  5   9852 15087296   3428 1320419600  2879 18701 6007 5518 15
>> 1 76  9
>>
>>  3  2   9852 15046564   3888 1323696400   877  6705 4403 5063 10
>> 0 85  4
>>
>>  3  1   9852 15039628   4012 1325217600  5681 17683 6337 8803 14
>> 1 77  8
>>
>>  3  0   9852 15007564   4272 1328240000   104  6932 3013 1758 14
>> 0 85  1
>>
>>  3  0   9852 14977520   5040 1331065200   603 13573 5566 4285  9
>> 0 89  1
>>
>>  4  0   9852 14951516   5132 133439600085  9594 5839 4115 16
>> 0 82  2
>>
>>  3  0   9852 14917308   5660 1337263200   601 15876 6305 4843 10
>> 0 84  5
>>
>>  3  4   9852 14990888   5420 1329673600  1036  5177 3061 2143 11
>> 0 80  9
>>
>>  5  0   9852 14974044   5568 1331659200   667 12701 4728 3052 14
>> 1 74 11
>>
>>  2  3   9852 14928648   1984 1334537200  1312 14722 5780 8408 10
>> 1 86  3
>>
>>  0  1   9852 19130736   4532 1334926800  2557  4197 3047 5435  3

Re: oom-killer no funciona como debería.

2017-04-06 Por tema luis gil 
Hola otra vez. He estado investigando y según parece el problema que tengo
es con el overcommit, es decir reservar más memoria para los procesos que
la que realmente existe físicamente. Se basa en que los procesos suelen
reservar más memoria de la que realmente hacen uso posteriormente. El
overcommit permite aprovechar mejor la memoria. El problema surge cuando
los procesos efectivamente utilizan la memoria que han reservado y superan
la memoria física existente. En ese caso el sistema llama a oom-killer para
liberar memoria.

Por lo que he entendido de la información que he encontrado, el overcommit
tiene 3 modos de funcionamiento: 0, 1 y 2. Por defecto, y el que tengo yo
configurado, es el 0. Este modo utiliza un algoritmo heurístico para
determinar cuando hay que lanzar el oom-killer y según parece en mi sistema
lo está lanzando antes de tiempo, ya que lo lanza cuando hay en torno a 20
G libres de memoria de 32 G del total. El modo 1 elimina el overcommit, lo
que puede provocar un kernel panic y el consiguiente bloqueo del sistema.
El modo 2 no utiliza un algoritmo heurístico, sino que llama al oom-killer
cuando el uso de la RAM llega a un nivel determinado. O así lo he entendido
yo de la información que he encontrado. Mi intención es configurar el
overcommit a 2 y forzar así el uso de más memoria. ¿Alguien se ha visto en
la necesidad de modificar este parámetro? ¿le ha funcionado?

Un saludo y gracias.

El 3 de abril de 2017, 11:09, luis gil  escribió:

> Gracias Oswaldo.
>
> He estado mirando la configuración de Apache y he encontrado alguna cosa
> mejorable.
>
> De todas maneras aunque Apache estuviera mal configurado y utilizase más
> memoria de la que debería entiendo que la debería de ver reflejada en la
> memoria libre.
>
> Ahora se acaba de reiniciar mysql otra vez. Cuando lo ha hecho se estaba
> subiendo un fichero al mysql desde un formulario de la web y cargándolo en
> una tabla de mysql. El fichero ocupa 1,15 G. En el primer correo no
> disponía de la salida de vmstat para pegarlo, pero ahora sí, ejecutándose
> cada 3 sg sale lo siguiente:
>
> procs ---memory-- ---swap-- -io -system--
> cpu
>
>  r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy
> id wa
>
>  3  1   9852 15138904   5320 1313599200   239 18743 3750 4352 11  0
> 88  1
>
>  4  0   9852 15113336   5404 131622600087  7967 3130 3862 13  0
> 86  1
>
>  4  0   9852 15072972   5688 1319556400   532  9706 3708 3503 15  1
> 84  1
>
>  3  0   9852 15040076   5760 132253280080 12579 4180 4988 11  0
> 88  1
>
>  5  0   9852 15017408   5800 132532120031 12678 4164 4459 19  1
> 80  0
>
>  3  1   9852 14992168   5924 132835800080 13179 5154 6640  9  0
> 90  1
>
>  2  5   9852 15087296   3428 1320419600  2879 18701 6007 5518 15  1
> 76  9
>
>  3  2   9852 15046564   3888 1323696400   877  6705 4403 5063 10  0
> 85  4
>
>  3  1   9852 15039628   4012 1325217600  5681 17683 6337 8803 14  1
> 77  8
>
>  3  0   9852 15007564   4272 1328240000   104  6932 3013 1758 14  0
> 85  1
>
>  3  0   9852 14977520   5040 1331065200   603 13573 5566 4285  9  0
> 89  1
>
>  4  0   9852 14951516   5132 133439600085  9594 5839 4115 16  0
> 82  2
>
>  3  0   9852 14917308   5660 1337263200   601 15876 6305 4843 10  0
> 84  5
>
>  3  4   9852 14990888   5420 1329673600  1036  5177 3061 2143 11  0
> 80  9
>
>  5  0   9852 14974044   5568 1331659200   667 12701 4728 3052 14  1
> 74 11
>
>  2  3   9852 14928648   1984 1334537200  1312 14722 5780 8408 10  1
> 86  3
>
>  0  1   9852 19130736   4532 1334926800  2557  4197 3047 5435  3  2
> 87  8
>
>  0  2   9852 19166220   6224 1331170800  1025   727 1657 2041  2  0
> 85 13
>
>  1  0   9852 19256336   6640 1322371600  1833   297 1265  649  1  0
> 96  4
>
>  0  2   9852 19245636   7940 1323008400  2737   116 1601 2039  0  0
> 97  3
>
>  0  1   9852 19240328   8804 1323239200   820   706 1426 7295  1  0
> 96  2
>
>  1  0   9852 19235716   9008 1323608400   649   205 1627 4513  1  0
> 98  1
>
>  0  0   9852 19236624   9044 132403240011  1421 2106 3454  0  0
> 99  0
>
>  0  0   9852 19239228   9112 132448560099   160 2115 2295  1  0
> 99  1
>
>  1  0   9852 19235060   9296 1325106800   276  2639 2586 4045  0  0
> 99  1
>
>  1  0   9852 19226752   9408 132608120040   157 3053 3948  1  0
> 99  0
>
>  1  0   9852 19212104   9744 1327114800   141  6591 3788 6791  1  0
> 98  0
>
>  0  0   9852 19203596   9820 132799080089  2537 2975 5262  1  0
> 99  0
>
>  1  0   9852 19192860   9876 1328982800   621  3435 2631 22059  1
> 0 98  1
>
>  0  0   9852 19186064  10148 1329956400   519  1393 3147 27693  2
> 1 96  2
>
>  2  0   9852 19178252  10244 133081760089  4543 2289

Re: oom-killer no funciona como debería.

2017-04-03 Por tema luis gil 
Gracias Oswaldo.

He estado mirando la configuración de Apache y he encontrado alguna cosa
mejorable.

De todas maneras aunque Apache estuviera mal configurado y utilizase más
memoria de la que debería entiendo que la debería de ver reflejada en la
memoria libre.

Ahora se acaba de reiniciar mysql otra vez. Cuando lo ha hecho se estaba
subiendo un fichero al mysql desde un formulario de la web y cargándolo en
una tabla de mysql. El fichero ocupa 1,15 G. En el primer correo no
disponía de la salida de vmstat para pegarlo, pero ahora sí, ejecutándose
cada 3 sg sale lo siguiente:

procs ---memory-- ---swap-- -io -system--
cpu

 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id
wa

 3  1   9852 15138904   5320 1313599200   239 18743 3750 4352 11  0
88  1

 4  0   9852 15113336   5404 131622600087  7967 3130 3862 13  0
86  1

 4  0   9852 15072972   5688 1319556400   532  9706 3708 3503 15  1
84  1

 3  0   9852 15040076   5760 132253280080 12579 4180 4988 11  0
88  1

 5  0   9852 15017408   5800 132532120031 12678 4164 4459 19  1
80  0

 3  1   9852 14992168   5924 132835800080 13179 5154 6640  9  0
90  1

 2  5   9852 15087296   3428 1320419600  2879 18701 6007 5518 15  1
76  9

 3  2   9852 15046564   3888 1323696400   877  6705 4403 5063 10  0
85  4

 3  1   9852 15039628   4012 1325217600  5681 17683 6337 8803 14  1
77  8

 3  0   9852 15007564   4272 1328240000   104  6932 3013 1758 14  0
85  1

 3  0   9852 14977520   5040 1331065200   603 13573 5566 4285  9  0
89  1

 4  0   9852 14951516   5132 133439600085  9594 5839 4115 16  0
82  2

 3  0   9852 14917308   5660 1337263200   601 15876 6305 4843 10  0
84  5

 3  4   9852 14990888   5420 1329673600  1036  5177 3061 2143 11  0
80  9

 5  0   9852 14974044   5568 1331659200   667 12701 4728 3052 14  1
74 11

 2  3   9852 14928648   1984 1334537200  1312 14722 5780 8408 10  1
86  3

 0  1   9852 19130736   4532 1334926800  2557  4197 3047 5435  3  2
87  8

 0  2   9852 19166220   6224 1331170800  1025   727 1657 2041  2  0
85 13

 1  0   9852 19256336   6640 1322371600  1833   297 1265  649  1  0
96  4

 0  2   9852 19245636   7940 1323008400  2737   116 1601 2039  0  0
97  3

 0  1   9852 19240328   8804 1323239200   820   706 1426 7295  1  0
96  2

 1  0   9852 19235716   9008 1323608400   649   205 1627 4513  1  0
98  1

 0  0   9852 19236624   9044 132403240011  1421 2106 3454  0  0
99  0

 0  0   9852 19239228   9112 132448560099   160 2115 2295  1  0
99  1

 1  0   9852 19235060   9296 1325106800   276  2639 2586 4045  0  0
99  1

 1  0   9852 19226752   9408 132608120040   157 3053 3948  1  0
99  0

 1  0   9852 19212104   9744 1327114800   141  6591 3788 6791  1  0
98  0

 0  0   9852 19203596   9820 132799080089  2537 2975 5262  1  0
99  0

 1  0   9852 19192860   9876 1328982800   621  3435 2631 22059  1  0
98  1

 0  0   9852 19186064  10148 1329956400   519  1393 3147 27693  2  1
96  2

 2  0   9852 19178252  10244 133081760089  4543 2289 2897  1  0
98  0

 1  0   9852 19162580  10876 1331766000   128  4468 3635 10674  1  1
98  0

 2  0   9852 19067216  11472 1333464000  2903  3317 5963 24712  3  2
91  3

A mitad de tabla se aprecia como la memoria libre pasa de unos 15G a poco
más de 19G. Ha sido el momento en que, según sale en syslog, apache ha
llamado al proceso oom-killer y ha tirado mysql. No entiendo porqué apache
considera que 15 G de memoria libre son pocos y es necesario hacer sitio.

Un saludo y gracias.

El 3 de abril de 2017, 1:06, Oswaldo Franco 
escribió:

> Hola Luis, revisa bien la configuración del apache. Sobre todo
> asignaciones de memoria RAM o algo así.
>
> Espero te ayude mi indicio.
>
> Saludos
>
> El 2 abr. 2017 13:12, "luis gil"  escribió:
>
>> Buenas tardes. Espero que me puedan ayudar. El caso es que tengo un
>> servidor con Debian 6. Está corriendo mysql 5.1 y apache 2 con una
>> aplicación en php. La máquina tiene 31 G de RAM y 24 procesadores con 6
>> cores cada uno. El SO es de 32 bits.
>>
>> De vez en cuando, varias veces al día, normalmente con consultas pesadas
>> a la base de datos, se reinicia el mysql con consecuencias desde
>> indetectables a desastrosas. Mirando el syslog me sale lo siguiente:
>>
>> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058476] apache2 invoked
>> oom-killer: gfp_mask=0x44d0, order=2, oom_adj=0
>> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058481] apache2 cpuset=/
>> mems_allowed=0
>> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058487] Pid: 10826, comm:
>> apache2 Tainted: GW  2.6.32-5-686-bigmem #1
>> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058491] Call Trace:
>>

Re: oom-killer no funciona como debería.

2017-04-02 Por tema Oswaldo Franco 
Hola Luis, revisa bien la configuración del apache. Sobre todo asignaciones
de memoria RAM o algo así.

Espero te ayude mi indicio.

Saludos

El 2 abr. 2017 13:12, "luis gil"  escribió:

> Buenas tardes. Espero que me puedan ayudar. El caso es que tengo un
> servidor con Debian 6. Está corriendo mysql 5.1 y apache 2 con una
> aplicación en php. La máquina tiene 31 G de RAM y 24 procesadores con 6
> cores cada uno. El SO es de 32 bits.
>
> De vez en cuando, varias veces al día, normalmente con consultas pesadas a
> la base de datos, se reinicia el mysql con consecuencias desde
> indetectables a desastrosas. Mirando el syslog me sale lo siguiente:
>
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058476] apache2 invoked
> oom-killer: gfp_mask=0x44d0, order=2, oom_adj=0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058481] apache2 cpuset=/
> mems_allowed=0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058487] Pid: 10826, comm:
> apache2 Tainted: GW  2.6.32-5-686-bigmem #1
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058491] Call Trace:
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058501]  [] ?
> oom_kill_process+0x60/0x201
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058508]  [] ?
> __out_of_memory+0xf4/0x107
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058514]  [] ?
> out_of_memory+0x5a/0x7c
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058519]  [] ?
> __alloc_pages_nodemask+0x3ef/0x4d9
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058526]  [] ?
> __get_free_pages+0xc/0x17
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058532]  [] ?
> __kmalloc_track_caller+0x34/0x124
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058540]  [] ?
> sock_alloc_send_pskb+0xaa/0x25f
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058544]  [] ?
> __alloc_skb+0x4a/0x115
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058550]  [] ?
> sock_alloc_send_pskb+0xaa/0x25f
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058558]  [] ?
> __wake_up_sync_key+0x33/0x49
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058565]  [] ?
> copy_from_user+0x27/0x10e
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058571]  [] ?
> sock_alloc_send_skb+0xc/0xf
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058578]  [] ?
> unix_stream_sendmsg+0x134/0x2c4
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058585]  [] ?
> __sock_sendmsg+0x43/0x4a
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058591]  [] ?
> sock_aio_write+0xa3/0xb0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058598]  [] ?
> do_sync_write+0xc0/0x107
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058605]  [] ?
> run_posix_cpu_timers+0x65f/0x67a
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058612]  [] ?
> autoremove_wake_function+0x0/0x2d
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058618]  [] ?
> fsnotify_access+0x5a/0x61
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058625]  [] ?
> security_file_permission+0xc/0xd
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058630]  [] ?
> vfs_write+0x8f/0xd6
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058635]  [] ?
> sys_write+0x3c/0x63
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058641]  [] ?
> sysenter_do_call+0x12/0x28
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058644] Mem-Info:
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058646] DMA per-cpu:
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058649] CPU0: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058652] CPU1: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058656] CPU2: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058659] CPU3: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058663] CPU4: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058666] CPU5: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058668] CPU6: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058671] CPU7: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058674] CPU8: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058677] CPU9: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058679] CPU   10: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058682] CPU   11: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058685] CPU   12: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058689] CPU   13: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058692] CPU   14: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058695] CPU   15: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058698] CPU   16: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058701] CPU   17: hi:0,
> btch:   1 usd:   0
> Mar 31 13:34:05 LaCuqui3 kernel:

oom-killer no funciona como debería.

2017-04-02 Por tema luis gil 
Buenas tardes. Espero que me puedan ayudar. El caso es que tengo un
servidor con Debian 6. Está corriendo mysql 5.1 y apache 2 con una
aplicación en php. La máquina tiene 31 G de RAM y 24 procesadores con 6
cores cada uno. El SO es de 32 bits.

De vez en cuando, varias veces al día, normalmente con consultas pesadas a
la base de datos, se reinicia el mysql con consecuencias desde
indetectables a desastrosas. Mirando el syslog me sale lo siguiente:

Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058476] apache2 invoked
oom-killer: gfp_mask=0x44d0, order=2, oom_adj=0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058481] apache2 cpuset=/
mems_allowed=0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058487] Pid: 10826, comm:
apache2 Tainted: GW  2.6.32-5-686-bigmem #1
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058491] Call Trace:
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058501]  [] ?
oom_kill_process+0x60/0x201
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058508]  [] ?
__out_of_memory+0xf4/0x107
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058514]  [] ?
out_of_memory+0x5a/0x7c
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058519]  [] ?
__alloc_pages_nodemask+0x3ef/0x4d9
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058526]  [] ?
__get_free_pages+0xc/0x17
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058532]  [] ?
__kmalloc_track_caller+0x34/0x124
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058540]  [] ?
sock_alloc_send_pskb+0xaa/0x25f
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058544]  [] ?
__alloc_skb+0x4a/0x115
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058550]  [] ?
sock_alloc_send_pskb+0xaa/0x25f
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058558]  [] ?
__wake_up_sync_key+0x33/0x49
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058565]  [] ?
copy_from_user+0x27/0x10e
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058571]  [] ?
sock_alloc_send_skb+0xc/0xf
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058578]  [] ?
unix_stream_sendmsg+0x134/0x2c4
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058585]  [] ?
__sock_sendmsg+0x43/0x4a
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058591]  [] ?
sock_aio_write+0xa3/0xb0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058598]  [] ?
do_sync_write+0xc0/0x107
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058605]  [] ?
run_posix_cpu_timers+0x65f/0x67a
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058612]  [] ?
autoremove_wake_function+0x0/0x2d
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058618]  [] ?
fsnotify_access+0x5a/0x61
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058625]  [] ?
security_file_permission+0xc/0xd
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058630]  [] ?
vfs_write+0x8f/0xd6
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058635]  [] ?
sys_write+0x3c/0x63
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058641]  [] ?
sysenter_do_call+0x12/0x28
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058644] Mem-Info:
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058646] DMA per-cpu:
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058649] CPU0: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058652] CPU1: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058656] CPU2: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058659] CPU3: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058663] CPU4: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058666] CPU5: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058668] CPU6: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058671] CPU7: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058674] CPU8: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058677] CPU9: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058679] CPU   10: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058682] CPU   11: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058685] CPU   12: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058689] CPU   13: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058692] CPU   14: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058695] CPU   15: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058698] CPU   16: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058701] CPU   17: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058704] CPU   18: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058708] CPU   19: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058711] CPU   20: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058714] CPU   21: hi:0,
btch:   1 usd:   0
Mar 31 13:34:05 LaCuqui3 kernel: [30300729.058717] CPU   22: hi:0,
btch:   1 usd:   0
Mar 31