Apagado disco USB – RaspBerry

Publicación original: 19.07.2014

Tengo una raspberry conectada 24/7, en la cual tengo conectado un disco usb que uso muy poco (motivo por el que nunca se me había planteado la necesidad de poder «apagarlo» automáticamente). Hasta ahora montaba y desmontaba el disco según necesidades.

Es posible que para un proyecto futuro, me interese tener el/los disco/s montados siempre y que el SO los apague según el tiempo de inactividad.
Un compañero me comento el uso y me he puesto a mirar HDPARM

Nota:

Simplemente a modo de recordatorio, buscando info sobre el tema he visto que podemos saber si ha existido actividad en el disco consultando el fichero:

/sys/block/sda/stat

Cuando se realizan operaciones sobre el disco el valor número cambia.

cat /sys/block/sda/stat | tr -dc "[:digit:]"

HDPARM

Con mi disco he tenido unos problemas, que detallare al final. Aunque el estado «unknown» que se ve a continuación, esta relacionado con mis problemas.

Ver el estado del disco:

root@RASP1:~# hdparm -C /dev/sda1
/dev/sda1:
drive state is: unknown
root@RASP1:~#

Si todo funciona correctamente el estado debe ser «active/idle, standby»….

Ver el tiempo tras el que pasaremos a inactividad «spin-down«

root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor se debe entender del siguiente modo:

• SI Permitimos el Spin-Down: Entre 1 y 127
• NO Permitimos el Spin-Down: Entre 128 y 254
• El valor de 255 : Desactiva la gestión de energía avanzada del disco duro.

Cuando permitimos el spin-down, el tiempo en segundos, se obtiene multiplicando por 5 el valor dado, así un valor de 120, serán 120*5 segundos….. 10 minutos

Estableciendo el valor:

Para esto editamos el fichero de configuración de hdparm:

/etc/hdparm.conf

Y al final añadimos: (Este punto no he conseguido que funcione con mi disco)

/dev/DISCO {
  spindown_time = Valor_deseado}

Tras esto es suficiente con dejar el demonio corriendo:

/etc/init.d/hdparm restart

NOTA: Problemas con mi disco

Las pruebas las estoy haciendo con un disco WD:

root@RASP1:~# hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD5000BEVT-11A03T0
Serial Number: WD-WX30A6957814
Firmware Revision: 01.01A01
...

En este disco no he podido definir el valor en el fichero de configuración, así como ver el estado del disco, ni forzar el «apagado» del disco

root@RASP1:~# hdparm -y /dev/sda
/dev/sda:
issuing standby command
HDIO_DRIVE_CMD(standby) failed: Invalid argument

Sin embargo el disco si para cuando establezco el valor via comando:

root@RASP1:~# hdparm -B 121 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x79 (121)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 121
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 121
root@RASP1:~#
root@RASP1:~#
root@RASP1:~# hdparm -B 120 /dev/sda
/dev/sda:
setting Advanced Power Management level to 0x78 (120)
HDIO_DRIVE_CMD failed: Invalid argument
APM_level = 120
root@RASP1:~# hdparm -B /dev/sda
/dev/sda:
APM_level = 120

Este valor esta en uso hasta que el disco se desconecta de la corriente. Por lo que no es un problema para mi no poder, establecerlo de manera permanente.

Procesos en segundo plano – SIGHUP, NOHUP

Publicación original: 14.07.2014

Me parece interesante a modo de «chuleta» y/o recordatorio comentar un poco este tema…
Lo quiero separar en dos partes una sobre los procesos en segundo plano y otra sobre la señal SIGHUP.

• Procesos en segundo plano

Los procesos en segundo plano son aquellos que pese a estar en ejecución no tenemos la posibilidad de interactuar con ellos.

La manera de lanzar procesos en segundo plano es añadiendo al final & , de este modo el proceso quedará en ejecución pero liberará la shell, para poder seguir trabajando.

gandalf ~ # find / -name hola &
[1] 19968
gandalf ~ # ps -ef|grep find
...
[1]+  Hecho                   find / -name hola

Para poder interactuar con estos procesos necesitamos traerlos a primer plano y para realizar esta gestión tenemos los comandos jobs, bg y fg

Un ejemplo…. Lanzamos dos procesos en segundo plano:

gandalf ~ # while true; do echo "ab" > /dev/null; done &
[1] 20265
gandalf ~ # while true; do echo "a" > /dev/null; done &
[2] 20266

Visualizamos los procesos en segundo plano así como su estado:

gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Traemos uno de los procesos a primer plano y lo detenemos con Ctrl+Z

gandalf ~ # fg %1while true; do
echo "ab" > /dev/null;
done
^Z
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done

Al listar los procesos en segundo plano tenemos uno detenido y uno en ejecución.

gandalf ~ # jobs
[1]+  Detenido                while true; do
echo "ab" > /dev/null;
done
[2]-  Ejecutando              while true; do
echo "a" > /dev/null;
done &

