{"id":21143,"date":"2026-08-29T15:03:43","date_gmt":"2026-08-29T13:03:43","guid":{"rendered":"https:\/\/webhosting.de\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/"},"modified":"2026-08-29T15:03:43","modified_gmt":"2026-08-29T13:03:43","slug":"dimensionar-corretamente-o-backlog-do-socket-do-linux-ajuste-de-tcp-otimizacao-de-rede","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"Dimensionar corretamente o backlog do socket do Linux para obter o m\u00e1ximo desempenho da rede"},"content":{"rendered":"<p>Vou mostrar-te, concretamente, como podes <strong>Atrasos no Linux<\/strong> dimensionar corretamente, para que as liga\u00e7\u00f5es recebidas sejam devidamente armazenadas em buffer e aceites rapidamente. Desta forma, conseguir\u00e1s uma <strong>constante<\/strong> Desempenho da rede mesmo em picos de carga, sem que os pedidos fiquem pendentes ou sejam rejeitados.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Resumo os pontos-chave que se seguem como ponto de partida, antes de aprofundar o assunto.<\/p>\n<ul>\n  <li><strong>Fila de aceita\u00e7\u00e3o<\/strong> dimensionar de forma espec\u00edfica, sem confundir a fila SYN.<\/li>\n  <li><strong>somaxconn<\/strong> define o limite m\u00e1ximo r\u00edgido para o backlog da fun\u00e7\u00e3o list()`.<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> protege os handshakes em caso de pico de tr\u00e1fego.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> determina o valor efetivo.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> e os testes de carga orientam cada ajuste.<\/li>\n<\/ul>\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\/2026\/08\/linux-socket-backlog-5609.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona a fila de espera dos sockets do Linux<\/h2>\n\n<p>Um socket de servidor muda com <strong>listen()<\/strong> entra no modo de escuta e, ao faz\u00ea-lo, recebe um valor de backlog que armazena em buffer as liga\u00e7\u00f5es j\u00e1 estabelecidas at\u00e9 que a aplica\u00e7\u00e3o as recupere atrav\u00e9s de <strong>accept()<\/strong> assume. Os n\u00facleos Linux modernos utilizam este valor exclusivamente para a fila de aceita\u00e7\u00e3o (Accept-Queue), enquanto as liga\u00e7\u00f5es semiabertas durante o handshake v\u00e3o parar \u00e0 fila SYN. Separo rigorosamente estas duas filas para poder atribuir corretamente a causa e o efeito e n\u00e3o ajustar os par\u00e2metros errados. A fila de aceita\u00e7\u00e3o evita transbordamentos de curta dura\u00e7\u00e3o quando a aplica\u00e7\u00e3o n\u00e3o aceita as liga\u00e7\u00f5es imediatamente, enquanto a fila SYN suporta os handshakes durante um curto intervalo de tempo. Quem ignorar esta sem\u00e2ntica estar\u00e1 a otimizar o <strong>falso<\/strong> Local e desperdi\u00e7a reservas valiosas.<\/p>\n\n<h2>Por que \u00e9 que o tamanho certo contribui diretamente para o desempenho<\/h2>\n\n<p>O tamanho da fila de espera determina o n\u00famero de sess\u00f5es totalmente estabelecidas que podem ficar \u00e0 espera de aceita\u00e7\u00e3o, o que <strong>Tempo de resposta<\/strong> influencia o estabelecimento da liga\u00e7\u00e3o. Se a fila de aceita\u00e7\u00e3o estiver cheia, o kernel recusa novas tentativas ou atrasa-as significativamente, o que se traduz em erros espor\u00e1dicos e um in\u00edcio de liga\u00e7\u00e3o moroso. Numa aproxima\u00e7\u00e3o simples, aplica-se o seguinte: taxa m\u00e1xima de aceita\u00e7\u00e3o \u2248 tamanho da fila dividido pelo tempo m\u00e9dio de perman\u00eancia por entrada. Se os pedidos forem processados de forma muito r\u00e1pida e em grande volume, aumenta a import\u00e2ncia de uma fila de aceita\u00e7\u00e3o com dimens\u00e3o suficiente. No que diz respeito aos pacotes, vale a pena analisar <a href=\"https:\/\/webhosting.de\/pt\/servidor-filas-de-pacotes-estabilidade-da-rede-otimizacao-do-alojamento-latencia\/\">Filas de pacotes do servidor<\/a>, porque \u00e9 a\u00ed que se encontra o pr\u00f3ximo n\u00edvel de buffer que incluo no ajuste e que coordeno com a estrat\u00e9gia de backlog.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_socket_backlog_opt_8492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e2metros do kernel: somaxconn e tcp_max_syn_backlog<\/h2>\n\n<p>Para o backlog efetivo, n\u00e3o conta apenas o valor em <strong>listen()<\/strong>, uma vez que o kernel imp\u00f5e um limite m\u00e1ximo r\u00edgido atrav\u00e9s de `net.core.somaxconn`. Al\u00e9m disso, `net.ipv4.tcp_max_syn_backlog` controla o n\u00famero de handshakes semiabertos, o que \u00e9 crucial, especialmente em picos de carga ou padr\u00f5es semelhantes a ataques DDoS. Na pr\u00e1tica, aplica-se a regra simples: backlog efetivo = min(backlog, somaxconn), algo que tenho sempre em mente em cada ajuste. Os valores predefinidos conservadores revelaram-se historicamente baixos, o que faz com que os servi\u00e7os web e API modernos entrem rapidamente em gargalos. Por isso, defino o `somaxconn` de forma a que as liga\u00e7\u00f5es aceites tenham buffer suficiente e ajusto o `tcp_max_syn_backlog` em conformidade, para que os handshakes n\u00e3o entrem em sobrecarga e os clientes leg\u00edtimos sejam processados rapidamente.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Objetivo<\/th>\n      <th>Verificar<\/th>\n      <th>Valores iniciais habituais<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>Limite m\u00e1ximo para a fila de aceita\u00e7\u00e3o e, consequentemente, para o backlog da fun\u00e7\u00e3o `listen()`<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>128 a 4096+, dependendo do kernel<\/td>\n      <td>Backlog efetivo = min(backlog da aplica\u00e7\u00e3o, somaxconn)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.ipv4.tcp_max_syn_backlog<\/strong><\/td>\n      <td>Limite para liga\u00e7\u00f5es semiabertas (fila SYN)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>256 a 8192+, consoante a aplica\u00e7\u00e3o<\/td>\n      <td>Combinar com os SYN-Cookies para atenuar os picos de tr\u00e1fego<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>Buffer para pacotes recebidos no caminho do SoftIRQ<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>1000 a 5000+, dependendo da placa de rede\/IRQ<\/td>\n      <td>Avaliar em conjunto com os buffers de rece\u00e7\u00e3o\/envio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Valores de refer\u00eancia de acordo com o perfil de carga e a lat\u00eancia<\/h2>\n\n<p>Dimensiono a fila de aceita\u00e7\u00e3o com base no valor esperado <strong>perfil de carga<\/strong> e do tempo m\u00e9dio de resposta da aplica\u00e7\u00e3o. Para servi\u00e7os de tr\u00e1fego moderado, valores entre 256 e 1024 costumam ser suficientes, enquanto APIs ou lojas com tr\u00e1fego intenso beneficiam de valores entre 2048 e 8192, desde que o hardware e a arquitetura do servidor web suportem esses valores. Muitas solicita\u00e7\u00f5es curtas justificam valores mais elevados, porque mais liga\u00e7\u00f5es ficam em espera por um curto per\u00edodo de tempo e, mesmo assim, s\u00e3o encaminhadas rapidamente. As sess\u00f5es de longa dura\u00e7\u00e3o requerem antes um n\u00famero otimizado de trabalhadores e vias de E\/S, em vez de filas cada vez maiores. Tenho em aten\u00e7\u00e3o a intera\u00e7\u00e3o com os agendadores da CPU, a distribui\u00e7\u00e3o de IRQ e o caminho de aceita\u00e7\u00e3o no espa\u00e7o do utilizador, para que a fila n\u00e3o tenha de ser o \u00fanico recurso utilizado.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-socket-backlog-netzwerk-4421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Avaliar a situa\u00e7\u00e3o atual e identificar pontos de estrangulamento<\/h2>\n\n<p>Antes de alterar os valores, avalio a utiliza\u00e7\u00e3o da fila com <strong>ss<\/strong> ou o netstat e verifico se h\u00e1 anomalias nas filas de rece\u00e7\u00e3o e envio. As estat\u00edsticas do kernel e as mensagens do dmesg fornecem informa\u00e7\u00f5es sobre transbordamentos de listas, pacotes perdidos ou perdas de backlog, que eu correlaciono temporalmente com picos de carga. Analiso os registos do servidor Web e dos proxies a montante para identificar taxas de erro no estabelecimento de liga\u00e7\u00f5es e nas tentativas de reposi\u00e7\u00e3o. Paralelamente, observo a carga da CPU, o equil\u00edbrio de IRQ e o comportamento do agendador, para n\u00e3o deixar escapar nenhum estrangulamento noutras camadas. S\u00f3 depois de compreender a situa\u00e7\u00e3o \u00e9 que planeio os pr\u00f3ximos passos para uma abordagem direcionada <strong>Afina\u00e7\u00e3o<\/strong>.<\/p>\n\n<h2>Medi\u00e7\u00e3o aprofundada: indicadores, padr\u00f5es de erros e percurso de diagn\u00f3stico<\/h2>\n<p>Para um diagn\u00f3stico preciso, consulto os contadores do kernel em \/proc\/net\/netstat. Na linha TcpExt, interesso-me especialmente pelos valores de ListenOverflows e ListenDrops (fila de aceita\u00e7\u00e3o), bem como pelos de SyncookiesSent\/SyncookiesRecv (fase SYN). Se os \u201eListenOverflows\u201c aumentarem, significa que a fila de aceita\u00e7\u00e3o (Accept-Queue) \u00e9 demasiado pequena ou que a aplica\u00e7\u00e3o est\u00e1 a aceitar liga\u00e7\u00f5es demasiado lentamente. Se os contadores de Syncookies aumentarem, significa que a fila SYN est\u00e1 sobrecarregada ou que o servi\u00e7o est\u00e1 a ser alvo de padr\u00f5es de ataque agressivos. Com o comando `ss -ltn`, verifico o backlog atualmente configurado por porta e determino se a aplica\u00e7\u00e3o est\u00e1 realmente a passar o valor pretendido ao kernel. Mensagens do `dmesg` como \u201eTCP: request_sock_queue is full\u201c indicam um transbordamento da fila SYN, enquanto \u00abTCP: listen overflow\u00bb aponta para a fila de aceita\u00e7\u00e3o. Comparo estes indicadores com as m\u00e9tricas de monitoriza\u00e7\u00e3o (lat\u00eancias, taxas de erro, tentativas de repeti\u00e7\u00e3o), para poder agir de forma precisa.<\/p>\n<p>No caso de picos de curta dura\u00e7\u00e3o, crio s\u00e9ries temporais de alta resolu\u00e7\u00e3o. Correlaciono o n\u00edvel m\u00e1ximo de enchimento da fila de aceita\u00e7\u00e3o com a lat\u00eancia de aceita\u00e7\u00e3o no espa\u00e7o do utilizador. Opcionalmente, utilizo tra\u00e7os baseados em eBPF para analisar os tempos de espera de \u00abAccept\u00bb e os \u00abwakeups\u00bb. Isto \u00e9 particularmente \u00fatil quando h\u00e1 muitos \u00ablisteners\u00bb, afinidades de processos ou conten\u00e7\u00e3o de bloqueios em jogo e os efeitos n\u00e3o podem ser explicados apenas atrav\u00e9s dos contadores.<\/p>\n\n<h2>Otimiza\u00e7\u00e3o gradual com ciclos de medi\u00e7\u00e3o<\/h2>\n\n<p>Come\u00e7o por documentar o estado atual, registo os valores predefinidos existentes e a caracter\u00edstica de carga atual em <strong>horas de pico<\/strong>. Em seguida, aumentei moderadamente o somaxconn e o backlog da aplica\u00e7\u00e3o, em cerca de duas a tr\u00eas etapas, e observei, em cada uma delas, as taxas de erro, as lat\u00eancias e os tempos de aceita\u00e7\u00e3o. Em seguida, verifico o tcp_max_syn_backlog e os SYN-Cookies, caso os handshakes falhem antes mesmo da fila de aceita\u00e7\u00e3o. Para cada etapa, realizo testes de carga reproduz\u00edveis e baseio-me em m\u00e9tricas concretas, em vez de intui\u00e7\u00e3o. A melhor configura\u00e7\u00e3o resulta de um ciclo de medi\u00e7\u00e3o, no qual integro sistematicamente o feedback do monitoriza\u00e7\u00e3o e da an\u00e1lise de desempenho da aplica\u00e7\u00e3o na pr\u00f3xima <strong>Personaliza\u00e7\u00e3o<\/strong> condam.<\/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\/2026\/08\/linuxsocketbacklognetzwerk5234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00e3o da aplica\u00e7\u00e3o e estrat\u00e9gia de aceita\u00e7\u00e3o<\/h2>\n\n<p>Verifico as defini\u00e7\u00f5es do backlog dos servi\u00e7os do servidor, como o Apache, o NGINX ou os servidores de aplica\u00e7\u00f5es, para garantir que um valor predefinido demasiado baixo n\u00e3o afete todo o <strong>fila de espera<\/strong> limita. Algumas estruturas definem os seus pr\u00f3prios valores ou ignoram par\u00e2metros elevados at\u00e9 que uma op\u00e7\u00e3o seja definida explicitamente. Quando h\u00e1 muitos n\u00facleos de CPU dispon\u00edveis, complemento o conceito atrav\u00e9s de <a href=\"https:\/\/webhosting.de\/pt\/assim-re-report-linux-servidor-web-otimizacao-de-desempenho-nucleo\/\">SO_REUSEPORT<\/a>, para que v\u00e1rios listeners executem o `accept()` em paralelo na mesma porta. Desta forma, reduzo sensivelmente o tempo de aceita\u00e7\u00e3o, o que diminui o tempo m\u00e9dio de perman\u00eancia na fila de aceita\u00e7\u00e3o. \u00c9 importante que eu ajuste em simult\u00e2neo eventuais limites para descritores de ficheiros abertos e processos de trabalho, para que n\u00e3o surja um novo estrangulamento no espa\u00e7o do utilizador.<\/p>\n\n<h2>Aplica\u00e7\u00e3o pr\u00e1tica em servidores e frameworks comuns<\/h2>\n<p>Na pr\u00e1tica, controlo o backlog efetivo por servi\u00e7o: o NGINX permite definir o backlog no bloco \u00ablisten\u00bb; al\u00e9m disso, existem os par\u00e2metros \u00abaccept_mutex\u00bb e \u00abworker_processes\u00bb, que determinam a taxa de aceita\u00e7\u00e3o. No Apache, defino o ListenBacklog (por vHost\/Bind) e certifico-me de que o MPM (por exemplo, event) mant\u00e9m trabalhadores suficientes dispon\u00edveis. No HAProxy, defino o backlog atrav\u00e9s das op\u00e7\u00f5es de bind e, paralelamente, ajusto o tune.maxaccept e o n\u00famero de processos\/threads. Nas pilhas Java (Netty, Undertow, Tomcat) existe geralmente uma propriedade `soBacklog`; o `Node.js\/Libuv` aceita um par\u00e2metro `backlog` em `server.listen()`, que, sem uma especifica\u00e7\u00e3o expl\u00edcita, se situa frequentemente abaixo de `somaxconn`. Em Go, o net.Listen ou o http.Server utilizam os valores predefinidos do sistema operativo; neste caso, presto especial aten\u00e7\u00e3o a garantir um somaxconn suficiente, uma vez que a camada de aplica\u00e7\u00e3o raramente define o seu pr\u00f3prio backlog.<\/p>\n<p>Testo cada servi\u00e7o com s\u00e9ries de liga\u00e7\u00f5es curtas e intensas (por exemplo, sem Keep-Alive) para verificar a resili\u00eancia do backlog. S\u00f3 quando a aceita\u00e7\u00e3o se mantiver constante mesmo em condi\u00e7\u00f5es de picos de tr\u00e1fego \u00e9 que volto a permitir, no dia-a-dia, tempos de Keep-Alive mais longos e a reutiliza\u00e7\u00e3o de liga\u00e7\u00f5es, de forma a poupar recursos.<\/p>\n\n<h2>SO_REUSEPORT: Paraleliza\u00e7\u00e3o sem conten\u00e7\u00e3o<\/h2>\n<p>Com SO_REUSEPORT, distribuo as liga\u00e7\u00f5es recebidas por v\u00e1rios sockets de escuta, normalmente um por trabalhador\/n\u00facleo da CPU. Cada socket possui a sua pr\u00f3pria fila de aceita\u00e7\u00e3o com o seu pr\u00f3prio backlog, o que multiplica efetivamente a capacidade total. \u00c9 fundamental que todos os listeners estejam configurados de forma id\u00eantica (mesmos valores de backlog, mesmas prioridades), para que o kernel distribua de forma equitativa e n\u00e3o surjam desequil\u00edbrios. Observo se determinados trabalhadores est\u00e3o sobrecarregados ou subutilizados e ajusto o n\u00famero de processos ou a afinidade da CPU. Na pr\u00e1tica, esta estrat\u00e9gia reduz significativamente a conten\u00e7\u00e3o de bloqueios no caminho de aceita\u00e7\u00e3o e diminui as tempestades de despertar, o que suaviza as lat\u00eancias.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, dados antecipados e momento da aceita\u00e7\u00e3o<\/h2>\n<p>Atrav\u00e9s do TCP_DEFER_ACCEPT, posso fazer com que o kernel s\u00f3 ative a fun\u00e7\u00e3o accept() quando j\u00e1 tiverem chegado dados \u00fateis. Desta forma, diminui o n\u00famero de ativa\u00e7\u00f5es desnecess\u00e1rias (clientes que se ligam, mas n\u00e3o enviam nada) e o tempo de perman\u00eancia na fila de aceita\u00e7\u00e3o parece menor. Utilizo esta configura\u00e7\u00e3o com cautela, uma vez que os tempos de espera ao n\u00edvel da aplica\u00e7\u00e3o, o comportamento dos dispositivos interm\u00e9dios e as pilhas dos clientes podem interagir entre si. As cargas de trabalho passivas (por exemplo, protocolos que enviam inicialmente dados do servidor) beneficiam menos; por outro lado, os protocolos \u00abchatty\u00bb com envios imediatos do cliente podem ser aliviados. Por isso, verifico sempre como o DEFER_ACCEPT afeta as tentativas de reenvio, os tempos de espera e as lat\u00eancias totais antes de o ativar de forma permanente. Al\u00e9m disso, s\u00f3 planeio utilizar o TCP_FASTOPEN se os custos do handshake forem significativos e a infraestrutura os suportar de forma est\u00e1vel.<\/p>\n\n<h2>Seguran\u00e7a em picos de carga e picos de SYN<\/h2>\n\n<p>Quando deteto valores elevados na fila SYN, recorro a <strong>Cookies SYN<\/strong> que tornam os handshakes mais suport\u00e1veis quando h\u00e1 muitas liga\u00e7\u00f5es incompletas a tentar estabelecer-se. Em caso de anomalias na fase de entrada, aumentei o valor de `tcp_max_syn_backlog` em incrementos moderados e observei se os clientes leg\u00edtimos voltavam a chegar rapidamente. Complemento isto com limites de taxa, estrat\u00e9gias de backoff e par\u00e2metros de retransmiss\u00e3o bem definidos, para que padr\u00f5es desfavor\u00e1veis n\u00e3o provoquem efeitos de domin\u00f3. Informa\u00e7\u00f5es detalhadas sobre como bloquear de forma eficaz padr\u00f5es recorrentes s\u00e3o apresentadas no contexto <a href=\"https:\/\/webhosting.de\/pt\/syn-protecao-contra-inundacoes-tratamento-de-tomadas-defesa-do-servidor\/\">Prote\u00e7\u00e3o contra SYN-Flood<\/a> em conjunto. As funcionalidades de seguran\u00e7a s\u00e3o mais eficazes quando as coordeno com os tamanhos do backlog, os buffers de pacotes e o desempenho de aceita\u00e7\u00e3o de aplica\u00e7\u00f5es, e as comparo regularmente com perfis de teste realistas.<\/p>\n\n<h2>Ajuste da fila de trabalhos no dia-a-dia da hospedagem<\/h2>\n\n<p>No \u00e2mbito do alojamento profissional, verifico sempre os valores do backlog em conjunto com <strong>somaxconn<\/strong>, tcp_max_syn_backlog, backlog do netdev e workers de aplica\u00e7\u00f5es. \u00c9 assim que garanto que os tempos de resposta prometidos continuem a ser cumpridos, mesmo com flutua\u00e7\u00f5es no tr\u00e1fego. Documento todos os par\u00e2metros do kernel e dos servi\u00e7os, para que as auditorias, as rotinas de SRE e as transfer\u00eancias de responsabilidades proporcionem clareza rapidamente. O sistema de monitoriza\u00e7\u00e3o emite alertas em caso de n\u00edveis de enchimento das filas, erros de aceita\u00e7\u00e3o e novas tentativas, o que acelera os ajustes posteriores. Quem compara pacotes de alojamento deve avaliar, para al\u00e9m da CPU e da RAM, tamb\u00e9m estes detalhes de rede, pois t\u00eam um impacto significativo nos custos, no \u00abTime-to-First-Byte\u00bb e no sucesso <strong>Sess\u00f5es<\/strong> t\u00eam.<\/p>\n\n<h2>Evitar erros t\u00edpicos<\/h2>\n\n<p>Um erro comum: s\u00f3 estou a aumentar a lista de tarefas pendentes da aplica\u00e7\u00e3o, mas <strong>somaxconn<\/strong> demasiado pequeno, o que faz com que o limite m\u00e1ximo efetivo permane\u00e7a inalterado. Igualmente perigosa \u00e9 a confus\u00e3o entre as filas Accept e SYN, o que leva a corre\u00e7\u00f5es erradas. Valores extremamente elevados, sem um plano definido, ocultam as fraquezas da aplica\u00e7\u00e3o, consomem mem\u00f3ria e dificultam a an\u00e1lise das causas. Se a fun\u00e7\u00e3o `accept()` n\u00e3o aceitar as liga\u00e7\u00f5es com rapidez suficiente, a fila permanecer\u00e1 cheia apesar dos n\u00fameros elevados e os clientes continuar\u00e3o \u00e0 espera. Por isso, verifico primeiro o percurso no espa\u00e7o do utilizador, minimizo a conten\u00e7\u00e3o de bloqueios, distribuo o trabalho pelos n\u00facleos e, posteriormente, calibro os tamanhos do backlog <strong>Direcionado<\/strong>.<\/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\/2026\/08\/linux-backlog-serverraum-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Contentores, m\u00e1quinas virtuais e orquestra\u00e7\u00e3o<\/h2>\n<p>Em ambientes virtualizados e contentores, aplica-se o seguinte: o backlog efetivo depende do kernel do anfitri\u00e3o. Se definir o `somaxconn` no contentor, o anfitri\u00e3o tem de permitir e manter essa configura\u00e7\u00e3o. No Kubernetes, ativo explicitamente os sysctls necess\u00e1rios e certifico-me de que as pol\u00edticas de seguran\u00e7a o permitem. Al\u00e9m disso, verifico os valores do ulimit (nofile) e os limites do cgroup, para garantir que seja poss\u00edvel abrir um grande n\u00famero de sockets em simult\u00e2neo. Se houver um controlador Ingress ou um NodePort a antepor-se a isso, dimensiono o seu backlog de lista da mesma forma que o da pr\u00f3pria aplica\u00e7\u00e3o, para que o primeiro salto n\u00e3o se torne o gargalo. O mesmo se aplica aos balanceadores de carga L3\/4 ou aos proxies: cada n\u00edvel possui as suas pr\u00f3prias filas, que analiso de forma integrada.<\/p>\n\n<h2>Planeamento de capacidade: exemplos de c\u00e1lculos para os volumes de pedidos em atraso<\/h2>\n<p>Eu fa\u00e7o o dimensionamento em tr\u00eas etapas: (1) determinar a taxa m\u00e1xima de chegada (Conn\/s) nos picos, (2) medir a lat\u00eancia m\u00e9dia de aceita\u00e7\u00e3o da aplica\u00e7\u00e3o, (3) prever uma margem de seguran\u00e7a. Exemplo: se ocorrer um pico de 10 000 conex\u00f5es por segundo e o tempo m\u00e9dio entre a chegada e a fun\u00e7\u00e3o accept() for de 3 ms, ent\u00e3o, a curto prazo, \u00e9 necess\u00e1rio armazenar em buffer, em m\u00e9dia, 10 000 \u00d7 0,003 = 30 conex\u00f5es. Para picos e flutua\u00e7\u00f5es na distribui\u00e7\u00e3o, escolho um fator de 5 a 10, ou seja, 150 a 300. Se, al\u00e9m disso, planear utilizar v\u00e1rios listeners via SO_REUSEPORT, a capacidade aumenta proporcionalmente ao n\u00famero de listeners. Para pedidos muito curtos (por exemplo, 5\u201320 ms), fa\u00e7o c\u00e1lculos mais conservadores, porque as flutua\u00e7\u00f5es estat\u00edsticas s\u00e3o predominantes. No caso de sess\u00f5es de longa dura\u00e7\u00e3o, dou prioridade ao n\u00famero de trabalhadores, \u00e0 escalabilidade do epoll e \u00e0s vias de E\/S, antes de aumentar ainda mais os backlogs.<\/p>\n<p>Al\u00e9m disso, calculo as necessidades de mem\u00f3ria: cada entrada na fila de aceita\u00e7\u00e3o mant\u00e9m estruturas do kernel em mem\u00f3ria. Por isso, valores muito elevados s\u00f3 fazem sentido se o or\u00e7amento de RAM, os descritores de ficheiros e os trabalhadores do espa\u00e7o do utilizador tamb\u00e9m acompanharem esse ritmo. O objetivo n\u00e3o \u00e9 ter um buffer o maior poss\u00edvel, mas sim um buffer suficientemente grande para suavizar picos de tr\u00e1fego sem sobrecarregar outros recursos.<\/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\/2026\/08\/linuxsocketbacklog1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gest\u00e3o de altera\u00e7\u00f5es, persist\u00eancia e revers\u00e3o<\/h2>\n<p>Separo os testes da opera\u00e7\u00e3o: primeiro, fa\u00e7o os ajustes num ambiente de staging com perfis de carga representativos e, depois, implemento gradualmente em produ\u00e7\u00e3o. Registo os par\u00e2metros do kernel em ficheiros sysctl.d dedicados, documento-os com a finalidade e a data e verifico a sua efic\u00e1cia ap\u00f3s o rein\u00edcio. Defino as filas de espera dos servi\u00e7os no respetivo ficheiro de configura\u00e7\u00e3o e fixo-as atrav\u00e9s da gest\u00e3o de configura\u00e7\u00e3o, para que n\u00e3o se verifiquem desvios. Para sistemas cr\u00edticos, estabele\u00e7o uma janela de revers\u00e3o e, ap\u00f3s a implementa\u00e7\u00e3o, monitorizo de perto os transbordamentos de lista, as lat\u00eancias de aceita\u00e7\u00e3o e as taxas de erro. Se surgirem efeitos secund\u00e1rios (por exemplo, aumento da carga de mem\u00f3ria ou satura\u00e7\u00e3o de threads), recuo um passo e resolvo primeiro o novo gargalo.<\/p>\n\n<h2>Ferramentas e rotinas operacionais<\/h2>\n<p>Nas minhas rotinas operacionais, tenho \u00e0 disposi\u00e7\u00e3o um pequeno conjunto de ferramentas fi\u00e1veis: ss\/netstat para visualizar os sockets em escuta e os valores atuais do backlog, sysctl para a configura\u00e7\u00e3o de par\u00e2metros, journalctl\/dmesg para obter informa\u00e7\u00f5es do kernel e uma ferramenta de teste de carga capaz de gerar picos de forma breve, repet\u00edvel e mensur\u00e1vel. Al\u00e9m disso, utilizo exportadores de processos que registam o tempo de aceita\u00e7\u00e3o e os n\u00edveis de enchimento das filas, bem como perfis do sistema (perf, eBPF), para, se necess\u00e1rio, analisar em detalhe o percurso de aceita\u00e7\u00e3o. A monitoriza\u00e7\u00e3o recolhe histogramas relativos \u00e0s lat\u00eancias de estabelecimento de liga\u00e7\u00e3o, para que eu n\u00e3o veja apenas valores m\u00e9dios, mas tamb\u00e9m distribui\u00e7\u00f5es e P95\/P99 \u2014 \u00e9 precisamente a\u00ed que se escondem os sintomas de filas demasiado pequenas.<\/p>\n\n<h2>Lista de verifica\u00e7\u00e3o para a implementa\u00e7\u00e3o<\/h2>\n<ul>\n  <li>Recolher o perfil de carga: Conn\/s, amplitude de picos, lat\u00eancia de aceita\u00e7\u00e3o, taxa de Keep-Alive.<\/li>\n  <li>Documentar os valores atuais: somaxconn, tcp_max_syn_backlog, netdev-backlog, backlogs dos servi\u00e7os, nofile.<\/li>\n  <li>Verificar os contadores do kernel: ListenOverflows\/Drops, contadores de Syncookies, mensagens dmesg.<\/li>\n  <li>Aumentar gradualmente o backlog: aplica\u00e7\u00e3o e somaxconn em sincronia, ciclos de medi\u00e7\u00e3o por cada fase.<\/li>\n  <li>Proteger a fase SYN: aumentar moderadamente o valor de tcp_max_syn_backlog, ativar os SYN-Cookies e monitorizar a situa\u00e7\u00e3o.<\/li>\n  <li>Paraleliza\u00e7\u00e3o: utilizar o SO_REUSEPORT, calibrar os trabalhadores e as afinidades.<\/li>\n  <li>Acompanhar o percurso dos pacotes: ajustar o netdev-backlog, o equil\u00edbrio de IRQ e os buffers de rece\u00e7\u00e3o\/envio.<\/li>\n  <li>Persist\u00eancia e revers\u00e3o: sysctl.d, gest\u00e3o de vers\u00f5es, implementa\u00e7\u00e3o faseada, telemetria a ter em conta.<\/li>\n<\/ul>\n\n<h2>Resumo para uma aplica\u00e7\u00e3o r\u00e1pida<\/h2>\n\n<p>Dimensiono o backlog de forma pragm\u00e1tica: primeiro avalio, depois <strong>personalizar<\/strong>, e depois voltar a medir. Para muitos servidores Web e API, valores entre 2048 e 8192 para o `somaxconn`, com a configura\u00e7\u00e3o adequada da aplica\u00e7\u00e3o, constituem um n\u00edvel inicial vi\u00e1vel, que verifico atrav\u00e9s de um teste de carga. Em caso de picos de handshake, aumentei o valor de `tcp_max_syn_backlog` gradualmente e ativei os SYN-cookies, para que os clientes leg\u00edtimos n\u00e3o fossem prejudicados. Paralelamente, trato do backlog do netdev, dos buffers de rece\u00e7\u00e3o\/envio, do equil\u00edbrio de IRQ e da estrat\u00e9gia de aceita\u00e7\u00e3o no espa\u00e7o do utilizador. Assim, mantenho o estabelecimento de liga\u00e7\u00f5es, o tempo de resposta e as taxas de erro sob controlo e utilizo o <strong>Pend\u00eancias do Linux<\/strong> como um instrumento eficaz para garantir um desempenho constante da rede.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a dimensionar corretamente o backlog de sockets do Linux e a melhorar de forma sustent\u00e1vel o desempenho de rede dos seus servidores atrav\u00e9s de um ajuste espec\u00edfico do TCP.<\/p>","protected":false},"author":1,"featured_media":21136,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21143","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"149","_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":"1","_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":"Linux Backlog","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":"21136","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}