Limites do servidor no alojamento: otimizar os limites de ficheiros e processos

Limites do servidor No alojamento, o utilizador controla especificamente o número de ficheiros e processos que os seus serviços podem manter abertos ao mesmo tempo, decidindo assim a latência, as mensagens de erro e a disponibilidade. Vou mostrar-lhe, passo a passo, como medir, ajustar e monitorizar os limites de ficheiros e processos para que os servidores Web funcionem sem problemas, mesmo sob carga. fiável trabalho.

Pontos centrais

• Suave/dura Compreender os limites e defini-los de forma adequada
• nenhum ficheiro (ficheiros) e nproc (processos) aumento orientado
• PHP-FPM e configurar corretamente as filas de espera
• Monitorização e reconhecer os estrangulamentos
• Segurança com limites superiores sensatos

Breve explicação dos limites máximos: Suave vs. difícil

Utilizo Ulimits para obter dados fiáveis por utilizador ou processo. Limites para os recursos. Os limites suaves são os limites actuais e alteráveis, que posso aumentar até ao limite rígido se a aplicação precisar de mais espaço de manobra a curto prazo. Os limites rígidos representam o limite superior absoluto e impedem o crescimento descontrolado de serviços individuais, o que afetaria todo o host. Por padrão, o comando ulimit refere-se ao limite rígido sem uma chave, o que torna os ajustes mais fáceis para administradores com direitos. Isso evita que um único script sobrecarregue o servidor com muitos arquivos ou processos. sobrecarregado.

Faço sempre uma distinção entre os parâmetros mais importantes, tais como nenhum ficheiro (ficheiros abertos), nproc (processos/threads), fsize (tamanho do ficheiro), stack (tamanho da pilha) e cpu (tempo de CPU). As pilhas Web com PHP, base de dados e componentes de cache, em particular, muitas vezes requerem significativamente mais descritores abertos do que os valores mínimos predefinidos. Sem os limites corretos, acumulam-se mensagens como „demasiados ficheiros abertos“, tempos de resposta longos ou timeouts para os pedidos. Primeiro, meço o uso real, aumento os limites gradualmente e depois verifico a latência, os contadores de erros e a taxa de transferência. É assim que asseguro um desempenho consistente com níveis de acesso elevados. Tempos de resposta.

Porque é que os limites são cruciais no alojamento

Os ambientes de alojamento partilham recursos de hardware, pelo que utilizo limites adequados para impedir o acesso injusto a recursos por parte de contas ou serviços individuais e mantenho o Desempenho estável. Nos planos de entrada, por exemplo, os processos CGI/PHP simultâneos e o tempo de CPU por utilizador são limitados, de modo a que um cron job defeituoso não torne todo o host mais lento. Nos planos superiores, mais processos podem ser executados e mais RAM pode ser usada, o que beneficia aplicações exigentes como lojas. Avalio sempre o número de processos, a RAM por processo e o tempo de CPU em conjunto para que não existam estrangulamentos artificiais. Forneço uma estrutura prática detalhada para recursos justos no artigo sobre Limites do alojamento partilhado, que explica de forma compacta as ligações organiza.

O ficheiro é crítico porque cada arquivo aberto, cada soquete e cada pipe vincula um descritor. Os valores predefinidos de 1024 são muitas vezes demasiado pequenos para as aplicações web modernas, especialmente quando existem muitas ligações simultâneas. Portanto, primeiro leio picos reais de logs e ferramentas antes de aumentar os valores, para que eu saiba os efeitos nas tabelas do kernel e na pressão da memória. Isto permite-me aumentar o débito sem pôr em causa a segurança e a capacidade de resposta do anfitrião. Se compreender o princípio, evita falhas aleatórias devido a um controlo demasiado apertado Barreiras.

Os parâmetros mais importantes na vida quotidiana: nofile, nproc e co.

Para cargas de trabalho relacionadas com a Web nenhum ficheiro no topo, porque as ligações HTTP, os sockets upstream e as ligações a bases de dados consomem quantidades enormes de descritores. Planeio buffers para cargas de pico, por exemplo, duas a quatro vezes o pico típico, para que ondas curtas de tráfego não levem imediatamente a erros. Para serviços baseados em trabalhadores, eu dimensiono o nofile em paralelo com o número de trabalhadores e suas conexões máximas. Se um CDN, proxy reverso ou camada de mensagens for adicionado, a demanda aumenta novamente, o que eu levo em conta no cálculo. Somente com um buffer limpo é que os erros esporádicos de „arquivo aberto“ desaparecem e o Taxa de erro diminui.

