Comprender y comprobar los límites de LVE de CloudLinux en el alojamiento compartido

Qué limita un LVE en el alojamiento compartido

En el alojamiento compartido, varios clientes comparten los recursos de un servidor. CloudLinux puede limitar el uso de una cuenta de cliente con un Entorno virtualizado ligero, abreviado LVE. El proveedor establece cuáles son los límites aplicables. Su objetivo es evitar que una cuenta consuma recursos de forma ilimitada; por el contrario, también es posible que la propia página web alcance esos límites.

Un límite describe un tope máximo y no supone automáticamente un servicio reservado. Por ejemplo, un límite de CPU no significa que tengas un núcleo de procesador en exclusiva ni que se te garantice un tiempo de respuesta concreto. La velocidad a la que funciona una aplicación depende también de su tarea, del hardware y de otros componentes.

Un LVE tampoco convierte tu paquete de alojamiento en un servidor propio. El proveedor sigue gestionando el entorno compartido y determina su configuración. Como cliente, solo puedes comprobar por ti mismo los valores vigentes y sus consecuencias en la medida en que tu tarifa y el panel de control de alojamiento te faciliten la información correspondiente.

Hay que distinguirlo de CageFS: Se refiere al aislamiento de la vista del sistema de archivos, mientras que los límites de LVE restringen el uso de recursos. Ambas funciones pueden complementarse, pero no son lo mismo. El proveedor puede confirmarte qué componentes están realmente activos en tu oferta.

Encontrarás una explicación más detallada de los componentes en el artículo sobre Aislamiento de procesos con CloudLinux SecureLVE. No obstante, para la localización concreta de errores, la configuración de tu propio paquete es fundamental: la interfaz y el nivel de detalle de la visualización de recursos pueden variar en función del panel y de la activación.

¿A quiénes se aplican los límites?

Lo decisivo no es solo el importe de un límite, sino también su Ámbito de aplicación. Si, por ejemplo, gestionas un blog y una tienda en la misma cuenta de alojamiento, ambos pueden consumir el mismo presupuesto de recursos en una configuración vinculada a la cuenta. Una importación en la tienda puede ocupar entonces capacidad que el blog también necesita en ese mismo momento.

Esto no significa que cada página lenta se deba a otro proyecto de la cuenta. Sin embargo, explica por qué, ante un incidente límite, no debes fijarte únicamente en el dominio afectado en ese momento. Las tareas programadas y otros sitios web de la misma cuenta también pueden ser relevantes durante el periodo en cuestión.

CloudLinux documenta con Aislados Además, ofrece la posibilidad de establecer límites a nivel de sitio web. La denominación «CloudLinux» por sí sola no permite deducir si se utiliza esta función ni cómo se aplica en cada oferta concreta. Por lo tanto, un análisis aislado tampoco sustituye a la consulta de las condiciones específicas de cada tarifa.

Antes de comparar tarifas, pregunta al proveedor de la forma más concreta posible: ¿los valores de SPEED, PMEM, IO, IOPS, EP y NPROC se aplican por cuenta de alojamiento o por sitio web? Si varios proyectos comparten un presupuesto, también es importante saber qué dominios y tareas se asignan a ese presupuesto. De este modo, evitarás incluir por error un valor indicado para cada sitio web individual.

Si el panel solo muestra una estadística global, esta sirve, en un primer momento, para delimitar el intervalo de tiempo, pero no necesariamente para asignarla a una aplicación concreta. En ese caso, solicita información al servicio de asistencia sobre qué desglose está disponible y si la carga se puede asignar a un proyecto o a una tarea.

Distinguir entre CPU, memoria y límites de acceso

Los distintos límites del alojamiento compartido restringen diferentes tipos de actividades. VELOCIDAD se refiere al presupuesto de CPU: si se agota, los procesos que requieren un gran esfuerzo de cálculo se ralentizan y las solicitudes pueden tardar más en procesarse. Por lo tanto, un límite de CPU en el alojamiento web es solo una posible explicación para la lentitud de las páginas, y no equivale a todos los límites de LVE.

