Límites del servidor en el alojamiento: optimizar los límites de archivos y procesos

Límites del servidor En el alojamiento, controlas específicamente cuántos archivos y procesos pueden mantener abiertos tus servicios al mismo tiempo, lo que decide sobre la latencia, los mensajes de error y la disponibilidad. Te mostraré paso a paso cómo medir, ajustar y supervisar los límites de archivos y procesos para que los servidores web funcionen sin problemas incluso bajo carga. fiable trabajo.

Puntos centrales

• Blando/Duro Comprender los límites y establecerlos adecuadamente
• sin archivo (archivos) y nproc (procesos) aumento selectivo
• PHP-FPM y configurar correctamente las colas
• Monitoreo y reconocer los cuellos de botella
• Seguridad con límites superiores razonables

Los límites máximos explicados brevemente: blandos frente a duros

Utilizo Ulimits para obtener datos fiables por usuario o proceso. Límites para los recursos. Los límites blandos son los límites actuales, modificables, que puedo aumentar hasta el límite duro si la aplicación necesita más margen de maniobra a corto plazo. Los límites duros representan el límite superior absoluto y evitan el crecimiento descontrolado de servicios individuales, que afectaría a todo el host. Por defecto, el comando ulimit hace referencia al límite duro sin un conmutador, lo que facilita los ajustes a los administradores con derechos. Esto evita que un único script sobrecargue el servidor con demasiados archivos o procesos. sobrecargado.

Siempre diferencio entre los parámetros más importantes como sin archivo (abrir archivos), nproc (procesos/hilos), fsize (tamaño de archivo), stack (tamaño de pila) y cpu (tiempo de CPU). Las pilas web con componentes PHP, base de datos y caché, en particular, suelen requerir un número de descriptores abiertos significativamente superior a los valores mínimos por defecto. Sin los límites correctos, se acumulan mensajes como „demasiados archivos abiertos“, largos tiempos de respuesta o tiempos de espera de las peticiones. Primero mido el uso real, aumento los límites gradualmente y luego compruebo la latencia, los contadores de errores y el rendimiento. Así garantizo un rendimiento constante con niveles de acceso elevados. Tiempos de respuesta.

Por qué los límites son cruciales en el alojamiento

Los entornos de alojamiento comparten recursos de hardware, por lo que utilizo límites adecuados para evitar el acceso injusto a los recursos por parte de cuentas o servicios individuales y mantener la Actuación estables. En los planes básicos, por ejemplo, los procesos CGI/PHP simultáneos y el tiempo de CPU por usuario están limitados para que un cron job defectuoso no ralentice todo el host. En los planes superiores, se pueden ejecutar más procesos y se puede utilizar más RAM, lo que beneficia a aplicaciones exigentes como las tiendas. Siempre evalúo conjuntamente el número de procesos, la RAM por proceso y el tiempo de CPU para que no queden cuellos de botella artificiales. Proporciono un marco práctico detallado para los recursos justos en el artículo sobre Límites del alojamiento compartido, que explica de forma compacta las conexiones organiza.

En archivo es crítico porque cada archivo abierto, cada socket y cada tubería enlaza un descriptor. Los valores por defecto de 1024 son a menudo demasiado pequeños para las aplicaciones web modernas, especialmente cuando hay muchas conexiones simultáneas. Por lo tanto, antes de aumentar los valores, primero leo los picos reales de los registros y las herramientas para conocer los efectos sobre las tablas del núcleo y la presión de la memoria. Esto me permite aumentar el rendimiento sin poner en peligro la seguridad y la capacidad de respuesta del host. Si se entiende el principio, se evitan fallos aleatorios debidos a unos valores demasiado ajustados Barreras.

Los parámetros más importantes en la vida cotidiana: nofile, nproc y co.

Para cargas de trabajo relacionadas con la web sin archivo en la parte superior porque las conexiones HTTP, los sockets ascendentes y las conexiones a bases de datos consumen cantidades ingentes de descriptores. Planifico buffers para picos de carga, por ejemplo de dos a cuatro veces el pico típico, para que las oleadas cortas de tráfico no provoquen errores de inmediato. Para los servicios basados en trabajadores, escalo nofile en paralelo con el número de trabajadores y sus conexiones máximas. Si se añade una CDN, un proxy inverso o una capa de mensajería, la demanda vuelve a aumentar, lo que tengo en cuenta en el cálculo. Sólo con un búfer limpio desaparecen los errores esporádicos de „archivo abierto“ y el Tasa de error disminuye.