Em nproc-Considero processos e threads em conjunto porque alguns tempos de execução utilizam pools de threads que contam para o limite superior. Eu verifico as estratégias de spawn de servidores web, servidores de aplicativos e banco de dados para que o limite superior não entre em vigor sem ser notado e bloqueie novos trabalhadores. Se os valores de nproc forem muito baixos, isso geralmente se manifesta como lançamentos de serviços lentos ou filas que não são processadas. Eu aumento o limite para corresponder ao número de núcleos da CPU, à carga de E/S e à arquitetura do aplicativo. Isso mantém o processo de geração previsível e evita a rigidez do processo. Bloqueios.

Verificar os limites: é assim que leio a realidade

Começo todas as optimizações com visibilidade, porque sem números, as medidas permanecem cego. O comando ulimit -a mostra-me os limites actuais da sessão da shell e assim fornece a base para comparações com configurações de serviços. Eu verifico o nofile e o nproc separadamente porque esses valores são os primeiros a atingir seus limites na hospedagem. Também uso lsof, ss ou netstat para contar os ficheiros e sockets abertos por processo. Só quando conheço o pico de carga em produção é que planeio os buffers e os adiciono ao Valores-limite em.

# Todos os limites de uma sessão
ulimit -a

# Descritores de ficheiros (soft/hard)
ulimit -n
ulimit -Hn

# Processos/threads por utilizador
ulimit -u
ulimit -Hu

Para os serviços que o systemd inicia, eu não olho apenas para a minha shell interactiva, porque o systemd define o seu próprio Limites. Assim, comparo os valores efectivos de um processo em execução através de /proc//limits de modo a expor inconsistências entre a shell e o serviço. Os desvios indicam configurações em falta nos ficheiros unitários, que eu adiciono diretamente. Esta comparação poupa-me muita confusão sobre o motivo pelo qual uma aplicação não tem permissão para abrir ficheiros adicionais apesar dos limites mais elevados da shell. Isto permite-me encontrar rapidamente lacunas na configuração e garantir uma consistência Moldura.

Personalizar temporariamente: testes rápidos em sessões em curso

Antes de estabelecer limites permanentes, testo especificamente limites mais elevados numa concha. Valores. Isto permite-me ver, sem reiniciar, se a aplicação está a aceitar mais ligações como esperado ou se a latência está a diminuir. Os valores aumentados são aplicados nesta sessão até que eu a feche ou reinicie o serviço. Eu documento o efeito no syslog, nos registos de erros e nas métricas para que os ajustes permanentes posteriores sejam bem fundamentados. Testes curtos poupam-me grandes reversões e fornecem resultados fiáveis. Cupões.

# Temporário na shell atual
ulimit -n 65536 # Aumentar descritores de ficheiros
ulimit -u 4096 # Aumentar o limite de processos/thread

# Verificar/ajustar explicitamente limites rígidos (root)
ulimit -Hn 131072
ulimit -Hu 8192

Realizo estes testes em alturas de picos de carga planeados, a fim de analisar os efeitos reais. Ver. Se os erros de „demasiados ficheiros abertos“ pararem e o número de pedidos por segundo aumentar, registo os valores medidos. Se o impacto se mantiver baixo, procuro travões paralelos, como atrasos de sockets demasiado estreitos, limites de trabalhadores no servidor Web ou pools de ligações a bases de dados. Só quando toda a cadeia é escalonada é que um servidor ulimit mais elevado compensa. Desta forma, evito optimizações parciais que, em última análise, não têm qualquer efeito percetível. Melhoria trazer.

Configurar permanentemente: limits.conf e systemd

Para valores permanentes, edito o ficheiro /etc/security/limits.conf e adiciono valores específicos do utilizador ou do serviço. Linhas. Eu diferencio entre limites suaves e rígidos para que os aplicativos permaneçam altamente elásticos no curto prazo, mas ainda tenham uma clara vantagem. Para os serviços systemd, também defino LimitNOFILE e LimitNPROC, porque, caso contrário, os arquivos de unidade substituem as alterações do shell. Depois de personalizar, eu recarrego o systemd e reinicio os serviços afetados para que os novos limites tenham efeito. A reinicialização é importante, caso contrário os processos permanecem no antigo Valores do quadro.

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

