Lea las advertencias de memoria y disco antes de actualizar.

Captura una pequeña línea base con contexto

Usa una cuenta de Linux autorizada para inspeccionar la aplicación que operas. Los comandos aquí inspeccionan el estado; no eliminan archivos ni redimensionan el almacenamiento. Algunos directorios y diarios requieren acceso elevado. Reemplaza /var/lib/field-api, /opt/field-api y /opt/first-api con rutas de aplicación reales, y confirma que esas rutas existen antes de interpretar los resultados.

Registra la hora, la versión actual y la actividad: tráfico normal, una carga, un trabajo de informes o una compilación de despliegue. Toma otra lectura durante una actividad comparable. Dos capturas de pantalla no relacionadas pueden hacer que una máquina sana parezca inconsistente. Si los usuarios ya están afectados, captura la primera pista útil de la guía de fallos de aplicación antes de hacer varios cambios a la vez.

Lee la memoria disponible y luego inspecciona la carga de trabajo

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

En free, la memoria disponible estima qué podría usarse para nuevas aplicaciones sin recurrir al swap. Tiene en cuenta la caché reclamable, por lo que responde a una pregunta distinta de la memoria “libre” completamente sin usar. Consulta el manual upstream de free. Linux usa memoria para el almacenamiento en caché de archivos; una caché grande por sí sola no es evidencia de una fuga. La descripción general de la memoria del kernel explica por qué la caché y la memoria de la aplicación coexisten.

Lectura ilustrativa, no una medición del servidor: un host pequeño tiene alrededor de 1.9 GiB de memoria utilizable, 80 MiB libres y 850 MiB disponibles. La cifra baja de memoria libre por sí sola no justifica una actualización. Si la memoria disponible cae repetidamente cerca de cero durante un informe, las solicitudes se ralentizan y aparecen mensajes relevantes de asignación o de memoria agotada, esa evidencia combinada merece una investigación.

El ps El comando lista el RSS de los procesos en KiB, del mayor al menor. El RSS describe la memoria residente, no una contabilidad completa de la propiedad exclusiva; las páginas compartidas pueden aparecer en varios procesos. No sumes todas las cifras de RSS y trates el resultado como uso exacto del host. La referencia upstream de ps define el RSS y la ordenación. Registra el nombre del proceso y si su huella vuelve hacia su nivel anterior después de que termina la carga de trabajo.

El swap en uso puede reflejar actividad anterior; por sí solo no prueba presión actual. Distingue también la capacidad del host de los límites del servicio o contenedor. Un proceso limitado puede fallar mientras el host todavía tiene memoria disponible. Inspecciona el límite configurado y el momento del fallo antes de aumentar el tamaño del VPS. La referencia del sistema de archivos proc del kernel documenta los campos de memoria detrás de estas observaciones.

Encuentra el sistema de archivos que realmente se está llenando

df -h / /opt/first-api
df -i / /opt/first-api

El primer comando informa el espacio en los sistemas de archivos que contienen esas rutas. El segundo informa los inodos, que son registros del sistema de archivos necesarios para archivos y directorios. Una carga de trabajo con muchos archivos diminutos puede agotar los inodos mientras la capacidad en bytes sigue disponible. Comprueba el punto de montaje y ambos tipos de capacidad en lugar de usar el tamaño de todo el VPS como tu único número. Consulta el manual GNU de df.

Una ruta en un volumen montado por separado puede llenarse independientemente del sistema de archivos raíz. A la inversa, dos rutas listadas pueden pertenecer al mismo sistema de archivos, por lo que su espacio disponible no es aditivo. Las reservas del sistema de archivos, las cuotas y las capas de almacenamiento también pueden afectar lo que la aplicación puede escribir. Un único porcentaje mostrado no identifica al propietario del crecimiento.

Atribuye el crecimiento a registros, cargas o artefactos

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du estima el espacio asignado bajo cada directorio. Aquí -x evita cruzar a otro sistema de archivos, -h usa unidades legibles y -d1 limita la profundidad mostrada. Los árboles grandes todavía pueden tardar tiempo y actividad de disco en escanearse. Los errores de permisos significan que la vista está incompleta. Consulta el manual GNU de du. El comando del diario informa el almacenamiento del diario, incluidos los archivos activos y archivados, como documenta journalctl.

Compara los directorios más grandes con su propósito:

• Registros: ¿un error repetido aumentó el volumen, y está configurada la rotación?
• Cargas: ¿los archivos de usuario retenidos crecen según lo esperado, y se tienen en cuenta las cargas parciales abandonadas?
• Artefactos de versión: ¿se acumulan compilaciones antiguas más allá de la política de reversión?
• Archivos de base de datos: ¿las propias herramientas de la base de datos explican el crecimiento y las necesidades de mantenimiento?

No elimines un directorio de base de datos desconocido ni uses una limpieza amplia de volúmenes de contenedores como paso de investigación. Identifica primero la propiedad, los requisitos de retención y una copia recuperable. Si df y los totales de directorios discrepan sustancialmente, inspecciona los límites de montaje, los errores de acceso y los archivos que siguen abiertos tras su eliminación con un operador experimentado; eliminar repetidamente los archivos visibles puede pasar por alto el espacio ocupado.

Convierte las lecturas en una acción siguiente concreta

Caso ilustrativo: la memoria disponible se mantiene cómoda, pero un directorio de cargas crece aproximadamente 400 MiB en cada uno de dos días observados. El sistema de archivos tiene alrededor de 2 GiB disponibles. Dividir el espacio restante entre ese crecimiento a corto plazo sugiere solo unos cinco días al mismo ritmo, antes de permitir margen operativo. Es una estimación de planificación, no un pronóstico ni una fecha límite segura hasta la que esperar; las cargas y el trabajo temporal pueden llegar de forma desigual.

La siguiente acción es comprobar la retención de cargas y la demanda esperada, planificar almacenamiento adicional si está justificado y configurar una alerta con suficiente antelación para actuar. Más RAM no resolvería este hallazgo. En un caso diferente, una compilación de despliegue podría crear un pico breve de memoria mientras el servicio sigue siendo pequeño; mover la compilación fuera del VPS podría ser más útil que ampliar permanentemente el entorno de ejecución.

Después de un cambio justificado, repite las mismas lecturas y una acción de la aplicación. Confirma que el espacio está realmente disponible y que los datos previstos siguen funcionando. Mantén la eliminación y el redimensionamiento como operaciones planificadas con pasos de recuperación, no como respuestas automáticas a un número en rojo. Usa la guía de presupuesto de recursos para convertir una necesidad demostrada en opciones de configuración, y practica la restauración antes de depender de una limpieza o migración.