Añadir DS a RRD – Problema PNP4Nagios – No DS called …

Me he encontrado varias veces problemas con los ficheros rrd que usa pnp para graficar en Nagios.
Indicando que faltan uno o varios (DS)-DataSource… esto sucede normalmente, porque se ha cambiado el plugin de un servicio y el nuevo plugin genera una salida diferente, lo cual genera un nuevo XML, pero el RRD que teníamos sigue con la definición anterior y faltan los (DS) indicados.

NOTA:
Para cada servicio, tenemos dos ficheros….
XML –> Estructura de BBDD rrd.
RRD –> BBDD

Como proceder… tenemos dos alternativas….

1.- Mas rápida… pero con perdida de histórico del servicio.

Borramos el rrd y el xml, y en el siguiente check se generaran de nuevo, pero habremos perdido el histórico para ese servicio.

2.- Creamos los DS que faltan.

De este modo mantendremos el historico del servicio para el resto de DS’s

NOTA: El script usado “rrd_add_datasource.pl” se puede descargar o copiarlo directamente.-
– Caso Practico –

1.- Verificar los DS que tenemos en el XML:

#cat /var/lib/pnp4nagios/XXXXXXX/DISK-linux.xml |grep "<DS>"
 <DS>1</DS>
 <DS>2</DS>
 <DS>3</DS>
 <DS>4</DS>
 <DS>5</DS>

2.- Verificar los DS que tenemos en el rrd:

#rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
 ds[1].type = "GAUGE"
 ds[2].type = "GAUGE"
 ds[3].type = "GAUGE"

3.- Debemos añadir el DS 4 y 5

# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 4 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.
# /root/rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE
Processing /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd... ok.

4.- Verificamos que el RRD ya tiene los DS correctos

[root@s2-argos ~]# rrdtool info /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd |grep type
ds[1].type = "GAUGE"
ds[2].type = "GAUGE"
ds[3].type = "GAUGE"
ds[4].type = "GAUGE"
ds[5].type = "GAUGE"

Tras esto el mapa se mostrara correctamente.
– Script “rrd_add_datasource.pl” –

#!/usr/bin/perl

use strict;
use warnings;
use RRD::Simple();

my $rrd_file = shift @ARGV;
my $DS_name = shift @ARGV;
my $DS_type = shift @ARGV;

my $rrd = RRD::Simple->new();

print "Processing $rrd_file...";
$rrd->add_source($rrd_file, $DS_name => $DS_type);
print " ok.\n";

e.j.

./rrd_add_datasource.pl $RRD_FILE $DS_NAME $TYPE
./rrd_add_datasource.pl /var/lib/pnp4nagios/XXXXXXX/DISK-linux.rrd 5 GAUGE
Publicado en Nagios | Deja un comentario

Configurando VLAN tagging sobre Bond

No hace mucho, he tenido que configurar un bond con tagging y he tenido algunos problemas que me parece buena idea, dejar por escrito.

La configuración de una interfaz “tagueada” con el id de una VLAN, no tiene más complicación. Existe mucha documentación al respecto.

Defines tu fichero de interfaz ifcfg-eth0 y su copia “link” con un “.” seguido del vlan_id…. ifcfg-eth0.10 (En este fichero, se define la configuración de red y se añade la clausula “VLAN=yes”)

Hasta aquí, todo según la documentación….

Al combinar, bond y tagging, es cuando he tenido estos problemas principalmente:

 

1.- Para vlans, necesitamos el modulo 8021q, el cual no carga por defecto, por lo que creamos un fichero /etc/modules-load.conf/8021q.conf

8021q

2.- Según la documentación consultada, desde la versión 6.3 de CentOS, existen problemas con bonding+tagging y NetworkManager. En los “bug reports” se recomienda que se pare NetWorkManager.

Estas pruebas se han realizado con CentOS 7.2 y tenia el mismo problema.

3.- Al parar NetworkManager, el modulo de bond no se carga al arranque. Para esto, tenemos dos alternativas:

3a.- Definir la carga del modulo creando un fichero en /etc/modprob.d/bond.conf

alias bond0 bonding
options bond0 miimon=100 mode=0

El detalle de los modos disponibles, lo tenéis aqui

3b.- Definir en el fichero de configuración del bond, la opción BONDING_OPTS:

BONDING_OPTS="mode=balance-rr miimon=100"

Esto hace que el modulo se cargado al arranque

Tras esto, la configuración siguiente funciona sin problemas:

 