# unidade systemd (por exemplo, /etc/systemd/system/nginx.service.d/limits.conf)
[Serviço]
LimitNOFILE=65536
LimitNPROC=4096

# Ativar alterações
systemctl daemon-reload
systemctl restart nginx

Contexto	Localização	Validade	Típico
Sessão interactiva	ulimit em Shell	Apenas os actuais shell/filhos	Testes rápidos
Utilizador de todo o sistema	/etc/security/limits.conf	Processos baseados em login/PAM	Base duradoura
Serviços (systemd)	Ficheiro de unidade: LimitNOFILE/LimitNPROC	Apenas o serviço afetado	Limites claros dos serviços

Categorizar corretamente os limites do kernel em todo o sistema

Para além dos limites máximos relacionados com o processo e com o utilizador, existem limites máximos para todo o sistema que eu verifico sempre. Mesmo um nofile alto é inútil se o kernel mantém a tabela global de descritores de arquivos curta. Portanto, eu verifico fs.file-max (total de possíveis FDs abertos) e fs.nr_open (máximo de FDs permitidos por processo no nível do kernel). Se esses valores não coincidirem, eu alcanço os limites logo no início, apesar de aumentar os ulimits.

# Verificar os limites de todo o sistema
cat /proc/sys/fs/file-max
cat /proc/sys/fs/nr_open
cat /proc/sys/fs/file-nr # Em uso, Livre, Máximo

# Aumentar temporariamente (até reiniciar)
sysctl fs.file-max=2097152

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

Eu noto a cascata: Limite de processo (RLIMIT_NOFILE) ≤ fs.nr_open ≤ fs.file-max (global). Se nofile for definido via fs.nr_open, o kernel ignora silenciosamente o pedido. Eu dimensiono globalmente de acordo, e depois por serviço. Para aceitar backlogs, eu também dimensiono net.core.somaxconn e os parâmetros de backlog dos respectivos serviços, caso contrário as conexões de entrada continuarão a passar fome na fila.

unidades do systemd: TasksMax, PIDsMax e DefaultLimits

Nas distribuições modernas, o systemd não limita apenas os descritores, mas também o número de tarefas (processos/threads) por serviço via TarefasMax. Defino valores adequados para configurações de elevada simultaneidade ou utilizo „infinito“ quando transfiro o controlo para o nproc. Para serviços de utilizador [email protected]ço respetivamente system.conf com as opções DefaultLimit* para aumentar os valores de base de forma consistente.

# Serviço drop-in para mais tarefas e FD
mkdir -p /etc/systemd/system/php-fpm.service.d
cat < /etc/systemd/system/php-fpm.service.d/limits.conf
[Serviço]
LimitNOFILE=131072
LimitNPROC=8192
TasksMax=16384
EOF

systemctl daemon-reload
systemctl restart php-fpm

# Predefinições para todo o sistema (use com cuidado)
# /etc/systemd/system.conf
DefaultLimitNOFILE=65536
DefaultLimitNPROC=4096
DefaultTasksMax=8192

Importante: os logins sudo, su e SSH herdam os limites de forma diferente. Para logins baseados em PAM, /etc/security/limits.conf tem efeito, mas muitas vezes não para shells que não são de logins ou cronjobs. Portanto, eu sempre testo o caminho completo pelo qual meu serviço inicia para que não haja desvios silenciosos.

Dimensionamento de servidores Web com Ulimits

Com o NGINX, eu vinculo worker_processes, worker_connections e worker_rlimit_nofile com os limites de todo o sistema. Regra de ouro: Máximo de conexões simultâneas ≈ worker_processes × worker_connections, mais reserva para upstreams, logs e pipes internos. Sem um worker_rlimit_nofile aumentado, o NGINX é executado mais cedo no EMFILE, apesar dos altos ulimits.

Exemplo do # NGINX (excerto)
worker_processes auto;
eventos {
    worker_connections 40960;
    multi_accept on;
    use epoll;
}
worker_rlimit_nofile 131072;

