Dimensione la aplicación que realmente ejecuta.

Antes de medir

Use una máquina de prueba Linux que controle, con su aplicación y datos representativos. Los comandos siguientes inspeccionan recursos; no ajustan el kernel ni eliminan archivos. Necesita procps y GNU coreutils, y permiso para inspeccionar el directorio de aplicación elegido. Reemplace /srv/my-app por su ruta real. Si la aplicación aún no se ejecuta en ningún sitio, use su entorno de desarrollo o staging para construir una estimación inicial, luego revise esa estimación en el sistema previsto.

Anote qué comparte el VPS: sistema operativo, proxy, API, base de datos, workers y monitorización. Registre si las compilaciones de recursos se ejecutan allí, si las copias de seguridad se comprimen localmente y si una tarea programada puede solaparse con un despliegue. Un proceso de aplicación tranquilo puede coexistir con un proceso de release costoso.

Lea la memoria disponible e identifique los procesos

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

free -m informa mebibytes. Céntrese en available, la estimación de memoria que podría soportar trabajo nuevo sin hacer swap; free por sí solo excluye memoria reclamable útil. Por lo tanto, la caché no es, por sí misma, una razón para comprar más RAM. Consulte las definiciones de campos de free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Los valores RSS de proceso anteriores corresponden aproximadamente a 384, 180 y 32 MiB. Ayudan a localizar el uso de memoria, pero sumar todos los valores RSS no es un total exacto de la máquina: las páginas compartidas pueden contarse más de una vez y algunos costes del kernel quedan fuera de la cifra del proceso. Evite imprimir argumentos de comandos o entornos al recopilar un informe, porque pueden contener secretos. El manual de ps explica sus campos y su comportamiento de instantánea.

Convierta las observaciones en una hoja de cálculo

Las siguientes asignaciones ilustran una API pequeña con una base de datos local y un worker. Son valores de planificación inventados, no benchmarks ni requisitos mínimos para un framework concreto. Sustituya sus mediciones y anote qué asignaciones pueden alcanzar su pico al mismo tiempo.

Esta hoja de cálculo ya supera un presupuesto de 1,024 MiB. Un entorno de prueba de 2,048 MiB dejaría 676 MiB frente a estas asignaciones, pero el resultado útil es si el trabajo representativo real cabe mientras la aplicación sigue respondiendo. Si la asignación de despliegue domina, compilar artefactos en otro lugar puede ser un mejor cambio que ampliar el servidor permanente. Conserve los supuestos junto al total.

Vigile la CPU y el swap durante trabajo útil

vmstat 1 10

Ejecute esto durante un lote de solicitudes representativo, un trabajo y un release. Ignore la primera línea al interpretar un intervalo reciente: resume la actividad desde el arranque. Las líneas posteriores describen los intervalos de muestreo. Trabajo ejecutable persistente en r, tiempo de inactividad bajo en id y solicitudes lentas juntos justifican investigar la presión de CPU. Actividad repetida de si/so muestra swapping; el swap asignado por sí solo no prueba presión actual. wa y st necesitan contexto en lugar de una actualización automática de CPU. Estos campos se definen en vmstat.

Registre también el tiempo de respuesta en la aplicación. Una API externa o consulta de base de datos lenta puede hacer que las solicitudes esperen mientras la CPU permanece mayormente inactiva. Repita la misma carga de trabajo después de un cambio, para saber qué cambio ayudó. Las pruebas de carga solo deben apuntar a sistemas que controle, con una tasa y una condición de parada que eviten interrumpir a otros usuarios.

Presupueste por separado el crecimiento de disco y la transferencia

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df describe el sistema de archivos que contiene la ruta, incluido el espacio compartido con otros directorios; df -i comprueba el uso de inodos donde sea compatible. Un gran número de archivos pequeños puede agotar los inodos antes que la capacidad en bytes. du estima el árbol elegido, sujeto a permisos de acceso. Son preguntas distintas, por lo que sus totales no tienen por qué coincidir. Consulte df y du.

Enumere la base de datos actual, las subidas, los registros, los artefactos de aplicación y cualquier espacio local de staging de copias de seguridad. Añada el espacio necesario para un release junto al release anterior, luego estime el crecimiento durante el siguiente intervalo de revisión. Por ejemplo, 100 MiB de nuevas subidas cada día añaden unos 3,000 MiB en 30 días antes de réplicas o copias de seguridad. Etiquete de forma coherente los GB decimales y los GiB binarios al comparar el resultado con un catálogo.

Para la transferencia, una respuesta ilustrativa de 20 kB enviada 50,000 veces es aproximadamente 1 GB de payload de respuesta. Añada subidas, archivos estáticos, sobrecarga de protocolo y tráfico de copias de seguridad. Esa aritmética estima volumen, no rendimiento ni usuarios simultáneos. Confirme cómo el servicio cuenta el tráfico y gestiona cualquier exceso.

Elija la siguiente acción y compruébela

• Memoria disponible baja durante picos normales: inspeccione los principales consumidores y pruebe un presupuesto de memoria mayor.
• Solicitudes lentas con presión de CPU sostenida: perfile la ruta ocupada, luego compare cambios de CPU usando la misma carga de trabajo.
• Uso de disco creciente: identifique el directorio responsable y la política de retención antes de eliminar nada.
• Los recursos parecen cómodos pero la aplicación es lenta: investigue dependencias, consultas y la ruta de solicitud.

Guarde la hoja de cálculo con la descripción de la carga de trabajo, la hora de muestreo, las unidades y la próxima fecha de revisión. Vuelva a comprobar tras un release sustancial, un crecimiento de datos o un worker añadido. Elija una configuración a partir de esas observaciones; ningún nombre de plan garantiza capacidad de solicitudes. Continúe con leer advertencias de memoria y disco o el primer escenario de recurso de API.