En nproc-Considero los procesos y los hilos juntos porque algunos tiempos de ejecución utilizan pools de hilos que cuentan para el límite superior. Compruebo las estrategias de spawn de los servidores web, los servidores de aplicaciones y la base de datos para que el límite superior no surta efecto de forma inadvertida y bloquee nuevos trabajadores. Si los valores de nproc son demasiado bajos, esto se manifiesta a menudo como lanzamientos de servicios lentos o colas que no se procesan. Aumento el límite para que coincida con el número de núcleos de la CPU, la carga IO y la arquitectura de la aplicación. Esto mantiene el proceso de spawn predecible y previene la rigidez. Atascos.

Comprobar Ulimits: así leo la realidad

Empiezo cada optimización por la visibilidad, porque sin cifras, las medidas siguen siendo ciego. El comando ulimit -a me muestra los límites actuales de la sesión de shell y, por tanto, proporciona la base para comparaciones con configuraciones de servicio. Compruebo nofile y nproc por separado porque estos valores son los primeros en alcanzar sus límites en el alojamiento. También utilizo lsof, ss o netstat para contar los archivos abiertos y los sockets por proceso. Sólo cuando conozco el pico de carga en producción planifico los buffers y los añado al Valores límite en.

# Todos los límites de una sesión
ulimit -a

# Descriptores de fichero (soft/hard)
ulimit -n
ulimit -Hn

# Procesos/hilos por usuario
ulimit -u
ulimit -Hu

Para los servicios que systemd inicia, no sólo miro mi shell interactivo, porque systemd establece su propio Límites. Por lo tanto, comparo los valores efectivos de un proceso en ejecución a través de /proc//limits para exponer las incoherencias entre el shell y el servicio. Las desviaciones indican que faltan ajustes en los archivos de unidad, que luego añado directamente. Esta comparación me ahorra un montón de rompecabezas sobre por qué una aplicación no se le permite abrir archivos adicionales a pesar de mayores límites de shell. Esto me permite encontrar rápidamente las lagunas de configuración y garantizar la coherencia de las aplicaciones. Marco.

Personalizar temporalmente: pruebas rápidas en sesiones en curso

Antes de fijar límites de forma permanente, pruebo específicamente límites más altos en un caparazón. Valores. Esto me permite ver sin reiniciar si la aplicación está aceptando más conexiones como se esperaba o si la latencia está disminuyendo. Los valores aumentados se aplican en esta sesión hasta que la cierro o reinicio el servicio. Documento el efecto en syslog, registros de errores y métricas para que los ajustes permanentes posteriores estén bien fundamentados. Las pruebas cortas me ahorran grandes retrocesos y proporcionan resultados fiables. Recibos.

# Temporal en el shell actual
ulimit -n 65536 # Aumentar descriptores de fichero
ulimit -u 4096 # Aumentar el límite de procesos/hilos

# Comprobar/ajustar explícitamente límites duros (root)
ulimit -Hn 131072
ulimit -Hu 8192

Llevo a cabo estas pruebas en momentos de picos de carga previstos para analizar los efectos reales. Véase. Si los errores de „demasiados archivos abiertos“ cesan y el número de peticiones por segundo aumenta, registro los valores medidos. Si el impacto sigue siendo bajo, busco frenos paralelos como backlogs de sockets demasiado estrechos, límites de trabajadores en el servidor web o pools de conexiones a bases de datos. Sólo cuando toda la cadena escala, un servidor ulimit más alto se amortiza limpiamente. De este modo, evito optimizaciones parciales que al final no tienen ningún efecto apreciable. Mejora traer.

Configurar permanentemente: limits.conf y systemd

Para valores permanentes, edito /etc/security/limits.conf y añado valores específicos de usuario o servicio. Líneas. Diferencio entre límites blandos y duros para que las aplicaciones sigan siendo muy elásticas a corto plazo pero sigan teniendo un límite superior claro. Para los servicios systemd, también establezco LimitNOFILE y LimitNPROC, porque de lo contrario los archivos de unidad anulan los cambios del shell. Después de personalizar, recargo systemd y reinicio los servicios afectados para que los nuevos límites surtan efecto. El reinicio es importante, de lo contrario los procesos permanecen en el antiguo Valores del marco.

# /etc/security/limits.conf (ejemplo)
* soft nofile 65536
* hard nofile 131072
www-data soft nproc 4096
www-data hard nproc 8192