Com o Apache (evento MPM), presto atenção a ServerLimit, ThreadsPerChild e MaxRequestWorkers. Se o número total de conexões possíveis aumentar, o nofile deve crescer em paralelo. Caso contrário, as filas de espera ficam cheias, mesmo que a CPU e a RAM ainda tenham espaço de sobra. Eu também ajusto os backlogs de escuta (por exemplo, para NGINX: listen ... backlog=...) e kernel-somaxconn para que novas aceitações não sejam descartadas.

Bases de dados e caches: orçamento de ficheiros abertos corretamente

As bases de dados e as caches têm os seus próprios parafusos de fixação: Utilizar MySQL/MariaDB limite_de_ficheiros_abertos e os parâmetros de ligação, o PostgreSQL beneficia do agrupamento prévio de ligações, enquanto o Redis traduz o número de clientes diretamente em FDs abertos. Certifico-me de que os respectivos serviços encontram um nofile que está acima dos seus valores máximos internos. Caso contrário, o arranque ou os picos de carga falharão mesmo que a camada de aplicação tenha sido escalada.

Um padrão típico: o PHP-FPM aumenta o paralelismo, mas o servidor de BD permanece com os antigos limites de FD e limites de conexão. Eu meço os handles abertos por componente e adiciono os buffers. Isso evita que um serviço a jusante neutralize o desempenho geral.

Contentores e orquestração: limites no contexto Docker/Kubernetes

Os limites funcionam em contêineres, independentemente do contexto de login do host. Eu os defino explicitamente na inicialização ou na orquestração e também observo os limites de cgroups (PIDs, memória). No ambiente Docker, eu defino nofile/nproc e, opcionalmente, um limite de PIDs. O Kubernetes encapsula isso por meio de opções específicas do SecurityContext e do RuntimeClass; dependendo do ambiente, os Ulimits devem ser definidos por meio do 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 (excerto)
serviços:
  app:
    imagem: myimage:latest
    ulimits:
      nofile:
        soft: 65536
        hard: 131072
      nproc: 8192
    pids_limit: 20000

Verifico sempre os limites no contentor através de /proc/self/limits e certifico-me de que as personalizações do anfitrião, como o limits.conf, não se difundem automaticamente nos processos do contentor. Crio transparência com parâmetros de implementação claros e controlados por versão para cada serviço.

Resolução de problemas na prática: EMFILE, EAGAIN e spawns lentos

Para análises reproduzíveis, utilizo o strace e procuro por EMFILE („Too many open files“) ou EAGAIN („Resource temporarily unavailable“) para accept(), open(), pipe() ou clone(). Conto regularmente os FDs por processo e comparo-os com os limites definidos. Fugas nos manipuladores de ficheiros (por exemplo, chamadas esquecidas a Close()) podem ser reconhecidas mais rapidamente desta forma.

# Determinar os FDs abertos por processo
ls -l /proc//fd | wc -l

# Visão geral do uso em todo o sistema
cat /proc/sys/fs/file-nr

# trim strace para erros de FD
strace -fp  -e trace=desc,processo,rede 2>&1 | grep -E 'EMFILE|EAGAIN'

Os problemas de arranque causados por limites de nproc demasiado apertados são revelados por um arranque lento, mensagens „can't fork“ ou pools de workers incompletos. Correlaciono estes eventos com as estratégias de geração (pré-fork, dinâmica, a pedido) para que os ajustes não só aliviem os sintomas, mas também apoiem a arquitetura.

Automatização, testes e reversão

Eu mantenho as mudanças de limite reproduzíveis: eu mantenho drop-ins para systemd, arquivos sysctl.d e modelos de serviço declarativamente. Cada alteração recebe um ticket, valores medidos antes/depois e um rollback claro. Na fase de testes, simulo a utilização com ferramentas como wrk, vegeta ou k6 e presto atenção às latências P95/P99, taxas de erro e tempos de fila. Só resultados fiáveis justificam uma expansão para a produção.

# Criar um scaffolding drop-in para vários serviços
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
[Serviço]
LimitNOFILE=65536
LimitNPROC=4096
TasksMax=8192
EOF
concluído
systemctl daemon-reload
systemctl restart nginx php-fpm redis

Para as campanhas, altero os limites de forma controlada, anoto a hora de início/fim e comparo-os com as curvas de tráfego. Após o pico, reintroduzo os valores mais conservadores para minimizar a superfície de ataque e libertar recursos do kernel não utilizados.

Risco de confusão: Ulimits vs. parâmetros do watcher/kernel