ifcfg-eno1

TYPE="Ethernet" 
BOOTPROTO="none" 
NAME="eno1" 
DEVICE="eno1" 
ONBOOT="yes" 
NM_CONTROLLED="no" 
MASTER="bond0" 
SLAVE="yes"

ifcfg-eno2

TYPE="Ethernet" 
BOOTPROTO="none" 
NAME="eno2" 
DEVICE="eno2" 
ONBOOT="yes" 
NM_CONTROLLED="no" 
MASTER=bond0 
SLAVE=yes

ifcfg-bond0

TYPE="Bond" 
BOOTPROTO="none" 
DEVICE="bond0" 
NAME="bond0" 
ONBOOT="yes" 
BONDING_OPTS="mode=balance-rr miimon=100" 
NM_CONTROLLED="no"

ifcfg-bond0.10

BOOTPROTO="none" 
DEFROUTE="yes" 
NAME="bond0.10" 
DEVICE="bond0.10" 
NM_CONTROLLED="no" 
ONBOOT="yes" 
IPADDR="192.168.1.23" 
PREFIX="24" 
GATEWAY="192.168.1.1"
DNS1="8.8.8.8"
DNS2="8.8.4.4"
BONDING_MASTER=yes 
VLAN="yes"

 

Con esto tendremos nuestro bond “tagueado” con el id de la vlan, como vemos a continuación.

# ip -d link show bond0.10
7: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff promiscuity 0 
    vlan protocol 802.1Q id 10 <REORDER_HDR> addrgenmode eui64

 

[root@papaya network-scripts]# ip a l 
1: lo: ...
2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
3: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
4: ...
5: ...
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever 
7: bond0.10@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 
    inet 192.168.1.23/24 brd 192.168.1.255 scope global bond0.10 
       valid_lft forever preferred_lft forever 
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

 

Publicado en Bond, Linux | Deja un comentario

Networking con Docker – docker0 bridge…. Y si coincide

He estado realizando unas pruebas con docker y me he encontrado con lo siguiente..

La red que usa docker como bridge 172.17.0.0 /16 coincide con la red del segmento en el que se aloja la máquina de pruebas. Por lo que al arrancar el demonio de docker la interfazdocker0, dejaba la máquina no accesible.

Leyendo un poco, hay varias formas de abordar esto…. podemos pasarle a docker, parámetros para indicarle que red bridge debe usar, por lo que nuestra interfaz docker0, sera creada en dicho segmento.

Sin embargo, me parece más sencillo, el segundo mecanismo que viene a indicar, que si tenemos una interfaz docker0 en la máquina anfitrión, al arrancar docker, usará esta interfaz para la red bridge. De este modo no hay que indicarle nada en el arranque a docker.

1.- Desde consola.

Si hemos arrancado docker, aunque paremos el servicio, ya tendremos la interfaz docker0, tumbamos la interfaz:

systemctl stop docker.service
ip link set dev docker0 down

Modificamos la red.

ip addr add 172.19.0.0/16 dev docker0
ip link set dev docker0 up

Con esto al arrancar docker, este usara la nueva interfaz docker0 en la red 172.19.0.0

2.- Mismo concepto pero desde fichero.

(Centos7) Creamos el fichero para la interfaz docker0:

/etc/sysconfig/network-scripts/ifcfg-docker0

DEVICE=docker0
TYPE=Bridge
IPADDR=172.19.0.1
NETMASK=255.255.0.0
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

De este modo dejaremos el cambio persistente.

Publicado en Docker, Virtualización | Deja un comentario

Notas sobre DM-Multipath.

Hace un par de días, tras unos problemas con algún sistema que otro, un compañero me hizo llegar una nota de oracle sobre multipath, que me parece de lo más claro que he leído sobre  esto, en bastante tiempo.

Oracle Doc ID: 470913.1

Como tengo una memoria “privilegiada”…. prefiero apuntar estas notas sueltas, que en conjunto, parece que hasta tienen sentido.

 

Device-Mapper Multipath (DM-Multipath)

Es una herramienta nativa en linux la cual permite configurar múltiples caminos entre un host y un array de almacenamiento, como si de uno solo se tratara.

Supongamos que vemos la cabina de discos por 4 caminos desde nuestra máquina….
Al ofrecer un disco a la máquina, esta vería 4 discos o cuatro caminos a un disco:

/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf

Multipath realiza la ‘agregación’ o ‘mapeo’, para que podamos trabajar con un dispositivo único (Aunque le da 3 nombres):