# unidad systemd (por ejemplo, /etc/systemd/system/nginx.service.d/limits.conf)
[Servicio]
LimitNOFILE=65536
LimitNPROC=4096

# Activar cambios
systemctl daemon-reload
systemctl restart nginx

Contexto	Ubicación	Validez	Típico
Sesión interactiva	ulimit en Shell	Sólo shell/childs actuales	Pruebas rápidas
Usuario de todo el sistema	/etc/security/limits.conf	Procesos basados en Login/PAM	Base duradera
Servicios (systemd)	Fichero de unidad: LimitNOFILE/LimitNPROC	Único servicio afectado	Límites claros de los servicios

Clasificar correctamente los límites del núcleo de todo el sistema

Además de los límites de proceso y usuario, hay límites para todo el sistema que siempre compruebo. Incluso un nofile alto es inútil si el kernel mantiene corta la tabla global de descriptores de fichero. Por tanto, compruebo fs.file-max (total de FDs abiertos posibles) y fs.nr_open (máximo de FDs permitidos por proceso a nivel de kernel). Si estos valores no coinciden, alcanzo los límites antes de tiempo a pesar de aumentar los ulimits.

# Comprueba los límites del sistema
cat /proc/sys/fs/file-max
cat /proc/sys/fs/nr_open
cat /proc/sys/fs/file-nr # En uso, Libre, Max

# Aumentar temporalmente (hasta reiniciar)
sysctl fs.file-max=2097152

# Permanente (en /etc/sysctl.d/99-ulimits.conf)
fs.file-max = 2097152

Observo la cascada: Límite de proceso (RLIMIT_NOFILE) ≤ fs.nr_open ≤ fs.file-max (global). Si nofile se establece a través de fs.nr_open, el núcleo ignora silenciosamente la solicitud. Dimensiono globalmente en consecuencia, luego por servicio. Para aceptar backlogs, también dimensiono net.core.somaxconn y los parámetros backlog de los respectivos servicios, de lo contrario las conexiones entrantes seguirán muriendo de hambre en la cola.

unidades systemd: TasksMax, PIDsMax y DefaultLimits

En las distribuciones modernas, systemd no sólo limita los descriptores, sino también el número de tareas (procesos/hilos) por servicio mediante TareasMax. Establezco valores apropiados para configuraciones de alta concurrencia o uso „infinito“ al transferir el control a nproc. Para servicios de usuario [email protected] respectivamente conf.sistema con interruptores DefaultLimit* para elevar los valores de referencia de forma coherente.

# Service drop-in para más tareas y FD
mkdir -p /etc/systemd/system/php-fpm.service.d
cat < /etc/systemd/system/php-fpm.service.d/limits.conf
[Servicio]
LimitNOFILE=131072
LimitNPROC=8192
TareasMáx=16384
EOF

systemctl daemon-reload
systemctl restart php-fpm

# Valores por defecto de todo el sistema (usar con cuidado)
# /etc/systemd/system.conf
DefaultLimitNOFILE=65536
DefaultLimitNPROC=4096
DefaultTasksMax=8192

Importante: los inicios de sesión sudo, su y SSH heredan los límites de forma diferente. Para inicios de sesión basados en PAM, /etc/security/limits.conf tiene efecto, pero a menudo no para shells sin inicio de sesión o cronjobs. Por lo tanto, siempre pruebo la ruta completa a través de la cual se inicia mi servicio para que no queden desviaciones silenciosas.

Escalado de servidores web con Ulimits

Con NGINX, vinculo worker_processes, worker_connections y worker_rlimit_nofile con los límites de todo el sistema. Regla general: Conexiones simultáneas máximas ≈ worker_processes × worker_connections, más reserva para upstreams, logs y tuberías internas. Sin un worker_rlimit_nofile incrementado, NGINX se ejecuta antes en EMFILE a pesar de ulimits altos.

# NGINX ejemplo (extracto)
worker_processes auto;
eventos {
    worker_connections 40960;
    multi_accept on;
    use epoll;
}
worker_rlimit_nofile 131072;

Con Apache (evento MPM) presto atención a ServerLimit, ThreadsPerChild y MaxRequestWorkers. Si el número total de conexiones posibles aumenta, nofile debe crecer en paralelo. De lo contrario, las colas se llenan aunque la CPU y la RAM aún tengan espacio de sobra. También ajusto los listen backlogs (por ejemplo, para NGINX: listen ... backlog=...) y kernel-somaxconn para que no se descarten nuevas aceptaciones.