Nem todos os erros de „demasiados ficheiros“ são causados pelo nofile. Os observadores do sistema de ficheiros (inotify) têm os seus próprios limites (e.g. max_user_watches), que são rapidamente atingidos com muitos ficheiros pequenos ou pilhas de desenvolvimento. vm.max_map_count (por exemplo, para motores de busca) ou net.ip_local_port_range (portas efémeras) também podem atuar como factores limitantes. Eu verifico esses parâmetros separadamente para não girar o botão errado.

Dimensionar corretamente o PHP-FPM: Processos, filas, limites

No PHP-FPM, eu coordeno pm.max_children, pm.max_requests e os limites ulimit para que o início do processo, memória e Ligações permanecem equilibrados. Quando o FPM atinge o seu limite superior, os pedidos acabam numa fila de espera; isto é intencional, mas só faz sentido se o servidor Web tratar corretamente os timeouts e o backoff. Eu meço o tempo médio de execução e uso isso para derivar um número de processo viável que não sobrecarregue a CPU e a RAM. Também ajusto o limite do descritor de ficheiro para que as ligações paralelas a montante e os gravadores de registos tenham espaço de manobra suficiente. Se quiser ir mais fundo, encontrará parafusos de ajuste práticos para Processos PHP-FPM e determina o melhor Equilíbrio.

Também verifico quantas conexões de banco de dados por trabalhador do FPM permanecem abertas ao mesmo tempo, para que os pools de conexão não se tornem o gargalo tornar-se. Um número demasiado grande de trabalhadores aumenta a pressão da RAM e as trocas de contexto, um número demasiado pequeno estagna o débito. É por isso que eu dimensiono em etapas, observo a latência P50/P95 e as falhas, e ajusto em pequenos passos. Somente quando os tempos de fila, a carga da CPU e as taxas de erro estão em equilíbrio é que eu fixo os valores permanentemente. Dessa forma, a pilha funciona de forma mais previsível e permanece estável sob carga reativo.

Monitorização e planeamento da capacidade

Faço uma cópia de segurança de cada passo com dados de medição, caso contrário, as alterações aos limites só têm um sentida. Métricas como ficheiros abertos por processo, pedidos em execução e em espera, segundos de CPU por trabalhador e memória RSS ajudam-me a categorizá-los. Os registos mostram-me quando os limites rígidos entram em vigor e se os serviços estão a recusar ligações em resultado disso. Os painéis de controlo com latências P95/P99 revelam estrangulamentos que ocultam os valores médios. De tudo isto, deduzo um alojamento prático de limites de processos que suaviza a utilização e reduz as filas de espera. abreviado.

Mantenho sempre um espaço livre reservado para que os picos curtos não causem interferências. produzir. Se estiver a atingir picos mensais ou de campanha, aumento os limites com uma a duas semanas de antecedência e efectuo testes de tráfego reais. Em seguida, reativo limites mais apertados para minimizar os recursos e as superfícies de ataque. Este ritmo protege a plataforma de forma económica e, ao mesmo tempo, reduz o risco de perturbações. O planeamento compensa várias vezes, porque as medidas proactivas podem minimizar as janelas de serviço e Tempo de atividade seguro

Inodes e número de ficheiros: limites silenciosos com um grande efeito

Para além do nofile, o sistema de ficheiros limita o número de Inodos e, portanto, o número possível de ficheiros, independentemente da memória utilizada. Os projectos Web com muitos ficheiros de cache pequenos ou ficheiros de sessão rapidamente se deparam com um problema. Verifico o df -i, limpo artefactos antigos, restos de rotação e diretórios temporários e ajusto a estrutura do sistema de ficheiros, se necessário. Consolidar as caches CMS ou colocá-las na memória alivia a carga sobre os inodes e a impressão IO ao mesmo tempo. Eu incluo detalhes, informações básicas e estratégias no meu guia para Compreender os inodes que desenvolveu o tema das práticas de acolhimento desbloqueia.

Se os inodes forem escassos, um limite mais elevado para o descritor de ficheiros é útil nada. Por isso, asseguro uma rotação clara dos registos, limito a verbosidade da depuração e transfiro os artefactos raramente utilizados para o armazenamento em arquivo. Os pipelines de compilação também devem arrumar os artefactos para que as implementações não consumam gradualmente as reservas de inode. Esta higiene mantém os limites estáveis a longo prazo e poupa muito tempo na resolução de problemas. Uma visão limpa dos inodes evita erros inesperados. Tempos de inatividade.

