{"id":16053,"date":"2025-12-20T11:51:36","date_gmt":"2025-12-20T10:51:36","guid":{"rendered":"https:\/\/webhosting.de\/php-fpm-prozess-management-pm-max-children-optimieren-core\/"},"modified":"2025-12-20T11:51:36","modified_gmt":"2025-12-20T10:51:36","slug":"php-fpm-gestion-de-procesos-pm-max-children-optimizar-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/php-fpm-prozess-management-pm-max-children-optimieren-core\/","title":{"rendered":"Configurar correctamente la gesti\u00f3n de procesos PHP-FPM: explicaci\u00f3n de pm.max_children y otros par\u00e1metros"},"content":{"rendered":"<p><strong>Ajuste de php-fpm<\/strong> decide cu\u00e1ntos procesos PHP-FPM pueden ejecutarse simult\u00e1neamente, la velocidad a la que se inician los nuevos procesos y el tiempo que tardan en atender las solicitudes. Te mostrar\u00e9 c\u00f3mo <strong>pm.max_hijos<\/strong>, pm, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers y pm.max_requests de manera que tu aplicaci\u00f3n responda r\u00e1pidamente bajo carga y el servidor no entre en modo de intercambio.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>modo pm<\/strong>: elige correctamente entre est\u00e1tico, din\u00e1mico o bajo demanda para que los procesos est\u00e9n disponibles seg\u00fan tu tr\u00e1fico.<\/li>\n  <li><strong>pm.max_hijos<\/strong>: Alinear el n\u00famero de procesos PHP simult\u00e1neos en la RAM con el consumo real de procesos.<\/li>\n  <li><strong>Valores iniciales\/de reserva<\/strong>: equilibrar adecuadamente pm.start_servers, pm.min_spare_servers y pm.max_spare_servers.<\/li>\n  <li><strong>reciclaje<\/strong>: Mit pm.max_requests Speicherlecks abfedern, ohne unn\u00f6tigen Overhead zu erzeugen.<\/li>\n  <li><strong>Monitoreo<\/strong>: Mant\u00e9n un ojo en los registros, el estado y la RAM, y luego reajusta paso a paso.<\/li>\n<\/ul>\n\n<h2>Por qu\u00e9 es importante la gesti\u00f3n de procesos<\/h2>\n\n<p>Yo contribuyo con <strong>PHP-FPM<\/strong> la ejecuci\u00f3n de cada script PHP como un proceso independiente, y cada solicitud paralela necesita su propio trabajador. Sin los l\u00edmites adecuados, las solicitudes se bloquean en colas, lo que provoca <strong>Tiempos muertos<\/strong> y errores. Si establezco l\u00edmites m\u00e1ximos demasiado altos, el grupo de procesos consume toda la memoria y el n\u00facleo comienza a <strong>intercambiar<\/strong>. Este equilibrio no es una cuesti\u00f3n de adivinanzas: me baso en valores medidos reales y mantengo un margen de seguridad. De este modo, la latencia se mantiene baja y el rendimiento estable, incluso cuando la carga var\u00eda.<\/p>\n\n<p>Para m\u00ed es importante una clara <strong>objetivo<\/strong>: \u00bfCu\u00e1ntas ejecuciones PHP simult\u00e1neas quiero permitir sin agotar la RAM? Al mismo tiempo, compruebo si los cuellos de botella se producen m\u00e1s bien en la <strong>Base de datos<\/strong>, en API externas o en el servidor web. Solo cuando conozco el cuello de botella, selecciono los valores correctos para pm, pm.max_children y similares. Empiezo de forma conservadora, mido y luego aumento gradualmente. De esta manera evito reinicios bruscos y fallos inesperados.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-fpm-serveradmin-4912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Los tres modos pm: static, dynamic, ondemand<\/h2>\n\n<p>El modo <strong>est\u00e1tico<\/strong> siempre mantiene exactamente pm.max_children procesos disponibles. Esto proporciona latencias muy predecibles, ya que no es necesario ning\u00fan proceso de inicio. Utilizo static cuando la carga es muy uniforme y hay suficiente RAM disponible. Sin embargo, cuando la demanda var\u00eda, con static desperdicio f\u00e1cilmente <strong>Memoria<\/strong>. Por eso utilizo static espec\u00edficamente donde necesito una ejecuci\u00f3n constante.<\/p>\n\n<p>Con <strong>din\u00e1mico<\/strong> Inicio una cantidad inicial y dejo que el tama\u00f1o del grupo oscile entre min_spare y max_spare. Este modo es adecuado para el tr\u00e1fico con picos, ya que los trabajadores se crean y se eliminan seg\u00fan sea necesario. Siempre mantengo suficientes procesos inactivos para absorber los picos sin tiempo de espera. Sin embargo, demasiados trabajadores inactivos consumen recursos innecesariamente. <strong>RAM<\/strong>, por lo que mantengo un margen de ahorro reducido. De este modo, la piscina se mantiene flexible sin hincharse.<\/p>\n\n<p>En el modo <strong>a la carta<\/strong> Al principio no hay trabajadores, PHP-FPM solo los inicia cuando hay solicitudes. Esto ahorra memoria en los periodos de inactividad, pero el primer acceso tiene un ligero retraso. Yo elijo ondemand para pools que se usan poco, herramientas de administraci\u00f3n o puntos finales cron. Para sitios web muy visitados, ondemand suele ofrecer peores tiempos de respuesta. En esos casos, prefiero claramente dynamic con valores de reserva bien configurados.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_konfiguration_9542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionar correctamente pm.max_children<\/h2>\n\n<p>Creo que <strong>pm.max_hijos<\/strong> de la RAM disponible para PHP y la memoria media por trabajador. Para ello, primero reservo memoria para el sistema, el servidor web, la base de datos y las cach\u00e9s, para que el sistema no entre en <strong>Subcontrataci\u00f3n<\/strong> funciona. Divido la RAM restante por el consumo real medido del proceso. De la teor\u00eda, resto un margen de seguridad de 20-30 % para compensar los valores at\u00edpicos y los picos de carga. Utilizo el resultado como valor inicial y luego observo el efecto.<\/p>\n\n<p>Calculo el consumo medio del proceso con herramientas como <strong>P.D.<\/strong>, top o htop y miro RSS\/RES. Importante: mido bajo una carga t\u00edpica, no en reposo. Si cargo muchos plugins, frameworks o bibliotecas grandes, el consumo por trabajador aumenta notablemente. Adem\u00e1s, la CPU limita la curva: m\u00e1s procesos no ayudan si una <strong>Hilo \u00fanico<\/strong>-Rendimiento de la CPU limitado por solicitud. Si desea profundizar en las caracter\u00edsticas de la CPU, encontrar\u00e1 informaci\u00f3n sobre <a href=\"https:\/\/webhosting.de\/es\/php-single-thread-performance-wordpress-hosting-velocity\/\">Rendimiento de un solo subproceso<\/a>.<\/p>\n\n<p>Mantengo mis suposiciones transparentes: \u00bfCu\u00e1nta RAM tiene realmente disponible PHP? \u00bfQu\u00e9 tama\u00f1o tiene un trabajador en solicitudes t\u00edpicas? \u00bfQu\u00e9 picos se producen? Si las respuestas son correctas, establezco pm.max_children, realizo una recarga suave y compruebo la RAM, los tiempos de respuesta y las tasas de error. Solo entonces sigo subiendo o bajando poco a poco.<\/p>\n\n<h2>Valores orientativos seg\u00fan el tama\u00f1o del servidor<\/h2>\n\n<p>La siguiente tabla me da <strong>Valores iniciales<\/strong> a mano. No sustituye a las mediciones, pero proporciona una orientaci\u00f3n s\u00f3lida para los ajustes iniciales. Adapto los valores a cada aplicaci\u00f3n y los compruebo mediante supervisi\u00f3n. Si quedan reservas sin utilizar, las aumento con cautela. Si el servidor alcanza el l\u00edmite de RAM, reduzco los valores.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>RAM del servidor<\/strong><\/th>\n      <th><strong>RAM para PHP<\/strong><\/th>\n      <th><strong>\u00d8 MB\/trabajador<\/strong><\/th>\n      <th><strong>pm.max_hijos<\/strong> (Inicio)<\/th>\n      <th><strong>Utilice<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>1-2 GB<\/td>\n      <td>~1 GB<\/td>\n      <td>50-60<\/td>\n      <td>15-20<\/td>\n      <td>Sitios peque\u00f1os, blogs<\/td>\n    <\/tr>\n    <tr>\n      <td>4-8 GB<\/td>\n      <td>~4-6 GB<\/td>\n      <td>60-80<\/td>\n      <td>30-80<\/td>\n      <td>Negocios, peque\u00f1as tiendas<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e1s de 16 GB<\/td>\n      <td>~10-12 GB<\/td>\n      <td>70-90<\/td>\n      <td>100-160<\/td>\n      <td>Alta carga, API, tiendas<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Leo la tabla de derecha a izquierda: \u00bfEncaja el <strong>Utilice<\/strong> Para el proyecto, compruebo si la RAM est\u00e1 reservada de forma realista para PHP. A continuaci\u00f3n, selecciono un tama\u00f1o de trabajador que se adapte a la base de c\u00f3digo y a las extensiones. Despu\u00e9s, configuro pm.max_children y observo el efecto en el funcionamiento en vivo. La tasa de acierto y la estabilidad aumentan cuando documento estos pasos de forma clara.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/php-fpm-prozessmanagement-5124.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurar los valores de inicio, reserva y solicitudes<\/h2>\n\n<p>Con <strong>pm.iniciar_servidores<\/strong> Determino cu\u00e1ntos procesos est\u00e1n disponibles de inmediato. Si el n\u00famero es demasiado bajo, se producen arranques en fr\u00edo bajo carga; si es demasiado alto, se ocupa RAM innecesariamente. A menudo me baso en 15-30 % de pm.max_children y redondeo si la carga comienza de forma m\u00e1s bien tranquila. En los picos de tr\u00e1fico, elijo una cantidad inicial algo mayor para que las solicitudes no se acumulen antes de que haya suficientes trabajadores esperando. Este ajuste fino reduce significativamente el tiempo de respuesta inicial.<\/p>\n\n<p>Los valores <strong>pm.min_servidores_de_repuesto<\/strong> y pm.max_spare_servers definen el intervalo de inactividad. Mantengo tantos trabajadores libres como para que las nuevas solicitudes puedan acceder directamente, pero no tantos como para que los procesos inactivos desperdicien memoria. En las tiendas, me gusta establecer un intervalo m\u00e1s estrecho para suavizar los picos. Con <strong>pm.max_requests<\/strong> Reciclo los procesos despu\u00e9s de unos cientos de solicitudes para limitar la deriva de memoria. Para aplicaciones discretas, elijo entre 500 y 800, pero si sospecho que hay fugas, deliberadamente elijo un n\u00famero m\u00e1s bajo.<\/p>\n\n<h2>Supervisi\u00f3n y resoluci\u00f3n de problemas<\/h2>\n\n<p>Compruebo regularmente <strong>Registros<\/strong>, p\u00e1ginas de estado y RAM. Las advertencias sobre los l\u00edmites alcanzados de pm.max_children son para m\u00ed una se\u00f1al clara de que hay que aumentar el l\u00edmite m\u00e1ximo u optimizar el c\u00f3digo\/la base de datos. Si se acumulan los errores 502\/504, consulto los registros del servidor web y las colas. Las fluctuaciones significativas en la latencia indican que hay muy pocos procesos, que hay bloqueos de E\/S o que los costes de los procesos son demasiado elevados. Primero miro los datos concretos y luego reacciono con peque\u00f1os pasos, nunca con saltos XXL.<\/p>\n\n<p>Reconozco los cuellos de botella m\u00e1s r\u00e1pidamente cuando utilizo la <strong>Tiempos de espera<\/strong> Mido a lo largo de toda la cadena: servidor web, PHP-FPM, base de datos, servicios externos. Si el tiempo de backend solo aumenta en determinadas rutas, a\u00edslo las causas mediante perfiles. Si se producen tiempos de espera en todas partes, me centro en el tama\u00f1o del servidor y del pool. Tambi\u00e9n es \u00fatil echar un vistazo a las colas de trabajadores y a los procesos en estado D. Solo cuando entiendo la situaci\u00f3n, cambio los l\u00edmites y documento cada cambio de forma clara.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_nachtarbeit_tech5982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interacci\u00f3n entre el servidor web y PHP-FPM<\/h2>\n\n<p>Me aseguro de que <strong>Servidor web<\/strong>Los l\u00edmites y PHP-FPM armonizan. Demasiadas conexiones simult\u00e1neas en el servidor web con muy pocos trabajadores provocan colas y tiempos de espera. Si se aumenta el n\u00famero de trabajadores, pero el servidor web limita la aceptaci\u00f3n, el rendimiento se ve afectado. Par\u00e1metros como worker_connections, event-Loop y Keep-Alive afectan directamente a la carga de PHP. Las siguientes indicaciones proporcionan una introducci\u00f3n pr\u00e1ctica al ajuste fino: <a href=\"https:\/\/webhosting.de\/es\/threadpool-servidor-web-apache-nginx-litespeed-optimizacion-configuracion\/\">Pools de subprocesos en el servidor web<\/a>.<\/p>\n\n<p>Me quedo con <strong>Keep-Alive<\/strong>-Ventana de tiempo a la vista, para que las conexiones inactivas no bloqueen innecesariamente a los trabajadores. Para los activos est\u00e1ticos, utilizo un almacenamiento en cach\u00e9 agresivo antes de PHP para mantener la carga de trabajo alejada del grupo. Las cach\u00e9s de proxy inverso tambi\u00e9n ayudan cuando se recuperan con frecuencia respuestas id\u00e9nticas. De este modo, puedo mantener pm.max_children m\u00e1s bajo y, aun as\u00ed, entregar m\u00e1s r\u00e1pido. Menos trabajo por solicitud suele ser el ajuste m\u00e1s eficaz.<\/p>\n\n<h2>Ajustes precisos en php-fpm.conf<\/h2>\n\n<p>Voy m\u00e1s all\u00e1 de los valores fundamentales y ajusto los <strong>Par\u00e1metros de la piscina<\/strong> Bien. Con <strong>pm.max_spawn_rate<\/strong> Limito la velocidad a la que se pueden crear nuevos trabajadores para que el servidor no inicie procesos de forma demasiado agresiva durante los picos de carga y entre en un estado de sobrecarga de la CPU. Para ondemand, establezco con <strong>pm.process_idle_timeout<\/strong> fijo, ya que los trabajadores no utilizados desaparecen r\u00e1pidamente: si es demasiado corto, se genera una sobrecarga de inicio; si es demasiado largo, se ocupa RAM. En el caso de <strong>escuchar<\/strong>-Socket, elijo entre Unix-Socket y TCP. Un Unix-Socket ahorra sobrecarga y ofrece una asignaci\u00f3n de derechos clara a trav\u00e9s de <em>listen.owner<\/em>, <em>listen.group<\/em> y <em>modoescuchar<\/em>. Para ambas variantes, utilizo <strong>lista.atraso<\/strong> suficientemente alto para que las r\u00e1fagas entrantes lleguen al b\u00fafer del n\u00facleo en lugar de ser rechazadas inmediatamente. Con <strong>rlimit_files<\/strong> Si es necesario, aumento el n\u00famero de archivos abiertos por trabajador, lo que aporta estabilidad cuando hay muchas descargas y cargas simult\u00e1neas. Y si hay que establecer prioridades, utilizo <strong>prioridad del proceso<\/strong>, para dar un tratamiento algo secundario a los grupos poco cr\u00edticos en lo que respecta a la CPU.<\/p>\n\n<h2>Slowlog y protecci\u00f3n contra bloqueos<\/h2>\n\n<p>Para hacer visibles las solicitudes lentas, activo el <strong>Slowlog<\/strong>. Con <strong>request_slowlog_timeout<\/strong> defino el umbral (por ejemplo, 2-3 s) a partir del cual un stack trace se env\u00eda al <strong>slowlog<\/strong> . As\u00ed encuentro bloqueos de E\/S, bucles costosos o bloqueos inesperados. Contra los verdaderos bloqueos utilizo <strong>request_terminate_timeout<\/strong>, que se interrumpe bruscamente cuando una solicitud tarda demasiado en ejecutarse. Considero que estos intervalos de tiempo son coherentes con <em>tiempo_de_ejecuci\u00f3n_m\u00e1ximo<\/em> de PHP y los tiempos de espera del servidor web, para que ninguna capa se interrumpa antes que otra. En la pr\u00e1ctica, empiezo de forma conservadora, analizo los registros de lentitud bajo carga y ajusto los umbrales gradualmente hasta que las se\u00f1ales sean significativas, sin saturar el registro.<\/p>\n\n<h2>Opcache, memory_limit y su influencia en el tama\u00f1o de los trabajadores<\/h2>\n\n<p>Me refiero al <strong>Opcache<\/strong> en mi planificaci\u00f3n de RAM. Su \u00e1rea de memoria compartida no se cuenta por trabajador, sino que es utilizada conjuntamente por todos los procesos. Tama\u00f1o y fragmentaci\u00f3n (<em>opcache.consumo_memoria<\/em>, <em>interned_strings_buffer<\/em>) influyen considerablemente en el tiempo de calentamiento y en la tasa de aciertos. Un Opcache bien dimensionado reduce la presi\u00f3n sobre la CPU y la RAM por cada solicitud, ya que se recompila menos c\u00f3digo. Al mismo tiempo, observo que <strong>l\u00edmite_de_memoria<\/strong>: Un valor alto protege contra la falta de memoria en casos individuales, pero aumenta el presupuesto te\u00f3rico en el peor de los casos por trabajador. Por lo tanto, planifico con un promedio medido m\u00e1s un margen, no con el memory_limit puro. Funciones como la precarga o JIT aumentan los requisitos de memoria; las pruebo espec\u00edficamente e incluyo el consumo adicional en el c\u00e1lculo de pm.max_children.<\/p>\n\n<h2>Separar y priorizar grupos<\/h2>\n\n<p>Dividir aplicaciones en <strong>varias piscinas<\/strong> cuando los perfiles de carga difieren considerablemente. Un grupo para el tr\u00e1fico frontend, otro para admin\/backend y un tercero para cron\/uploads: as\u00ed a\u00edslo los picos y asigno l\u00edmites diferenciados. Para los puntos finales poco frecuentados, establezco <em>a la carta<\/em> con un tiempo de espera inactivo reducido, para el frontend <em>din\u00e1mico<\/em> con un margen de ahorro reducido. Acerca de <strong>usuario\/grupo<\/strong> y, si procede,. <em>chroot<\/em> Me encargo de que el aislamiento sea limpio, mientras que los derechos de socket regulan qu\u00e9 proceso del servidor web puede acceder. Cuando hay que establecer prioridades, el frontend recibe m\u00e1s. <em>pm.max_hijos<\/em> y, si procede, una neutral <em>prioridad del proceso<\/em>, mientras que Cron\/Reports se ejecuta con un presupuesto menor y una prioridad m\u00e1s baja. De este modo, la interfaz de usuario sigue siendo receptiva, incluso cuando se est\u00e1n ejecutando tareas pesadas en segundo plano.<\/p>\n\n<h2>Utilizar correctamente los puntos finales de estado<\/h2>\n\n<p>Para el diagn\u00f3stico de tiempo de ejecuci\u00f3n, activo <strong>pm.status_path<\/strong> y opcionalmente <strong>ping.path<\/strong> por grupo. En el estado veo trabajadores activos\/inactivos que <em>Cola de listas<\/em>, contadores basados en el rendimiento y m\u00e9tricas de solicitudes lentas. Una cola de listas en constante crecimiento o trabajadores inactivos constantemente son se\u00f1ales de alarma para m\u00ed. Protejo estos puntos finales detr\u00e1s de Auth y una red interna para que ning\u00fan detalle operativo se filtre al exterior. Adem\u00e1s, activo <strong>captura_salida_trabajadores<\/strong>, si quiero recopilar r\u00e1pidamente stdout\/stderr de los trabajadores, por ejemplo, en caso de errores dif\u00edciles de reproducir. Combino estas se\u00f1ales con m\u00e9tricas del sistema (RAM, CPU, E\/S) para decidir si aumento pm.max_children, actualizo los valores de reserva o intervengo en la aplicaci\u00f3n.<\/p>\n\n<h2>Caracter\u00edsticas especiales en contenedores y m\u00e1quinas virtuales<\/h2>\n\n<p>En <strong>reciclaje de comida<\/strong> y m\u00e1quinas virtuales peque\u00f1as, tengo en cuenta los l\u00edmites de cgroup y el peligro del OOM-Killer. Establezco pm.max_children estrictamente seg\u00fan el <em>L\u00edmite de memoria del contenedor<\/em> y compruebo los picos de carga para que no se cierre ning\u00fan trabajador. Sin intercambio en contenedores, el margen de seguridad es especialmente importante. En el caso de las cuotas de CPU, escalo el n\u00famero de trabajadores al n\u00famero de vCPU disponibles: si la aplicaci\u00f3n est\u00e1 limitada por la CPU, un mayor paralelismo genera m\u00e1s colas que rendimiento. Las cargas de trabajo limitadas por E\/S admiten m\u00e1s procesos, siempre que el presupuesto de RAM lo permita. Adem\u00e1s, establezco <strong>umbral_de_reinicio_de_emergencia<\/strong> y <strong>intervalo_de_reinicio_de_emergencia<\/strong> para el proceso maestro, con el fin de evitar una espiral de fallos en caso de que un error poco frecuente afecte a varios hijos en poco tiempo. De este modo, el servicio sigue estando disponible mientras analizo la causa.<\/p>\n\n<h2>Implementaciones y recargas fluidas sin interrupciones<\/h2>\n\n<p>Estoy planeando <strong>Recargas<\/strong> de modo que las solicitudes en curso se completen correctamente. Un <em>recarga elegante<\/em> (por ejemplo, mediante systemd reload) aplica las nuevas configuraciones sin cerrar las conexiones abiertas. Mantengo estable la ruta del socket para que el servidor web no detecte ninguna interrupci\u00f3n de la conexi\u00f3n. En los cambios de versi\u00f3n que invalidan gran parte de Opcache, precargo la cach\u00e9 (solicitudes de precarga\/calentamiento) para limitar los picos de latencia inmediatamente despu\u00e9s de la implementaci\u00f3n. Las modificaciones importantes las pruebo primero en un grupo m\u00e1s peque\u00f1o o en una instancia Canary con una configuraci\u00f3n id\u00e9ntica antes de implementar los valores a gran escala. Cada ajuste se registra en mi registro de cambios con una marca de tiempo y capturas de pantalla de las m\u00e9tricas, lo que acorta la b\u00fasqueda de errores en caso de que se produzcan efectos secundarios inesperados.<\/p>\n\n<h2>Comportamiento de r\u00e1fagas y colas<\/h2>\n\n<p>Compenso los picos de carga con un <strong>Dise\u00f1o de colas<\/strong> ab. Yo apuesto por <strong>lista.atraso<\/strong> tan alto que el n\u00facleo puede almacenar temporalmente m\u00e1s intentos de conexi\u00f3n. En el lado del servidor web, limito el n\u00famero m\u00e1ximo de conexiones FastCGI simult\u00e1neas por grupo para que no superen <em>pm.max_hijos<\/em> encaja. De este modo, los picos se acumulan preferiblemente en el servidor web (m\u00e1s econ\u00f3mico) que en PHP (m\u00e1s caro). Mido la <em>Cola de listas<\/em> En el estado FPM: si aumenta regularmente, aumento el n\u00famero de trabajadores, optimizo las tasas de aciertos de la cach\u00e9 o reduzco los valores agresivos de Keep-Alive. El objetivo es, en los picos, el <em>Tiempo hasta el primer byte<\/em> mantener estable, en lugar de dejar que las solicitudes se pierdan en colas interminables.<\/p>\n\n<h2>Flujo de trabajo pr\u00e1ctico para ajustes<\/h2>\n\n<p>Empiezo con un <strong>Auditor\u00eda<\/strong>: presupuesto de RAM, tama\u00f1o del proceso, perfiles de E\/S. A continuaci\u00f3n, establezco valores iniciales conservadores para pm.max_children y el modo pm. Despu\u00e9s, realizo pruebas de carga u observo los picos de tiempo reales. Registro todos los cambios, incluidas las m\u00e9tricas y los intervalos de tiempo. Despu\u00e9s de cada ajuste, compruebo la RAM, la latencia P50\/P95 y las tasas de error; solo entonces paso al siguiente paso.<\/p>\n\n<p>Cuando me encuentro repetidamente al l\u00edmite, no escalo inmediatamente la situaci\u00f3n. <strong>Trabajador<\/strong>-N\u00famero. Primero optimizo las consultas, las tasas de aciertos de la cach\u00e9 y las funciones costosas. Traslado las tareas con gran carga de E\/S a colas y acorto las rutas de respuesta. Solo cuando la aplicaci\u00f3n funciona de manera eficiente, aumento el tama\u00f1o del grupo. Este proceso ahorra recursos y evita da\u00f1os consecuentes en otros lugares.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm_schreibtisch_7321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escenarios t\u00edpicos: valores de ejemplo<\/h2>\n\n<p>En un servidor virtual de 2 GB, reservo aproximadamente <strong>1 GB<\/strong> para PHP-FPM y establezco un consumo de trabajadores de entre 50 y 60 MB. Para ello, empiezo con pm.max_children en torno a 15-20 y utilizo dynamic con una cantidad inicial peque\u00f1a. Mantengo min_spare en 2-3 y max_spare en 5-6. Establezco pm.max_requests en 500 para que los procesos se intercambien regularmente. Estos ajustes proporcionan tiempos de respuesta estables para proyectos peque\u00f1os.<\/p>\n\n<p>Con 8 GB de RAM, suelo planificar entre 4 y 6 GB para <strong>PHP<\/strong> y establezco tama\u00f1os de trabajadores de 60-80 MB. Esto da como resultado un rango inicial de 30-80 procesos secundarios. pm.start_servers se sit\u00faa entre 15 y 20, min_spare entre 10 y 15, y max_spare entre 25 y 30. pm.max_requests lo selecciono entre 500 y 800. Bajo carga, compruebo si el pico de RAM deja margen y, a continuaci\u00f3n, lo aumento con precauci\u00f3n.<\/p>\n\n<p>En configuraciones de alta carga con m\u00e1s de 16 GB de RAM, reservo entre 10 y 12 GB para <strong>FPM<\/strong>. Con 70-90 MB por trabajador, r\u00e1pidamente llego a 100-160 procesos. Que sea m\u00e1s conveniente lo est\u00e1tico o lo din\u00e1mico depende del tipo de carga. Para una carga alta constante, lo est\u00e1tico es m\u00e1s convincente, mientras que para una demanda ondulada, lo din\u00e1mico es m\u00e1s adecuado. En ambos casos, es obligatorio realizar un seguimiento constante.<\/p>\n\n<h2>Evitar obst\u00e1culos y establecer prioridades<\/h2>\n\n<p>No confundo el n\u00famero de <strong>Visitantes<\/strong> con el n\u00famero de scripts PHP simult\u00e1neos. Muchas visitas a la p\u00e1gina llegan a las cach\u00e9s, proporcionan archivos est\u00e1ticos o se bloquean fuera de PHP. Por eso dimensiono pm.max_children seg\u00fan el tiempo PHP medido, no seg\u00fan las sesiones. Si los procesos se configuran de forma demasiado austera, veo solicitudes en espera y un aumento de las tasas de error. Si los valores son demasiado altos, la memoria se desborda al swap y todo se ralentiza.<\/p>\n\n<p>Un error frecuente: m\u00e1s procesos equivalen a m\u00e1s <strong>Velocidad<\/strong>. En realidad, lo que cuenta es el equilibrio entre CPU, IO y RAM. Si la CPU alcanza 100 % y la latencia se dispara, a\u00f1adir m\u00e1s trabajadores apenas servir\u00e1 de ayuda. Es mejor eliminar el verdadero cuello de botella o reducir la carga mediante la cach\u00e9. La gu\u00eda explica por qu\u00e9 los trabajadores suelen ser el cuello de botella. <a href=\"https:\/\/webhosting.de\/es\/php-trabajadores-alojamiento-cuello-de-botella-guia-equilibrio\/\">PHP Worker como cuello de botella<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/phpfpm-serverkonfig-7342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Primero determino el valor real. <strong>RAM<\/strong>Consumo por trabajador y, a partir de ah\u00ed, establezco pm.max_children con b\u00fafer. A continuaci\u00f3n, selecciono el modo pm adecuado para el tipo de carga y equilibro los valores de inicio y de reserva. Con pm.max_requests mantengo los procesos actualizados sin una sobrecarga innecesaria. Dirijo los registros, el estado y las m\u00e9tricas a un sistema de supervisi\u00f3n limpio para que cada cambio sea medible. De este modo, consigo tiempos de respuesta cortos, grupos estables y una carga del servidor con reservas para los picos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Gu\u00eda completa para el ajuste de php-fpm: aprende a configurar de forma \u00f3ptima pm.max_children y otros par\u00e1metros de proceso para maximizar el rendimiento de tu alojamiento php.<\/p>","protected":false},"author":1,"featured_media":16046,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-16053","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"2664","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":null,"_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"php-fpm tuning","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"16046","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16053","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=16053"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16053\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/16046"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=16053"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=16053"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=16053"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}