Bases de datos y cachés: presupuesto abrir archivos correctamente

Las bases de datos y las cachés tienen sus propios tornillos de ajuste: Utilice MySQL/MariaDB limite_archivos_abiertos y los parámetros de conexión, PostgreSQL se beneficia de la agrupación de conexiones de antemano, mientras que Redis traduce el número de clientes directamente en FD abiertos. Me aseguro de que los servicios respectivos encuentren un nofile que esté por encima de sus valores máximos internos. De lo contrario, el arranque o los picos de carga fallarán aunque se haya escalado la capa de aplicación.

Un patrón típico: PHP-FPM aumenta el paralelismo, pero el servidor DB permanece en los antiguos límites FD y topes de conexión. Mido los handles abiertos por componente y añado los buffers. Esto evita que un servicio aguas abajo neutralice el rendimiento general.

Contenedores y orquestación: límites en el contexto de Docker/Kubernetes

Los límites funcionan en los contenedores independientemente del contexto de inicio de sesión del host. Los establezco explícitamente en el arranque o en la orquestación y también observo los límites de los cgroups (PIDs, memoria). En el entorno Docker, defino nofile/nproc y opcionalmente un límite de PIDs. Kubernetes encapsula esto a través de opciones específicas de SecurityContext y RuntimeClass; dependiendo del entorno, Ulimits debe establecerse a través de Container Runtime.

# Docker local
docker run --ulimit nofile=131072:131072 \
           --ulimit nproc=8192:8192 \
           --pids-limit 20000 \
           --name webapp -p 80:80 myimage:latest

# Docker Compose (extracto)
services:
  app:
    image: myimage:latest
    ulimits:
      nofile:
        soft: 65536
        duro: 131072
      nproc: 8192
    pids_limit: 20000

Siempre verifico los límites en el contenedor a través de /proc/self/limits y me aseguro de que las personalizaciones del host, como limits.conf, no se difundan automáticamente en los procesos del contenedor. Creo transparencia con parámetros de despliegue claros y controlados por versiones para cada servicio.

Solución de problemas en la práctica: EMFILE, EAGAIN y spawns lentos

Para realizar análisis reproducibles, utilizo strace y busco EMFILE („Demasiados archivos abiertos“) o EAGAIN („Recurso temporalmente no disponible“) para accept(), open(), pipe() o clone(). Cuento regularmente los FD por proceso y los comparo con los límites establecidos. Las fugas en los manejadores de archivos (por ejemplo, llamadas a Close() olvidadas) pueden reconocerse más rápidamente de esta manera.

# Determinar los FDs abiertos por proceso
ls -l /proc//fd | wc -l

# Uso de todo el sistema de un vistazo
cat /proc/sys/fs/file-nr

# recortar strace para errores FD
strace -fp  -e trace=desc,process,network 2>&1 | grep -E 'EMFILE|EAGAIN'

Los problemas de arranque causados por límites de nproc demasiado ajustados se revelan por un arranque lento, mensajes de „no se puede bifurcar“ o grupos de trabajadores incompletos. Correlaciono estos eventos con las estrategias de spawn (prefork, dinámica, bajo demanda) para que los ajustes no solo alivien los síntomas, sino que también respalden la arquitectura.

Automatización, pruebas y desmantelamiento

Mantengo los cambios de límites reproducibles: mantengo drop-ins para systemd, archivos sysctl.d y plantillas de servicio declarativamente. Cada cambio recibe un ticket, valores medidos antes/después y una clara reversión. En la puesta en escena, simulo la utilización con herramientas como wrk, vegeta o k6 y presto atención a las latencias P95/P99, las tasas de error y los tiempos de espera. Sólo unos resultados fiables justifican la ampliación a producción.

# Crear andamiaje drop-in para múltiples servicios
for s in nginx php-fpm redis; do
  mkdir -p /etc/systemd/system/$s.service.d
  cat < /etc/systemd/system/$s.service.d/limits.conf
[Service]
LimitNOFILE=65536
LimitNPROC=4096
TareasMáx=8192
EOF
hecho
systemctl daemon-reload
systemctl restart nginx php-fpm redis

Para las campañas, cambio los límites de forma controlada, anoto la hora de inicio/fin y los comparo con las curvas de tráfico. Tras el pico, vuelvo a introducir los valores más conservadores para minimizar la superficie de ataque y liberar recursos del núcleo no utilizados.