Volvemos a poner en ejecución en background el proceso que estaba detenido.

gandalf ~ # bg %1
[1]+ while true; do
echo "ab" > /dev/null;
done &
gandalf ~ # jobs
[1]-  Ejecutando              while true; do
echo "ab" > /dev/null;
done &
[2]+  Ejecutando              while true; do
echo "a" > /dev/null;
done &

También podemos matar un proceso en background determinado

kill %2

• SIGHUP / NOHUP

Cuando un proceso termina lanza una señal SIGHUP a los procesos que cuelgan de el, y estos reaccionan simplemente saliendo.
Esto es un problema cuando queremos dejar corriendo algún proceso en la shell en la que nos encontremos, ya que aun teniéndolos en background, al salir de la shell el proceso terminará.
Podemos evitar esto lanzado el proceso con NOHUP, lo cual hará que el proceso no «escuche» la señal SIGHUP de su proceso padre.
Para lanzar un proceso con NOHUP basta con (nohup «comando»), por ejemplo:

nohup ./script.sh arg1 arg2
nohup su - user -c "./script arg1 arg2"

Algo interesante, a tener en cuenta, es el tratamiento de la salida /entrada estandar, así como de la salida de error que hace nohup.

• Salida estandar –> Si no esta redirigida, se redirige a $HOME/nohup.out
• Entrada estandar –> SI no esta definida toma valor de «/dev/null»
• Salida de error –-> Si no está definida es redirigida a la salida estandar.

Cabio de Site y CMS..

Ha llegado el momento de realizar la migración que estaba preparando.
El blog estrena nueva cara y cambia de ubicación..

He migrado todo el contenido y las nuevas entradas serán publicadas en el nuevo site.

http://www.celtha.es/blog

A ver que tal la experiencia.

Tunning Postgres

Estos últimos días he necesitado hacerle algo de Tunning a un postgres, así que he ido ajustando los valores que comento... 

Este proceso como todos los de tunning que he visto, se trata de iterar las veces que consideremos oportuno hasta no obtener mejora y dejarlo en la 

iteración (n-1) donde obtuvimos la última mejora.

El proceso a iterar consta de 3 partes básicamente.. (Toma de datos | Configuración | Toma de datos y Análisis)

Ya sabemos todos, que lo primero es medir.... lo que no se puede medir no se puede mejorar. ( Lord Kelvin , aunque hay bastante discusión sobre esto.)

1.- Toma de datos Inicial.

Hay infinitas formas de hacer esto yo tome como referencia este pool de pruebas. (Crear una table, insertar 100000 registros, hacer la consulta completa y borrar la tabla)

\timing
create table test_tunning (id integer primary key);
insert into test_tunning values (generate_series(1,100000));
select count(*) from test_tunning;
drop table test_tunning;

P.ejemplo

postgres=# \timing

El despliegue de duración está activado.

postgres=# create table test_tunning (id integer primary key);

NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «test_tunning_pkey» para la tabla «test_tunning»

CREATE TABLE

Duración: 14,178 ms

postgres=# insert into test_tunning values (generate_series(1,100000));

INSERT 0 100000

Duración: 202,436 ms

postgres=# select count(*) from test_tunning;

 count  

--------

 100000

(1 fila)

Duración: 11,773 ms

postgres=# drop table test_tunning;

DROP TABLE

Duración: 9,565 ms

2.- Aplicando Tuning Inicial Configuración Postgres.

A). shared_buffers 

shared_buffers = 615MB 

(Del 10% al 25% (Para un servidor dedicado). Podemos comenzar con un valor cercano al 15% e ir subiéndolo) 

Al aplicar este valor cabe la posibilidad de tener que modificar dos valores del kernel, ya que si son demasiado bajos postgres no arrancara.

Para la modificación en "caliente"

sysctl -w kernel.shmall=1048576
sysctl -w kernel.shmmax=4294967296

Para dejar el cambio permanente, editamos "/etc/sysctl.conf"

kernel.shmall = 

kernel.shmmax = 

B). effective_cache_size  

effective_cache_size = 1800MB 

Este valor podemos calcularlos de dos modos, según la documentación que he podido encontrar. 

A.- Un calculo genérico es el 50% del total de la ram de la máquina. Funciona bien pero no es lo más preciso posible.

B.- Si queremos ajustar más deberíamos tomar un valor del calculo (Shared_buffers+Ram Cached)

C.) work_mem 

work_mem = 16MB 

Este valor, es el que define la memoria usada por cada usuario para realizar operaciones de ordenación en las consultas. Por defecto esta a 1MB, valor que en los sistemas actuales no tiene sentido. Pasamos a 16MB y ajustamos luego, para lo que será necesario estudiar las consultas con más detalle. He visto medida genéricas que llegan a valores máximos de (max_connections/2 )

D).  maintenance_work_mem