"/dev/dm-0" o "/dev/mpath/mpath0" o "/dev/mapper/mpath0"

 

Según la documentación consultada funciona como una tabla de ‘mapeos’:

‘1’ Mapped device <–> Mapping Table <–> ‘N’ Target device

 

Como hemos comentado, para cada agregación de caminos, se crean 3 dispositivos (nombre de dispositivo), y aquí viene el problema…..

Cual uso, para que y porque.

1.- /dev/dm-X
Este dispositivo es para uso interno de DM-Multipath
NUNCA se debe usar este dispositivo.

2.- /dev/mpath/mpathX
Alias en formato “humano”. Se usa para tener agrupados los discos en un mismo directorio “/dev/mpath/”
NUNCA se debe usar este dispositivo, ya que en el arranque UDEV, puede no ser capaz de crear los dispositivos, lo suficientemente rápido, por lo que no estarán disponibles para ser montados.

3.- /dev/mapper/mpathN
Este es el dispositivo que debemos usar ya que es persistente y se crean al arrancar usando el driver device-mapper.
Podemos usar este driver para crear dispositivos lógicos usando “dmsetup”

Nota: Indicar que en distintas máquinas el nombre recibido puede ser diferente, si se quiere garantizar el mismo nombre, deberemos usar UDEV/Multipath y su wwid, para fijarlo.

Por ejemplo:

Single Path:

Obtener UUID
------------------
#scsi_id -g -s /block/sdc
3600a0b8000132XXXXXXXXXXXXb625e

Luego en UDEV
------------------
Editamos:
'/etc/udev/rules.d/10-local.rules'

...
KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="3600a0b8000132XXXXXXXXXXXXb625e", NAME="sda%n"
...

Multipath

Obtener WWID
---------------
multipath -ll

...
mpath1 (360060480000XXXXXXXXXX23544343331)
...