PMEM limita la memoria física del LVE. En caso de presión de memoria, primero se puede liberar la caché; si eso no es suficiente, se pueden terminar procesos. Hay que distinguirlo del valor obsoleto VMEM para la memoria virtual. Del mismo modo, el PHP-memory_limit no debe equipararse al presupuesto total del PMEM del LVE.

En el acceso a los archivos, IO e IOPS miden cosas diferentes: IO se refiere al rendimiento de datos, mientras que IOPS indica el número de operaciones de lectura y escritura por segundo. Por eso, muchos archivos pequeños pueden alcanzar un límite diferente al de unos pocos archivos grandes. En este contexto, IO no se refiere a la velocidad de tu conexión a Internet.

El EP contabiliza las entradas en el LVE y no constituye un límite general para el número de visitantes simultáneos. La forma en que se contabilizan las entradas depende, entre otras cosas, del servidor web y del modelo de proceso. NPROC Por el contrario, limita los procesos y los subprocesos. Cuando se alcanza este límite, no se pueden crear más procesos de forma temporal; por lo tanto, EP y NPROC no son intercambiables.

El espacio de almacenamiento y los inodos son datos de tarificación relacionados, pero independientes. El hecho de que se haya agotado la cuota de archivos o se haya alcanzado el límite de inodos no supone automáticamente un problema de CPU, PMEM o EP. Los valores que puedas ver en el panel dependen del proveedor y de la interfaz que este ofrezca.

Resumen de los límites del LVE y sus consecuencias

No todos los límites de LVE funcionan de la misma manera: algunos frenan el trabajo en curso, otros impiden que se inicien nuevos procesos o pueden interrumpir los ya existentes. La tabla te ayuda a asociar un recurso mostrado con su comportamiento y una pista de auditoría adecuada. Los valores límite concretos los establece tu proveedor.

En Límite de PMEM No solo se tiene en cuenta la memoria de los procesos de aplicación individuales. También se pueden incluir la memoria compartida y la caché de archivos; que se tenga en cuenta la caché depende de la configuración. Si se cierran los procesos, pueden producirse errores HTTP, aunque esto no tiene por qué ser la consecuencia visible.

Los dos límites de acceso a los archivos se refieren a magnitudes diferentes: IO limita el rendimiento de datos, mientras que las IOPS limitan el número de operaciones. Por lo tanto, muchos archivos pequeños pueden consumir sobre todo IOPS, mientras que los archivos grandes pueden generar un alto rendimiento. En este contexto, «IO» no se refiere al ancho de banda de la red; según CloudLinux, los accesos desde la caché de archivos no cuentan para el límite de IO.

Calcular el límite de la CPU con un ejemplo

Supongamos que tu paquete tuviera un Límite de VELOCIDAD del 150 %. Dado que, matemáticamente, el 100 % equivale a un núcleo de procesador, esto supone un presupuesto de CPU equivalente a un núcleo y medio. Se trata de un ejemplo ilustrativo, no de una medición. El valor real de tu paquete puede variar; lo que prevalece es la información facilitada por el proveedor.

El ejemplo describe un límite máximo para el tiempo de CPU utilizable, no una reserva de un núcleo exclusivo. Tampoco significa que cada proceso pueda utilizar un núcleo y medio al mismo tiempo. La forma en que se distribuye el presupuesto entre las tareas en ejecución depende, entre otras cosas, del número de procesos que realmente necesiten tiempo de cálculo en paralelo.

Un 150 % no garantiza ni un tiempo de respuesta concreto ni un número determinado de visitantes que se puedan atender simultáneamente. Una solicitud sencilla puede requerir poco esfuerzo de cálculo, mientras que una solicitud dinámica puede requerir mucho más. A esto hay que añadir los posibles tiempos de espera para acceder a archivos o realizar operaciones en la base de datos, que un mayor presupuesto de CPU no elimina automáticamente.

Además, unos porcentajes iguales en servidores diferentes no suponen una comparación directa de la velocidad: los núcleos del procesador pueden diferir en su rendimiento. Por lo tanto, para evaluar el límite de tu CPU es más importante que el uso se sitúe repetidamente en el límite durante un problema concreto y que se observen los eventos de límite correspondientes. Incluso en ese caso, deberías comprobar otras posibles causas.

