Seis fallas técnicas específicas y reconocibles explican por qué el hosting compartido falla bajo carga real: contención de recursos por vecinos ruidosos, el OOM killer de Docker que termina contenedores, límites de conexiones a la base de datos y límites de procesos, entre otras. No se trata de una vaga sensación de que el servidor está «demasiado lento». Cada una tiene una señal de diagnóstico que puedes revisar directamente y todas apuntan a la misma solución de fondo: recursos dedicados y aislados, algo que solo un VPS ofrece.
| Síntoma | Causa real | Qué revisar |
|---|---|---|
| Los tiempos de respuesta empeoran cada mes, sin cambios en el tráfico | Contención por vecinos ruidosos / CPU steal | Revisa el CPU steal time (st) y el iowait mediante monitoreo |
| Las configuraciones Docker con varios contenedores fallan con errores de memoria | Swap restringido del hosting compartido + límites de cgroup | Define límites explícitos de memoria para los contenedores y revisa los OOM kills |
| El sitio sigue lento después de subir al nivel más alto de hosting compartido | Límite de arquitectura: mismo kernel compartido, sin root y sin I/O dedicado | Confirma si el cuello de botella es CPU, I/O o la base de datos. Un plan compartido más grande puede no cambiar nada de eso |
| La app falla específicamente durante picos de tráfico | Los límites de recursos, conexiones a la base de datos y procesos se alcanzan al mismo tiempo | Primero agrega caché y una CDN; migra si los picos son frecuentes |
| El equipo de desarrollo alcanza límites de recursos al probar funciones | Los entornos de staging comparten los mismos límites que producción | Separa los pools de recursos de staging y producción |
Observa el patrón: ninguno de estos casos se trata realmente de velocidad bruta. Se trata de aislamiento de recursos, algo que el hosting compartido, por definición, no te da.
La diferencia central: recursos aislados frente a compartidos
El hosting compartido coloca muchas cuentas en el mismo servidor físico y todas usan el mismo pool de CPU, RAM e I/O. No hay un límite estricto que impida que el pico de una cuenta afecte a las demás. Un VPS usa un hipervisor para dividir ese mismo hardware físico en instancias realmente aisladas, cada una con recursos reservados específicamente para ella y acceso root para configurar el sistema operativo, instalar lo que necesites y controlar cómo se usan esos recursos. La diferencia de precio refleja una diferencia real de arquitectura, no solo un nivel de marketing.
Vecinos ruidosos y CPU steal time
Cuando los tiempos de respuesta empeoran poco a poco cada mes sin que tu tráfico cambie mucho, la causa habitual es el clásico problema del «vecino ruidoso»: otro tenant en el mismo hardware físico consume una proporción desmedida de CPU, I/O o ancho de banda de red y deja a tu aplicación sin recursos que debería poder usar. No tienes que adivinarlo a ciegas. El CPU steal time, la columna «st» en top o herramientas de monitoreo similares, mide cuánto tiempo de CPU el hipervisor retiene de tu instancia para otros tenants. Un steal time elevado junto con un iowait alto indica de forma directa y medible que existe contención de recursos, no un problema en el código de tu aplicación.
Límites de memoria de Docker y el OOM killer
Ejecutar varios contenedores Docker en hosting compartido casi garantiza fallas del OOM (Out Of Memory) killer. Los entornos compartidos normalmente restringen o desactivan por completo el espacio swap y aplican límites estrictos de memoria mediante cgroup. Sin un límite de memoria explícito para cada contenedor, con la bandera -m o el campo memory en docker-compose.yml, un solo contenedor fuera de control puede consumir toda la RAM asignable del host antes de que algo lo detenga. Cuando alcanza ese límite sin swap disponible, el OOM killer del kernel termina el proceso. El comportamiento de memoria de cada runtime agrava el problema. Node.js, por ejemplo, usa por defecto un límite de heap de V8 que puede superar el límite de memoria de tu contenedor si no lo restringes explícitamente mediante –max-old-space-size. Las imágenes base más ligeras, como Alpine en lugar de Ubuntu o Debian completos, y el monitoreo continuo con docker stats ayudan. Sin embargo, el límite de fondo, swap restringido y límites estrictos de cgroup, forma parte de la arquitectura y no puedes solucionarlo solo con configuración en hosting compartido.
Por qué subir de plan compartido no siempre ayuda
Pasar al nivel más alto de un plan compartido aumenta la parte de recursos asignada a tu cuenta, pero no cambia la arquitectura subyacente. Sigues en un kernel compartido, sin acceso root y sin una asignación de I/O dedicada. Si tu cuello de botella real es la contención por vecinos ruidosos, un límite de conexiones a la base de datos o un límite de arquitectura para procesos simultáneos, en vez de necesitar una porción apenas mayor del mismo pool compartido, un nivel compartido superior no elimina ninguno de esos límites. Esta suele ser la explicación cuando una actualización no corrige la lentitud que debía resolver: la actualización abordó la capa equivocada del problema.
Por qué el hosting compartido falla con picos de tráfico
Un pico de tráfico alcanza varios límites del hosting compartido al mismo tiempo, por eso la falla suele sentirse repentina y no gradual. Los límites estrictos de CPU y memoria por cuenta se alcanzan de inmediato, los servidores de bases de datos compartidos tienen límites de conexiones simultáneas que el tráfico en picos supera rápidamente y un límite fijo de procesos PHP o workers de aplicación simultáneos hace que los visitantes adicionales queden en cola y agoten el tiempo de espera. Una CDN y el caché de páginas u objetos pueden absorber una parte considerable de la carga antes de que llegue a tu servidor, así que conviene implementarlos sin importar el nivel de hosting. Pero para picos realmente impredecibles o de gran volumen, los recursos dedicados y escalables eliminan el límite en lugar de solo aumentarlo.
Límites de recursos que bloquean el desarrollo, no solo producción
Los mismos límites que causan incidentes en producción suelen aparecer antes, durante el desarrollo. Un equipo que prueba una función nueva en un entorno de staging que comparte el mismo pool de recursos que producción alcanza los mismos límites de CPU, memoria o procesos. En este caso bloquean la velocidad de iteración en lugar de atender tráfico en vivo. Conviene reconocerlo como una señal distinta: si tu equipo alcanza límites de hosting durante las pruebas y no solo en los picos de tráfico de producción, el nivel de hosting es insuficiente para todo el proyecto, no únicamente para los momentos de mayor demanda.
Cuándo migrar a un VPS
Cualquiera de las señales anteriores, CPU steal time en aumento, OOM kills recurrentes, una actualización que no ayudó, fallas causadas por picos o límites de recursos en el entorno de desarrollo, es un motivo razonable para migrar a un VPS en lugar de permanecer en hosting compartido esperando que el siguiente nivel lo resuelva. Para consultar un marco más detallado y basado en métricas sobre cuándo un VPS supera su propio nivel, incluidos los umbrales de CPU steal time, la latencia p95/p99 y cuándo un VDS es el siguiente paso adecuado, consulta nuestra guía sobre la actualización de VPS a VDS.
Preguntas frecuentes: síntomas de fallas en hosting compartido
¿Cuáles son las principales diferencias entre el hosting compartido y un VPS para ejecutar una aplicación web en producción?
El hosting compartido coloca muchas cuentas en el mismo servidor y comparten el mismo pool de recursos sin aislamiento estricto. Un VPS usa un hipervisor para darte CPU, RAM y almacenamiento realmente dedicados, además de acceso root para que configures el servidor. Para una aplicación en producción, ese aislamiento evita que el pico de tráfico de otra cuenta afecte tu uptime.
¿Por qué los tiempos de respuesta de mi servidor empeoran cada mes aunque el tráfico no haya cambiado mucho?
Este es el patrón clásico del vecino ruidoso: otro tenant en tu hardware compartido consume una parte cada vez mayor de CPU, I/O o ancho de banda. Revisa el CPU steal time y el iowait en tus herramientas de monitoreo. Valores elevados en ambos son una señal directa y medible de contención de recursos, no de un problema en tu propia aplicación.
¿Por qué ejecutar varios contenedores Docker en hosting compartido sigue fallando con errores de memoria?
El hosting compartido normalmente restringe o desactiva el swap y aplica límites estrictos de memoria mediante cgroup. Sin límites de memoria explícitos por contenedor, un solo contenedor puede consumir toda la RAM disponible y activar el OOM killer del kernel. Definir límites de memoria y usar imágenes base más ligeras ayuda, pero el límite causado por el swap restringido forma parte de la arquitectura del hosting compartido.
¿Por qué mi sitio web sigue cargando lento incluso después de subir al nivel más alto de hosting compartido?
Un nivel compartido superior aumenta tu asignación de recursos, pero no cambia la arquitectura subyacente. Sigues en un kernel compartido sin acceso root ni I/O dedicado. Si tu cuello de botella real es la contención por vecinos ruidosos o un límite de conexiones a la base de datos, un plan compartido más grande no resuelve ninguno de los dos.
¿Por qué mi aplicación web falla durante picos de tráfico en hosting compartido?
Los picos alcanzan varios límites del hosting compartido a la vez: límites de CPU y memoria por cuenta, límites de conexiones a la base de datos y límites de procesos. Las solicitudes quedan en cola y agotan el tiempo de espera en vez de ser atendidas. El caché y una CDN ayudan a absorber carga. Para picos frecuentes o impredecibles, los recursos dedicados eliminan el límite en lugar de solo aumentarlo.
¿Por qué nuestro equipo de desarrollo sigue alcanzando límites de recursos al probar funciones nuevas?
Los entornos de staging en hosting compartido suelen usar el mismo pool de recursos que producción. Por eso, los mismos límites de CPU, memoria o procesos que causan incidentes en producción también ralentizan las pruebas y la iteración. Es una señal de que el nivel de hosting es insuficiente para todo el proyecto, no solo para el tráfico en horas pico.
Descargo de responsabilidad: las especificaciones, funciones y precios de los productos mencionados en este artículo pueden cambiar y variar según la región, el periodo de facturación y las promociones activas. Consulta el sitio web oficial de cada proveedor o marca para conocer las cifras y los precios vigentes.