Luego en "multipath.conf"
--------------------------
multipaths { 
...
...
	multipath { 
	wwid
        360060480000XXXXXXXXXX23544343331
        alias NOMBRE 
        } 
...
...

 

Nota2: Trabajando con dispositivos bajo UDEV, podemos obtener problemas de permisos, que no entraré a detallar, ya que no los he “sufrido”, simplemente citar que las definiciones de permisos, se realizan, en la creación del dispositivo, tal y como hemos visto antes, en su linea dentro de “rules.d”, añadiendo:

....., OWNER="Nombre_USUARIO", GROUP="Nombre_GRUPO", MODE="0660"

 

Creando particiones.

Una vez aclarado que debemos usar el dispositivo desde “/dev/mapper/…” y porque. Creamos la partición usando “fdisk

fdisk /dev/mapper/mpath0

Esto creará la entrada en la tabla de particiones, pero no en los dispositivos que forman la agrupación de discos.
Ni generará los ‘mapeos’ necesarios en “/dev”

Para registrar estos cambios y generar los ‘mapeos’, usamos kpartx que es parte de multipath-tools .

kpartx -a /dev/mapper/mpath0
partprobe

Esto nos creará el ‘mapeo’ en “/dev” para cada partición creada:

/dev/mapper/mpath0p1
/dev/mapper/mpath0p2
/dev/mapper/mpath0p3
...

A este dispositivo (/dev/mapper/mpath0p1), podemos darle formato como a cualquier partición.

 

Flags útiles:

Para ver las particiones de un device:

kpartx -l /dev/mapper/mpath0
mpath0p1 : 0 2295308 /dev/mapper/mpath0 61

Ver que información hay en la tabla de particiones para ser escrita con “kpartx -a

kpartx /dev/mapper/mpath0

 

Referencias del post:
Blogs:
http://www.celtha.es/blog/howto-configuracion-multipath/
http://clemente.pamplona.name/dba/manejo-de-asm-multipath-y-asmlib/

RedHat:

https://www.centos.org/docs/5/html/5.2/Virtualization/sect-Virtualization-Virtualized_block_devices-Configuring_persistent_storage_in_a_Red_Hat_Enterprise_Linux_5_environment.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/DM_Multipath/mpath_devices.html

https://access.redhat.com/documentation/es-ES/Red_Hat_Enterprise_Linux/6/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-6-DM_Multipath-es-ES.pdf

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/DM_Multipath/Red_Hat_Enterprise_Linux-7-DM_Multipath-en-US.pdf

Oracle:

Nota 394956.1
Nota 371814.1
Nota 456239.1

 

Dedicado a las dos ‘chicas’ de la casa, por aguantar mis horas de curro/hobby en casa.

Publicado en Linux, Multipath | Deja un comentario

Update Owncloud – Ventana mantenimiento.

Tras el último update con aptitude, al acceder vía web a mi owncloud, me he encontrado con un mensaje indicando que estaba en mantenimiento.
No es la primera vez que me sucede, aunque normalmente funciona correctamente, así que me dejaré este post…

Nota: El acceso desde la app de android era correcto.

Para solucionarlo he usado el comando:

cd /var/www/owncloud
sudo -u www-data php occ maintenance:mode --off

Aquí tenemos más comando útiles.

Tras esto, al acceder vía web, nos indica que tenemos disponible el update, y si lo lanzamos, actualiza la bbdd y funciona perfectamente.

Publicado en Owncloud | Deja un comentario

Tuning BD – Cálculo inicial.

En determinadas ocasiones he tenido que realizar un tunning, básico y rápido (seguro que también malo, pero…. ni soy dba ni lo pretendo)

Se que los cálculos genéricos no son el camino, pero aveces no hay mas remedio.

El siguiente script, pretende ofrecer algunos valores calculados sobre el HW de la maquina, y ofrecer algún posible calculo.

Básicamente se ha convertido en un compendio de formulas para tratar de ajustar el rendimiento.

Como curiosidad no esta mal.

NOTA: El script no era el fin, en si mismo…. son ordenes básicamente secuenciales….. 🙂

NOTA2: Esto empezó en un post anterior Aquí.

Publicado en MySql | Deja un comentario

Consumo de Memoria y Caches

Hace unos días he visto un caso curioso sobre un Centos7.

El caso es que la máquina tenia un consumo de memoria que rondaba el 95% y tras un análisis rápido, la memoria no aparecía como cacheada, por lo que suponía que estaba realmente siendo usada.

Lo siguiente fue, ver que proceso / procesos estaban haciendo uso de esta cantidad de memoria, y la sorpresa fue, que no me cuadraban los valores, “faltaban” más menos 7Gb de 8Gb…. ¿?

Tras revisar en detalle la salida de /proc/meminfo, observé esto:

...
Slab:            6903676 kB
...
SReclaimable:    6873888 kB

Aunque la máquina no tenia problemas de rendimiento, por motivos que vienen al caso, no podía llegar a estos umbrales aunque la memoria estuviera como “reclamable”….

Como evitar esto?

Hay muchos posts sobre esto, así que citaré alguno de los que consulté.

https://major.io/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/

http://www.blackmoreops.com/2014/10/28/delete-clean-cache-to-free-up-memory-on-your-slow-linux-server-vps/

Resumiendo….
Tenemos el fichero:

/proc/sys/vm/drop_caches

Que admite los siguientes valores:

0 » Cede el control al Kernel para que administre la memoria
1 » Libera pagecache
2 » Libera dentries y inodes
3 » Libera pagecache, dentries y inodes

Nota:

Pagecache: Paginación en memoria caché
Dentries: Directory entries, relación estructurada entre 
directorios y ficheros
Inodes: Índice de archivos utilizado por el sistema de 
ficheros dónde almacena los metadatos de cada archivo 
(tipo, propietario, permisos, fecha de creación....)

Esto se puede ejecutar manualmente o programar en el cron:

EJECUCIÓN MANUAL

#sync ; echo 0 > /proc/sys/vm/drop_caches
#sync ; echo 1 > /proc/sys/vm/drop_caches
#sync ; echo 2 > /proc/sys/vm/drop_caches
#sync ; echo 3 > /proc/sys/vm/drop_caches

CRON

00 04 * * * /bin/sync; /bin/echo 2 > /proc/sys/vm/drop_caches

 

También podemos configurar esto vía sysctl:

sysctl -a|grep -i cache

Podemos modificar, que  queremos vaciar como

vm.drop_caches = 0

 

NOTA
Además de esto, también existe el parametro:

vfs_cache_pressure

Este valor indica la prioridad con la que se reclamará la cache de de (inodos/dentry) frente a la de datos (pagecache).

Por defecto tiene un valor de “100”

  • Si se decrementa, se preferirá reclamar (pagecache).
  • Si se incrementa, se preferirá reclamar (inodos/dentry).
  • Un valor de “0” hará que nunca se reclame, por lo que acabaríamos provocando un out of memory.
Publicado en Linux | Deja un comentario

Raspberry + Telegram

telegram_rasp_1

Este post, solo pretende ser unas simples notas sobre la instalación y uso del cliente de Telegram.

Aplicación de mandar avisos al teléfono…. las 1000 y una Frikadas…. que cada uno decida las suyas.

Instalación

apt-get install libreadline-dev libconfig-dev libssl-dev lua5.2 liblua5.2-dev libevent-dev libjansson-dev libpython-dev make python2.7-dev libevent-dev libjansson-dev

cd /opt
git clone --recursive https://github.com/vysheng/tg.git && cd tg
./configure
make

En varios sites he visto que no usan el “recursive”, sin esta tendremos cabeceras no resueltas, cuando intentes compilar.

Arrancar el cliente.

Tras esto podemos arrancar la app (Hace uso de algun path relativo por lo que debes entrar en “/opt/tg” aunque la invoque con el path absoluto):

/opt/tg/bin/telegram-cli -k tg-server.pub -W

Nota: La primera vez te dara un codigo que deberas introducir en la app de tu teléfono.

Puedes revisar la lista de comando con “help”

 

Comandos interesantes.

Un par de comando que he usado:

contact_list (Lista tus contactos.)

NOTA: Con el cliente arrancado puedes tabular para completar, lo cual te permite completar, por ejemplo, el nombre de un contacto y darte cuenta que si tienes espacios para la app son “_” de modo que:

contacto con espacio es contacto_con_espacio y no "contacto con espacio"

 

Mandar msg y ficheros de texto.

Para mandar msg, basta con teclear con el cliente arrancado…

msg Contacto "Texto a enviar"

Si queremos mandar el contenido de un fichero de texto.

send_text Contacto /ruta/fichero

Nota: Para mandar un msg a alguien por primera vez es necesario crear el chat antes:

chat_add_user Nobre_Chat Contacto

Tras esto podemos mandar el msg con el comando “msg”

Hasta aqui el uso del cliente pero y en un script como…..

 

Envio del contenido de un fichero de Texto.

Este script “/usr/loca/tg_text.sh” recibe dos argumentos, arranca el cliente y manda el msg (Fichero de texto).

#!/bin/bash
destination=$1;
text=$2;
(sleep 10;echo "send_text $destination $text"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de “/opt/tg”)

/usr/local/tg_text.sh Usuario /usr/local/fich.txt

 

Envio de un msg.

Este script es idéntico al anterior pero cambiamos el comando send_text por msg.

#!/bin/bash
destination=$1;
message=$2;
(sleep 10;echo "msg $destination $message"; sleep 5; echo "safe_quit") | /opt/tg/bin/telegram-cli -k tg-server.pub -W

Invocamos con: (Recordar…. dentro de “/opt/tg”)

/usr/local/tg_msg.sh Usuario "Texto a enviar"

 

Aplicaciones…. lo dicho, muchas por ejemplo, parsear periódicamente webs de descargas y recibir las novedades en el movil…..

Lo próximo una cámara un sensor de movimiento y….. el gato como actor principal xDDD

 

Publicado en Bash, Raspberry pi | Deja un comentario

Notas OOM Killer – Out Of Memory

Introducción.

Habitualmente los procesos solicitan una reserva de memoria superior a lo que necesitan usar, debido a esto el kernel tiene la habilidad de hacer “over-commit” o lo que es lo mismo… asignar más memoria de la que tiene físicamente el sistema, considerando que normalmente los procesos no llegarán a usar esta.

Cuando los procesos si llegan a usar la memoria que han reservado, el kernel ha de comenzar a matar procesos para poder mantenerse operativo. Para recuperar la memoria necesaria el kernel usa “out-of-memory killer” o “OOM killer”.

Detección y Análisis.
Algunas veces hemos visto procesos que dejan de estar en ejecución o simplemente vemos los famosos mensajes por pantalla…. “…Out of memory…”

Podemos detectar si OOM esta entrando a matar procesos revisando el log del sistema..

grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 1324 (apache).

Si se revisa la memoria en este punto, es muy posible que no nos aporte nada, ya que OOM ya esta matando procesos para mantener la memoria que el kernel necesita, por lo que estos controles deberíamos hacerlos antes de que suceda el problema.

Dicho esto….
Podemos encontrarnos con el caso en que un sistema este matando procesos, teniendo memoria libre y sin estar usando swap…. ¿por qué?

La memoria del sistema se divide en “high memory” y “low memory”
En lineas generales tenemos distinto obgetos en cada zona…

High Memory:
-Código de procesos
-Datos de procesos

Low Memory:
-Buffers y Cache
-Kernel
-Procesos del kernel
-Tablas de asignación de memoria de cada proceso
….

El estado de la memoria es la suma de estas dos zonas.
Ya que es posible tener la “Low Memory” llena y la “High Memory” libre, podemos tener en la salida de “free -m” memoria libre y el OOM trabajando.

Para poder detallar esto tenemos:

free -lm
[root@test-sys1 ~]# free -lm
total used free shared buffers cached
Mem: 498 93 405 0 15 32
Low: 498 93 405
High: 0 0 0
-/+ buffers/cache: 44 453
Swap: 1023 0 1023

Configurando comportamiento.

Una vez determinado el porque entra en acción OOM Killer, podemos realizar varias acciones….

Por un lado podemos actuar en caliente sobre los procesos, para indicarle a OOM Killer que no intente matar un determinado proceso.

Esto se realiza mediante prioridades…

Kernel 2.6.29 o superior

Prioridades: -1000 (No se eliminará) a 1000 (próximo en ser eliminado)

Kernel inferior a 2.6.29

Prioridades: -17 (No se eliminará) a 15 (próximo en ser eliminado)

Para aplicarlas basta con:

echo “-999” > /proc/[PID]/oom_adj

El automatizarlo o no…. según necesidades.

Prevenir la entrada de OOM Killer.

Para prevenir este comportamiento podemos configurar el comportamiento del kernel en cuanto a overcommit.

Existen 3 valores para overcommit_memory.

0 – (Defecto) Comportamiento Heurístico. Realiza estimaciones, para asignar mas memoria de la disponible.

1 – Sin comportamiento Heurístico. Asignación de memoria física.

2 – En este caso deja de tener un comportamiento heuristico, cuando se supera el consumo de la swap + un porcentaje de memoria, indicado en “overcommit_ratio”, por lo que siempre tendremos un % de memoria no usada para el overcommit.

Una buena práctica sería, por ejemplo (En este ejemplo, el 20% de la memoria no se usaría en el overcommit):

vi /etc/sysctl.conf

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Luego ejecutamos “sysctl -p

Links relacionados.

http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

https://www.kernel.org/doc/gorman/html/understand/understand012.html

http://rm-rf.es/como-excluir-un-proceso-del-oom-killer

http://www.ecsl.cs.sunysb.edu/elibrary/linux/mm/mm.pdf

 

Publicado en Linux | Deja un comentario

Permitir Ficheros grandes – Upload Onwcloud

Hace poco me he montado un owncloud casero y me dió algunos problemas, a la hora de poder hacer upload de los ficheros con un tamaño grande, del orden de Gb.

Revisando información en castellano, no he encontrado referencias claras, por eso dejo aquí los cambios que he necesitado. Básicamente son 2…..

1.- Tamaño máximo de subida.

Estos parámetros se pueden cambiar en el php.ini de la maquina, pero no tendrán valor ya que son sobrescritos por el “.htaccess” del owncloud, por lo que se deben modificar en el directorio web del owncloud.

Ej. Para 2Gb

php_value upload_max_filesize 2G
php_value post_max_size 2G

 

2.- Tiempo máximo de ejecución. (Esta es la parte menos documentada.)

Además de esto, cuanto mayor es el fichero más tiempo de ejecución necesita el cgi para hacer el upload, por lo que debemos aumentar el tiempo de ejecución o obtendremos un Internal server error, ya que la subida se corta. Sigue subiendo pero ya no lo almacenamos en el fichero temporal, el cual deja de crecer llegado ese punto.

Esto se puede revisar viendo crecer el fichero en “/tmp” o donde se almacene.

Estos valor los he cambiado directamente en php.ini

Dejándolos en 1h (Por defecto los tenia en 60s):

max_execution_time = 3600
max_input_time = 3600

 

Con estos cambios tenemos la subida de ficheros grandes solucionada.

Además de esto, he cambiado la forma por defecto de loguear de ownclud.

En el fichero:

..../owncloud/config/config.php

Definimos:

  'log_type' => 'owncloud',
  'logfile' => '/var/log/owncloud.log',
  'loglevel' => '2',
  'logdateformat' => 'F d, Y H:i:s',

Nota: También se puede tirar contra syslog y por supuesto hay varios levels de logg, en la documentación esta indicado.

 

Publicado en Linux, Owncloud | Deja un comentario