maintenance_work_mem=200MB

Una manera de calcular el valor inicial sería: 50Mb por cada 1Gb de Ram.

Esta es la memoria que usará para realizar las operaciones de mantenimiento. El impacto de este valor no es elevado en la mayoría de los sistemas que he podido ver.

E). checkpoint_segments

checkpoint_segments=64 

Si bajamos este valor se producirán mas checkpoints lo que ocasiona escrituras en disco.

Un valor elevado disminuye las IO a disco pero emperora el tiempode recuperación ante desastre, ya que hay mas ficheros WAL pendientes de ser escritos.

F). wal_buffers

wal_buffers=16MB

Una manera de calcular el valor inicial sería: +-3% shared_buffers

Tamaño del buffer antes de tener que ser escrito en un fichero wal
Este valor es el mismo que el de los ficheros Wal por lo que debe minimizar las IO.

G). bgwriter_delaybgwriter_delay=500ms

Para ajustar este valor solo cabe consultar carga IO.

Delay del proceso writer.

Mas tiempo --> Menor IO y mas riesgo de perdida de datos, ya que se escriben menos frecuentemente.

Menor tiempo --> Mas IO y menos riesgo de perdida de datos.

3.- Toma de datos Final (Análisis de resultados).

Se repite la toma de datos del paso anterior.

Yo personalmente he tomado muestreos 5 veces de cada ciclo (create,insert,select,drop) antes de los cambio y después. Tomando la media. 

Esto lo he repetido 2 veces. total 10 valores de cada ciclo, de los cuales me he quedado con los mejores de cada caso.

	CREATE	INSERT	SELECT	DROP
PRE-Tunning	9,159 ms	161,687 ms	11,365 ms	9,3816
POST-Tunning	7,498 ms	156,892 ms	10,892 ms	13.984 ms
Ganancia	18,1%	2,97%	3,36%	-29.8%

Nota

El -29.8% no se a que se debe actualmente, (Quizás un pico en el pc) ya que estos valores están sacados de una máquina creada en mi pc, para la redacción de este post.

En entornos reales he obtenido ganancias de este tipo:

CREATE	INSERT	SELECT	DROP
92%	17%	0,08%	22%

Tras esto como ya he comentado, deberíamos seguir ajustando hasta no obtener mejora.

Problemas con la resolución de pantalla. Intel HD 4600 + Ubuntu14

No hace mucho, cambié el operativo de casa y decidí probar las "bondades" de un sistema LTS, así que llegué a ubuntu 14.04.

Me he encontrado con un problema que me sorprende se de aún, pero parece, es bastante comentado.

En mi caso, Ubuntu 14.04 solo me ofrece una resolución máxima, de 1024x768 con una Intel HD4600 integrada en el i5-4670, sobre un LG E2250v. Esto es completamente inaceptable, más si vienes de 1920*1080.

He probado varias formas de solucionar el problema, al final esta funcionando a 1920*1080 del siguiente modo...

1.- Verifica si estos 3 comando solucionan tu problema.... sino ajusta los valores correctamente.

xrandr --newmode monitor_1920 148.800 1920 2008 2052 2185 1080 1084 1089 1135

xrandr --addmode VGA1 monitor_1920

xrandr --output VGA1 --mode monitor_1920

Donde los valores "148.800 1920 2008 2052 2185 1080 1084 1089 1135" se deben obtener con el comando "cvt" OJO!! ESTO A MI NO ME FUNCIONÓ

Podéis ver que la salida de cvt es distinta a los valores que he usado...

# cvt 1920 1080 60

# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz

Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync

De donde obtendríamos:

173.00  1920 2048 2248 2576  1080 1083 1088 1120

Los valores que he acabado usando, son de:

http://wiki.xbmc.org/?title=Xorg_Modelines

...

...

# 1920x1080p @ 60Hz (EIA/CEA-861B)

ModeLine "1920x1080" 148.800 1920 2008 2052 2185 1080 1084 1089 1135 +hsync +vsync #INTEL

...

...

2.- Automatiza..

Tras verificar que los 3 comando anteriores te funcionan. Simplemente se trata de crear un script que se ejecute al cargar el escritorio, para lo cual creamos dos ficheros con el siguiente contenido...

/etc/xdg/autostart/fix_resolution.desktop 

[Desktop Entry]

Name=fix resolution

Exec=/usr/local/bin/fix_resolution.sh

/usr/local/bin/fix_resolution.sh

#!/bin/sh

xrandr --newmode monitor_1920 148.800 1920 2008 2052 2185 1080 1084 1089 1135

xrandr --addmode VGA1 monitor_1920

xrandr --output VGA1 --mode monitor_1920

Le damos permisos de ejecución al ".sh"

Con esto en cada reinicio se nos aplicara la configuración manual que hemos hecho.

Seguro que hay formas mas limpias y elegantes, pero esta me ha funcionado perfectamente.