Retificação orientada de mensagens de erro típicas

A mensagem „too many open files“ (demasiados ficheiros abertos) indica quase sempre que não existem ficheiros suficientes. nenhum ficheiro. Eu aumento temporariamente o limite no shell, confirmo o efeito e então ajusto os valores em limits.conf e systemd. Se aparecer a mensagem „resource temporarily unavailable“ (recurso temporariamente indisponível) durante o spawning, isso geralmente se deve ao limite do nproc, que eu aumento para corresponder à arquitetura do worker. Se os scripts PHP parecem travar, eu também verifico memory_limit, max_execution_time e os segundos de CPU concedidos pela configuração de hospedagem para CGI/FPM. Eu elimino gargalos ao longo da cadeia e evito que uma mudança em um lugar gere apenas novos Travões gerado noutra posição.

Se estes erros ocorrerem esporadicamente, trabalho com correlações métricas para determinar a situação de tempo e carga. captura. Os picos de ligações simultâneas, o aumento dos erros de backend ou as longas pesquisas de DNS fornecem boas indicações. Em seguida, verifico os limites dos serviços afectados separadamente para identificar os valores efectivos. Se a configuração estiver correta, mas os erros se mantiverem, procuro fugas nos ficheiros, observadores defeituosos ou sockets abertos desnecessários. A limitação passo a passo poupa tempo e reduz o Risco novos fracassos.

Um equilíbrio inteligente entre desempenho e segurança

Nunca aumento os limites sem limites, porque as aberturas demasiado largas são susceptíveis de serem atacadas. alargar. Os cenários de força bruta ou DoS beneficiam de limites demasiado elevados se não existirem outros controlos. É por isso que eu combino limites com limitação de taxa, estratégias de backoff e tempos limite claros no servidor Web e no upstream. Defino limites superiores rígidos para que possam ocorrer picos legítimos, mas que os abusos não possam aumentar. Desta forma, asseguro a disponibilidade sem pôr em causa a Controlo para perder.

Na vida quotidiana, um conceito graduado compensa: alguma margem de manobra para picos, efeito mensurável e regularidade Comentários. Se conhecer as implementações, as campanhas de tráfego e as cargas sazonais, pode planear os limites de forma pró-ativa. Eu documento todas as alterações com a data, o motivo e os valores medidos, para que as análises posteriores não fiquem no escuro. Este catálogo acelera as decisões futuras e evita a duplicação de trabalho. O desempenho e a segurança são beneficiados porque as decisões são baseadas em Dados baseado.

Avaliação dos pacotes de alojamento: o que devo procurar?

Verifico as ofertas de alojamento não só em termos de CPU e RAM, mas também explicitamente em termos de Limites para processos, descritores e segundos de CPU. Detalhes específicos sobre nproc, nofile e, se aplicável, quotas de inode ajudam-me a estimar corretamente a capacidade. Para lojas e APIs, exijo compromissos transparentes para processos PHP FPM, orçamentos de CPU e aumentos de limites a pedido. Os ambientes VPS ou dedicados dão-me soberania, mas os valores padrão sensatos para o funcionamento também contam aqui. Números claros evitam desilusões e mantêm as migrações no caminho certo simples.

Plano	Limite do processo (nproc)	Ficheiros (nofile)	RAM/Processo	tempo de CPU	Adequação
Iniciante	32-64	4096-8192	256–512 MB	5-600 s	Pequenos sítios
Negócios	64-128	16384-65536	512–1024 MB	600-3600 s	Lojas, APIs
VPS/Dedicado	Configurável	Configurável	Conforme necessário	Conforme necessário	Carga elevada

Brevemente resumido

Primeiro, meço a utilização real e, depois, levanto Limites em etapas e verificar o efeito sobre a latência, a taxa de erro e a taxa de transferência. Os switches principais são nofile para arquivos/sockets e nproc para processos/threads, complementados por fsize, stack e cpu. Defino valores permanentes de forma consistente em limits.conf e em unidades systemd para que os serviços tenham condições de estrutura idênticas. Para o PHP-FPM, eu harmonizo de perto os números de processos, memória e filas com o limite do descritor de arquivo. Monitorização, higiene de inode e limites superiores sensatos mantêm as configurações de alojamento sob carga Fiável e reativo.