Los servicios se detuvieron y es imposible reiniciarlos debido a falta de espacio en el disco duro. Al intentar ingresar a la interfaz grafica se muestra el siguiente error: "The appliance has shut down because available disk space is low".

English version of this KA 000094102.

El primer paso es determinar qué partición está llena. Esto se puede hacer ejecutando "df -h" desde la línea de comandos. Normalmente, / usr o la partición de datastore data está llena.

Es posible que la salida de 'df -h' no muestre ninguna partición al 100% de su capacidad, pero cualquiera que muestre el mayor porcentaje de uso es la que presenta el problema.
(Si se abriera un caso de Soporte es conveniente proporcionar los resultados de "df -h".)

Se puede utilizar el monitor de espacio libre en disco (free disk space monitor) para evitar problemas que pueden ocurrir si la partición del disco que contiene los archivos o los logs de transacciones de la base de datos (consultar https://docs.bmc.com/docs/display/disco113/Configuring+disk+space+monitor). Cuando se detecta una cantidad de espacio menor a la predefinida en el disco, el monitor detiene los servicios de Discovery de forma segura y / o evita que se inicie. Por defecto, la cantidad mínima de espacio permitido en el disco es de 1024 MB. 

Una práctica recomendada para evitar este problema es compactar la base de datos de forma regular https://docs.bmc.com/docs/discovery/113/tw_ds_offline_compact-788110380.html?src=search

Posibles causas raíz  de saturación de la partición de la base de datos (Datastore data):

- El tamaño de la base de datos es simplemente demasiado grande, en este caso, el dispositivo no ha sido dimensionado correctamente (consulte https://docs.bmc.com/docs/display/disco113/Sizing+guidelines)

- En versiones previas a 11.1 existe un defecto que puede aumentar el tamaño del almacén de datos. Si este fuera el caso se puede consultar el articulo 000123599 para verificar esta causa raíz y resolver el problema.

- Es posible que exista un problema con la eliminación de "doomed nodes" (consultar articulo 000093640). Es importante tener en cuenta que esta condición puede agravarse cuando la compactación no se ejecuta de forma regular. Para confirmar esta causa es necesario solucionar el problema de acumulación de doomed nodes (utilizando el articulo mencionado) y despues ejecutar una compactación y comparar las entradas en el archivo tw_appliance_df.log antes y después de la resolución del problema. Si la tasa de crecimiento del base de datos disminuye, esto significa que es necesaria una compactación regular para evitar este ciclo (almacén de datos grande => problema de rendimiento => acumulación de doomed nodes => almacén de datos grande => problema de rendimiento ...). 

- Otra posible causa puede ser la acumulación de relaciones en el historial de la base de datos. El defecto DRUD1-16602 soluciona este problema en las versiones 11.1, 11.0.0.3, 10.2.0.6 y 10.1.0.5 de Discovery. Si no es posible realizar la actualización de inmediato, la solución es agregar a la consola un disco nuevo y con suficiente espacio para mover la base de datos al mismo. Para obtener más información, consultar el articulo 000082640.

Posibles causas raíz de saturación del directorio de logs de la base de datos (db logs):

- Si recientemente se redujo drasticamente el valor de tiempo  "Time before history entries are purged" en Administration>Model Maintenance (por ejemplo, de "Never" a "30 days"). Es posible que esto haya provocado que una gran cantidad de nodos del historial sean eliminados de repente, lo que a su vez provoca un aumento en el tamaño de los los logs de la base de datos. Para solucionar esto es necesario contactar a soporte de BMC con la recomendación de hacer referencia al articulo interno 000164304.

- En teoría, un problema de rendimiento podría afectar negativamente a la base de datos. Este caso se presentaria si la lentitud del sistema evita que se procesen las transacciones pendientes en la partición de los logs de la base de datos, lo cual generaria una saturación de esta partición. Este vínculo causa-efecto no se ha confirmado hasta ahora pero es una posible causa raíz.

Posibles causas raíz de una saturación de la prtición  / usr:

- El directorio / usr / tideway / cores contiene archivos de gran tamaño. En este caso es necesario seguir los pasos  documentados en el articulo 000028149 y posteriormente el contenido puede ser borrado conservando la carpeta en sí.

- El directorio / usr / tideway / log está lleno de archivos de logs que contienen información de nivel de depuración (debug). Los archivos más grandes se pueden comprimir para liberar espacio. Es recomendable de que el nivel de "debug" solo se utilize cuando sea necesario.

- Existen demasiados archivos o archivos demasiado grandes de transacciones en el directorio / usr / tideway / var / persist / reasoning / engine / queue. Es normal que estos archivos se presenten durante el tiempo que los escaneos están en espera pero deberian procesarse y eliminarse cuando se reinicia el escaneo. La eliminación manual de estos archivos solo debe hacerse bajo la indicación de soporte de BMC. En casos excepcionales, la eliminación de otros archivos (como los archivos en / usr / tideway / log) podria permitir que los servicios inicien y se procesen los archivos pendientes.

- Destruir en masa una gran cantidad de hosts (> 1000) desde la interfaz grafica podría crear un archivo de transacciones muy grande. Dependiendo del espacio disponible en / usr, esto podría conducir a una saturación del disco. Se recomienda destruir hosts en lotes más pequeños (<1000) y monitorear el espacio en disco al realizar esta acción. Con la versión 11.3.01 y posterior, una alternativa es utilizar el comando "tw_query --destroy". Consultar https://docs.bmc.com/docs/display/DISCO113/tw_query.

- Puede ocurrir que en un consolidador existan demasiados archivos en el directorio / usr / tideway / var / persist / consolidation. Esto podría suceder si el consolidador no estuvo disponible durante un tiempo prolongado mientras se continuaron procesando las ejecuciones de Discovery. Para mas información ver el articulo 000118676.

- Un respaldo local podria estar ocupando demasiado espacio en / usr / tideway / var / localdisk / backup. El contenido se puede mover a otra ubicación como un servidor  remoto de Linux o un recurso compartido de Windows. De no ser indispensable al momento pofria ser eliminado ejecutando 'rm -f / usr / tideway / var / localdisk / backup / *', conservando la carpeta en sí. Si esta fue la causa raíz de la saturación del disco, las posibles soluciones son:

>  Agregar un nuevo disco y mover los respaldos a dicho disco utilizando la herramienta disponible en la interfaz grafica. Consultar https://docs.bmc.com/docs/display/disco113/Managing+disks+and+swap+space.
> Crear los respaldos en un servidor remoto ya sea Linux o Windows. Consultar https://docs.bmc.com/docs/display/disco113/Backing+up+and+restoring+the+appliance.

- Existen demasiados archivos de logs en / usr / tideway / var / pool y / usr / tideway / var / record. El contenido de estas carpetas se puede eliminar sin eliminar las carpetas en si. Es importante que el modo de "record" no permanezca habilitado durante un largo periodo de tiempo. (Consultar "record mode" en https://docs.bmc.com/docs/display/disco113/Configuring+discovery+settings)

Consultar también el siguiente video "How to resolve disk space problems in BMC Discovery"