Riesgo de confusión: límites máximos frente a parámetros de vigilancia/núcleo

No todos los errores de „demasiados archivos“ son causados por nofile. Los vigilantes del sistema de archivos (inotify) tienen sus propios límites (por ejemplo, max_user_watches), que se alcanzan rápidamente con muchos archivos pequeños o pilas de desarrollo. vm.max_map_count (por ejemplo, para buscadores) o net.ip_local_port_range (puertos efímeros) también pueden actuar como factores limitantes. Compruebo estos parámetros por separado para no girar el mando equivocado.

Dimensionar PHP-FPM correctamente: Procesos, colas, límites

Con PHP-FPM, coordino pm.max_children, pm.max_requests y los límites ulimit para que el inicio del proceso, memoria y Conexiones permanecen equilibradas. Cuando FPM alcanza su límite superior, las peticiones terminan en una cola; esto es intencional, pero sólo tiene sentido si el servidor web maneja los tiempos de espera y backoff correctamente. Mido el tiempo medio de ejecución y lo utilizo para derivar un número de proceso viable que no sature la CPU y la RAM. También ajusto el límite del descriptor de archivo para que las conexiones paralelas y los escritores de registros tengan suficiente espacio para maniobrar. Si quieres profundizar, encontrarás prácticos tornillos de ajuste para Procesos PHP-FPM y determina la mejor Saldo.

También compruebo cuántas conexiones de base de datos por trabajador FPM permanecen abiertas al mismo tiempo, para que los pools de conexiones no se conviertan en el ojo de aguja se convierten. Un número demasiado grande de trabajadores aumenta la presión de RAM y los cambios de contexto, uno demasiado pequeño estanca el rendimiento. Por eso escalo por etapas, observo la latencia P50/P95 y los fallos, y ajusto en pequeños pasos. Sólo cuando los tiempos de espera, la carga de la CPU y las tasas de error están equilibrados, fijo los valores de forma permanente. De este modo, la pila funciona de forma más predecible y se mantiene estable bajo carga. receptivo.

Supervisión y planificación de la capacidad

Hago una copia de seguridad de cada paso con datos de medición, de lo contrario los cambios en los límites sólo tienen un fieltro. Métricas como los archivos abiertos por proceso, las solicitudes en ejecución y en espera, los segundos de CPU por trabajador y la memoria RSS me ayudan a clasificarlos. Los registros me muestran cuándo entran en vigor los límites duros y si los servicios rechazan conexiones como consecuencia de ello. Los cuadros de mando con latencias P95/P99 revelan cuellos de botella que ocultan los valores medios. De todo ello deduzco un alojamiento práctico de los límites de proceso que suaviza la utilización y reduce las colas. acortado.

Siempre mantengo libre el espacio libre reservado para que los picos cortos no causen interferencias. producir. En caso de picos mensuales o de campaña, aumento los límites con una o dos semanas de antelación y realizo pruebas de tráfico real. A continuación, reactivo los límites más estrictos para minimizar los recursos y las superficies de ataque. Este ritmo protege económicamente la plataforma y reduce al mismo tiempo el riesgo de perturbaciones. La planificación vale la pena varias veces, porque las medidas proactivas pueden minimizar las ventanas de servicio y Tiempo de actividad Asegúrese de que

Inodos y número de archivos: límites silenciosos con un gran efecto

Además de nofile, el sistema de archivos limita el número de Inodos y, por tanto, el número posible de archivos, independientemente de la memoria utilizada. Los proyectos web con muchos archivos de caché pequeños o archivos de sesión se topan rápidamente con un obstáculo. Compruebo df -i, limpio artefactos antiguos, restos de rotación y directorios temporales y ajusto la estructura del sistema de archivos si es necesario. Consolidar las cachés CMS o colocarlas en memoria alivia la carga de los inodos y la impresión IO al mismo tiempo. Incluyo detalles, información de fondo y estrategias en mi guía de Entender los inodos que ha desarrollado el tema de las prácticas de acogida desbloquea.

Si los inodos son escasos, un límite de descriptor de archivo más alto es útil por sí solo nada. Por lo tanto, aseguro una rotación clara de los registros, limito la verbosidad de la depuración y muevo los artefactos raramente utilizados al almacenamiento de archivos. Los procesos de compilación también deberían ordenar los artefactos para que los despliegues no consuman gradualmente las reservas de inodos. Esta higiene mantiene los límites estables a largo plazo y ahorra mucho tiempo a la hora de solucionar problemas. Una visión limpia de los inodos evita errores inesperados. Tiempos de inactividad.