Cómo interpretar correctamente los datos sobre recursos

Si tu proveedor ha habilitado la vista de recursos, empieza por un incidente lo más concreto posible. Anota el dominio, la fecha, la hora y la zona horaria, así como, si procede, el estado HTTP que se muestra. Describe también qué fue lo que funcionó con lentitud o qué falló. Sin estos datos, resulta muy difícil atribuir un pico en las estadísticas a un problema concreto.

A continuación, selecciona el mismo periodo en la pantalla y compara, para CPU, PMEM, IO, IOPS, EP y NPROC, el uso, el límite establecido y, en su caso, los valores mostrados Fallos. No todas las interfaces muestran los mismos valores. Si te faltan datos estadísticos o no tienes claro a qué cuenta se refieren, consulta al proveedor.

Presta atención a la Resolución temporal: Un valor medio por hora bajo puede ocultar un breve pico en el que se alcanzó un límite. Si está disponible, elige un intervalo de tiempo más corto o una representación más detallada. Compara el pico con el tiempo de error registrado, en lugar de deducir, basándote únicamente en un promedio diario o por hora, que no se produjo ningún cuello de botella.

Los errores señalan incidentes límite, pero no constituyen un recuento directo de los visitantes afectados ni de las visitas fallidas a las páginas. Un fallo que coincide temporalmente es un indicio, pero no una prueba concluyente de la causa. Por lo tanto, comprueba también si en ese mismo momento se estaba llevando a cabo una importación, una copia de seguridad, una tarea programada o un cambio en la aplicación.

La interfaz y sus funciones dependen del panel y de la configuración; por lo tanto, no existe una ruta de menú válida para todos los casos. Para conocer los aspectos técnicos de la gestión, consulta el artículo sobre CloudLinux LVE Manager y para la gestión de recursos Más información. No obstante, los pasos de configuración administrativa que se indican allí requieren los permisos correspondientes y no están disponibles automáticamente para tu cuenta de cliente.

Clasificar las páginas lentas y los errores

Si tu CMS va lento al editar o al cargar páginas dinámicas, compara primero el periodo afectado con el indicador de la CPU. Si el uso se sitúa repetidamente en el límite de SPEED y se observan errores correspondientes, es necesario un Reducción de la velocidad de la CPU Es plausible. La coincidencia temporal la convierte en una pista, pero aún no demuestra qué tarea provocó la carga.

Comprueba, por ejemplo, si hay tareas programadas que se están ejecutando al mismo tiempo o si el problema coincide con algún cambio en las extensiones. Las operaciones con la base de datos, los problemas de red o una interfaz externa que responde con lentitud también pueden ralentizar las páginas. Por lo tanto, una elevada carga de la CPU por sí sola no significa ni que se haya elegido mal el plan de tarifas, ni que la culpa deba recaer necesariamente en una extensión concreta.

Si se producen errores cuando llegan varias solicitudes dinámicas al mismo tiempo, puede producirse un Fallo de EP ayudar. Las solicitudes de larga duración mantienen las entradas ocupadas durante más tiempo; al mismo tiempo, un visitante puede generar varias solicitudes. Por lo tanto, el EP no es un recuento de visitantes. En Apache, el código HTTP 508 es una posible consecuencia de haber superado el límite de EP, pero el estado por sí solo no confirma la causa.

Si durante una importación la pantalla muestra errores PMEM, es posible que la causa sea el límite de memoria de LVE. Además de la importación, los procesos PHP que se estén ejecutando simultáneamente pueden consumir memoria; sin los datos de proceso adecuados, no se puede determinar qué tarea fue la que provocó el problema. Asimismo, un error HTTP 500 o 503 puede tener otras causas y, por sí solo, no es prueba de falta de memoria.

El valor de PHP memory_limit Esto no responde por sí solo a la pregunta: no describe el uso total de memoria de todas las tareas del LVE. Por lo tanto, compara la hora de la importación con el uso de PMEM y los fallos, y toma nota de qué otras tareas se estaban ejecutando en paralelo antes de modificar un ajuste o la tarifa.

Comprobar la carga de fondo e involucrar al servicio de asistencia

Si una copia de seguridad o la importación de archivos se realiza con lentitud, comprueba IO e IOPS Por separado. La E/S limita el caudal de datos en los accesos a los discos duros, mientras que las IOPS indican el número de operaciones de lectura y escritura por segundo. Por lo tanto, muchos archivos pequeños pueden suponer un límite diferente al de la transferencia de unos pocos archivos grandes; en este contexto, la E/S no se refiere al ancho de banda de Internet.

Una copia de seguridad puede requerir recursos tanto de la CPU como de la memoria al mismo tiempo. Por lo tanto, además de las operaciones de E/S y las IOPS, comprueba también la VELOCIDAD y la PMEM durante el mismo periodo de tiempo, en lugar de deducir la causa basándote únicamente en la duración. Según CloudLinux, los accesos que se gestionan desde la caché de archivos no cuentan para el límite de E/S; por lo tanto, el uso de E/S que se muestra no refleja todos los accesos a archivos por igual.

Si es posible posponer una tarea programada, compara su ejecución habitual en una fase de menor carga con un periodo anterior similar. Ten en cuenta el volumen y las tareas que se ejecutan en paralelo: una importación de menor envergadura no es directamente comparable con una copia de seguridad completa. No es necesario realizar pruebas de carga adicionales ni eliminar archivos para esta clasificación.

En Carga de la base de datos puede influir, incluso si el uso de la CPU web que se muestra es bajo. Su asignación a la cuenta y los posibles límites independientes de MySQL dependen de la configuración. Pregunta al proveedor qué valores de la base de datos puedes ver en el panel y si el trabajo de la base de datos se contabiliza en la LVE o se limita por separado.

Para una solicitud de asistencia, resulta útil indicar el dominio, la hora con la zona horaria, el estado HTTP observado y el proceso afectado. Añade los límites, los valores de uso y los fallos visibles durante ese mismo periodo, así como las importaciones o copias de seguridad conocidas. Solicita la asignación de los eventos límite y, si está disponible, un análisis de las instantáneas del proceso; de este modo, se podrá comprobar la hipótesis de forma más precisa.

¿Optimizar, actualizar o cambiar de servidor?

Empieza por la Optimización una tarea identificada, si es posible reducir de forma justificada sus necesidades de recursos. Comprueba, por ejemplo, la configuración de la caché, las extensiones y las tareas en segundo plano programadas en paralelo. A continuación, compara periodos similares y presta atención tanto a los problemas de los usuarios como a los valores de los recursos afectados. De este modo, un único cambio permite identificar más fácilmente qué es lo que realmente ha cambiado.

Una actualización es una alternativa cuando los picos recurrentes y confirmados alcanzan los límites asignados a pesar de una optimización adecuada. Pregunta primero por los valores concretos de SPEED, PMEM, IO, IOPS, EP y NPROC. No te limites a comparar los nombres de los paquetes: un límite de CPU más alto no elimina ni un límite de EP independiente ni una falta de memoria LVE.

Al Comparativa de tarifas También hay que tener en cuenta el ámbito de aplicación. Indica al proveedor cuántos sitios web incluye tu cuenta y pregúntale si utilizan un presupuesto de recursos común o si se aplican límites por sitio web. CloudLinux ofrece, con Isolates, una opción para esto último; sin embargo, el nombre del producto por sí solo no indica que tu oferta lo utilice.

Un VPS o un servidor gestionado puede ofrecer más flexibilidad, pero no es una solución automática para cualquier página web lenta. Los factores decisivos son los recursos disponibles, la carga real y el modelo de funcionamiento: en el caso de un VPS, debes aclarar, sobre todo, qué tareas de administración vas a asumir tú mismo; en el caso de un servidor gestionado, qué tareas se encarga de realizar el proveedor.

Si la causa sigue sin estar clara, es más recomendable consultar los datos recopilados sobre los momentos y los errores que cambiar por mera sospecha. Incluso por debajo de un límite de LVE, la aplicación, la red o la base de datos pueden ralentizar el sistema. Antes de tomar una decisión, asegúrate de qué estadísticas y asistencia están disponibles en la oferta en cuestión.