Rectificación selectiva de mensajes de error típicos

El mensaje „demasiados archivos abiertos“ casi siempre indica que no hay suficientes archivos. sin archivo. Aumento el límite temporalmente en el shell, confirmo el efecto y luego ajusto los valores en limits.conf y systemd. Si aparece „recurso temporalmente no disponible“ al generarse, a menudo se debe al límite nproc, que aumento para ajustarlo a la arquitectura del trabajador. Si los scripts PHP parecen colgarse, también compruebo memory_limit, max_execution_time y los segundos de CPU concedidos por la configuración del alojamiento para CGI/FPM. Elimino los cuellos de botella a lo largo de la cadena y evito que un cambio en un lugar sólo genere nuevas Frenos generado en otra posición.

Si estos errores se producen esporádicamente, trabajo con correlaciones métricas para determinar la situación de tiempo y carga. captura. Los picos de conexiones simultáneas, el aumento de los errores de backend o las largas búsquedas DNS son buenos indicios. A continuación, compruebo los límites de los servicios afectados por separado para identificar los valores efectivos. Si la configuración es correcta pero los errores persisten, busco fugas en los gestores de archivos, vigilantes defectuosos o sockets abiertos innecesarios. La limitación paso a paso ahorra tiempo y reduce el Riesgo nuevos fracasos.

Un equilibrio inteligente entre rendimiento y seguridad

Nunca aumento los límites sin límites, porque las aperturas demasiado amplias se prestan al ataque. ampliar. Los escenarios de fuerza bruta o DoS se benefician de límites demasiado altos si no se aplican otros controles. Por eso combino los límites con la limitación de velocidad, las estrategias de backoff y los tiempos de espera claros en el servidor web y en el upstream. Establezco límites máximos estrictos para que se produzcan picos legítimos, pero el abuso no pueda escalar. Así es como garantizo la disponibilidad sin poner en peligro el servicio. Controlar perder.

En la vida cotidiana, un concepto graduado da sus frutos: cierto margen para los picos, efecto mensurable y regularidad. Reseñas. Si conoces los despliegues, las campañas de tráfico y las cargas estacionales, puedes planificar los límites de forma proactiva. Documento cada cambio con la fecha, el motivo y los valores medidos para que los análisis posteriores no se queden a oscuras. Este catálogo agiliza las decisiones futuras y evita la duplicación del trabajo. El rendimiento y la seguridad se benefician porque las decisiones se basan en Datos con base.

Evaluación de paquetes de alojamiento: ¿en qué me fijo?

Compruebo las ofertas de alojamiento no sólo por CPU y RAM, sino explícitamente por Ulimits para procesos, descriptores y segundos de CPU. Detalles específicos sobre nproc, nofile y, si procede, cuotas de inodos me ayudan a estimar correctamente la capacidad. Para tiendas y APIs, requiero compromisos transparentes para procesos PHP FPM, presupuestos de CPU y aumentos de límites a petición. Los entornos VPS o dedicados me dan soberanía, pero los valores por defecto sensatos para el funcionamiento también cuentan aquí. Unas cifras claras evitan decepciones y mantienen el rumbo de las migraciones sencillo.

Plan	Límite de proceso (nproc)	Archivos (nofile)	RAM/Proceso	tiempo de CPU	Idoneidad
Principiante	32-64	4096-8192	256-512 MB	5-600 s	Sitios pequeños
Negocios	64-128	16384-65536	512-1024 MB	600-3600 s	Tiendas, API
VPS/Dedicado	Configurable	Configurable	Según las necesidades	Según las necesidades	Carga elevada

Brevemente resumido

Primero mido la utilización real y luego levanto Límites por etapas y comprobar el efecto sobre la latencia, la tasa de errores y el rendimiento. Los interruptores principales son nofile para archivos/sockets y nproc para procesos/hilos, complementados por fsize, stack y cpu. Establezco valores permanentes de forma consistente en limits.conf y en las unidades systemd para que los servicios tengan condiciones marco idénticas. Para PHP-FPM, sincronizo estrechamente el número de procesos, memoria y colas con el límite del descriptor de fichero. Monitorización, higiene de inodos y límites superiores sensatos mantienen las configuraciones de hosting bajo carga Fiable y sensible.