{"id":20516,"date":"2026-08-10T15:06:02","date_gmt":"2026-08-10T13:06:02","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-thread-pool-server-performance-tempel\/"},"modified":"2026-08-10T15:06:02","modified_gmt":"2026-08-10T13:06:02","slug":"mariadb-pool-de-threads-servidor-desempenho-tempel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-thread-pool-server-performance-tempel\/","title":{"rendered":"Pool de threads do MariaDB: maior desempenho para servidores de alojamento com elevada carga de trabalho"},"content":{"rendered":"<p>Eu coloquei o <strong>Pool de threads do MariaDB<\/strong> de forma espec\u00edfica, para agrupar de forma organizada as consultas curtas em servidores de alojamento com elevada carga e distribuir melhor o tempo de CPU. Desta forma, reduzo <strong>Mudan\u00e7a de contexto<\/strong>, mantenha as filas de espera sob controlo e obtenha tempos de resposta visivelmente mais curtos mesmo com muitas liga\u00e7\u00f5es simult\u00e2neas.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Controlo adaptativo<\/strong>: Os grupos de threads distribuem o trabalho em paralelo, em vez do princ\u00edpio \u201eum thread por liga\u00e7\u00e3o\u201c.<\/li>\n  <li><strong>Efici\u00eancia da CPU<\/strong>: Menos mudan\u00e7as de contexto, melhores acertos na cache, lat\u00eancia mais est\u00e1vel.<\/li>\n  <li><strong>Foco no alojamento<\/strong>: Muitas consultas curtas beneficiam mais do que as transa\u00e7\u00f5es longas.<\/li>\n  <li><strong>Afina\u00e7\u00e3o simples<\/strong>: Par\u00e2metros importantes, como thread_handling e thread_pool_size.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o vis\u00edvel<\/strong>: As m\u00e9tricas mostram filas, threads inativos e carga de trabalho.<\/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\/servermanagement-performance-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o conjunto de threads do MariaDB consegue fazer<\/h2>\n\n<p>Agrupo muitas liga\u00e7\u00f5es curtas em poucos grupos de threads, para que o servidor <strong>Carga<\/strong> n\u00e3o s\u00e3o paralelizadas de forma descontrolada. Em vez de manterem um thread pr\u00f3prio para cada liga\u00e7\u00e3o, os pools processam sistematicamente os pedidos a partir de uma fila. Isto reduz a sobrecarga no sistema operativo e poupa as caches da CPU em situa\u00e7\u00f5es de elevada <strong>Concorr\u00eancia<\/strong>. Assim, as instru\u00e7\u00f5es AUTOCOMMIT curtas chegam mais rapidamente aos seus n\u00facleos, enquanto as opera\u00e7\u00f5es bloqueantes raramente abrandam todo o sistema. Esta vantagem \u00e9 particularmente significativa em padr\u00f5es OLTP com elevada simultaneidade, porque d\u00e1 prioridade ao trabalho efetivamente execut\u00e1vel.<\/p>\n\n<h2>Por que \u00e9 que os servidores de alojamento beneficiam com isso<\/h2>\n\n<p>Em sistemas partilhados, muitos workers PHP, tarefas Cron e chamadas \u00e0 API deparam-se com uma mem\u00f3ria RAM limitada e geram rapidamente picos de liga\u00e7\u00f5es, que eu suavizo com o Thread Pool. \u00c9 precisamente aqui que evito inunda\u00e7\u00f5es desnecess\u00e1rias de threads e previno as \u201etempestades de liga\u00e7\u00f5es\u201c, que fazem disparar as lat\u00eancias. O MariaDB j\u00e1 recomenda a utiliza\u00e7\u00e3o de uma variante de pool a partir de cerca de 128 consultas r\u00e1pidas em execu\u00e7\u00e3o simult\u00e2nea, o que sublinha a relev\u00e2ncia desta abordagem para o alojamento partilhado. Para abordagens pr\u00e1ticas mais aprofundadas, remeto para este guia conciso <a href=\"https:\/\/webhosting.de\/pt\/thread-pool-otimizacao-do-servidor-workerhosting-threadpool\/\">Otimiza\u00e7\u00e3o do pool de threads<\/a>, que aborda padr\u00f5es t\u00edpicos nas configura\u00e7\u00f5es de alojamento. Desta forma, garanto tempos de resposta constantes, reduzo a pegada de mem\u00f3ria por liga\u00e7\u00e3o e mantenho a <strong>CPU<\/strong> sensivelmente mais produtivo.<\/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\/mariadb_threadpool_meeting_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cargas de trabalho t\u00edpicas e limites<\/h2>\n\n<p>Vejo os maiores efeitos em situa\u00e7\u00f5es com muitas instru\u00e7\u00f5es SELECT e INSERT curtas, como em sistemas CMS e lojas online com elevado tr\u00e1fego de visitantes. O WordPress, o WooCommerce, os front-ends headless com chamadas intensivas \u00e0 API e as configura\u00e7\u00f5es multicliente beneficiam particularmente, porque as consultas costumam ser curtas. No caso de relat\u00f3rios longos e bloqueantes ou de transa\u00e7\u00f5es aninhadas, o benef\u00edcio diminui, uma vez que poucas consultas <strong>CPU<\/strong> de qualquer forma, monopolizam. A Percona salienta que as transa\u00e7\u00f5es em v\u00e1rias etapas escalam menos bem do que as instru\u00e7\u00f5es simples AUTOCOMMIT, o que tenho em conta na planea\u00e7\u00e3o. Por isso, avalio antecipadamente as cargas de trabalho de forma objetiva, para utilizar o pool como um elemento eficaz e n\u00e3o como uma panaceia.<\/p>\n\n<h2>Par\u00e2metros importantes e valores iniciais<\/h2>\n\n<p>Ativo o mecanismo atrav\u00e9s de <strong>gest\u00e3o de threads<\/strong> com o modo \u201epool-of-threads\u201c e, se necess\u00e1rio, desative-o com \u201eone-thread-per-connection\u201c. O controlador <strong>thread_pool_size<\/strong> Defino o tamanho com base nos n\u00facleos da CPU e, posteriormente, fa\u00e7o um ajuste fino com base nos valores medidos. Um pool demasiado pequeno provoca um ac\u00famulo de consultas, enquanto um pool demasiado grande gera concorr\u00eancia pelo tempo de processamento e n\u00e3o atinge o objetivo. Com <strong>limite_de_bloqueio_do_pool_de_threads<\/strong> reajo aos bloqueios quando os \u00abWorkers\u00bb parecem ficar bloqueados durante demasiado tempo. Al\u00e9m disso, utilizo <strong>tamanho_da_cache_de_fios<\/strong>, para que n\u00e3o surjam constantemente novos t\u00f3picos e para que a <strong>Lat\u00eancia<\/strong> cresce desnecessariamente.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Objetivo<\/th>\n      <th>valor inicial<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>gest\u00e3o de threads<\/td>\n      <td>Alterna entre o modo \u00abpool\u00bb e o modo \u00abum thread por liga\u00e7\u00e3o\u00bb<\/td>\n      <td>conjunto de threads<\/td>\n      <td>Comut\u00e1vel para testes sem necessidade de reiniciar o anfitri\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>thread_pool_size<\/td>\n      <td>N\u00famero de grupos de t\u00f3picos<\/td>\n      <td>\u2248 N\u00facleos da CPU<\/td>\n      <td>Iniciar com uma configura\u00e7\u00e3o conservadora no Hyper-Threading<\/td>\n    <\/tr>\n    <tr>\n      <td>limite_de_bloqueio_do_pool_de_threads<\/td>\n      <td>Detec\u00e7\u00e3o de paragens\/bloqueios<\/td>\n      <td>Padr\u00e3o, depois ajustar com precis\u00e3o<\/td>\n      <td>Ajudar quando as filas \u201eficam presas\u201c<\/td>\n    <\/tr>\n    <tr>\n      <td>tamanho_da_cache_de_fios<\/td>\n      <td>Reutiliza\u00e7\u00e3o de threads<\/td>\n      <td>Aumentar moderadamente<\/td>\n      <td>Reduz a sobrecarga de cria\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>max_conex\u00f5es<\/td>\n      <td>Limitar as liga\u00e7\u00f5es ativas<\/td>\n      <td>Votar com realismo<\/td>\n      <td>Respeitar rigorosamente os or\u00e7amentos de RAM<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Nunca aplico altera\u00e7\u00f5es \u00e0 cega no ambiente de produ\u00e7\u00e3o, mas sim testo-as de forma reproduz\u00edvel. S\u00f3 os testes de carga com conjuntos de dados representativos revelam se o comprimento da fila diminui e se as lat\u00eancias baixam realmente. Se continuarem a existir muitas solicita\u00e7\u00f5es vis\u00edveis na fila, aumentei o <strong>Dimens\u00f5es da piscina<\/strong> S\u00ea cauteloso e verifica se existem gargalos paralelos, como E\/S ou bloqueios. Por outro lado, se surgirem threads inativos com elevada lat\u00eancia, a causa situa-se, na maioria das vezes, fora do pool. Este ciclo pragm\u00e1tico de testar, medir e ajustar mant\u00e9m os sistemas a funcionar com uma velocidade previs\u00edvel.<\/p>\n\n<h2>Dimensionamento passo a passo<\/h2>\n\n<p>Come\u00e7o com um tamanho de pool pr\u00f3ximo do valor de refer\u00eancia e observo per\u00edodos curtos sob carga de pico. Em seguida, comparo os tempos de resposta, a carga da CPU, os threads inativos e a profundidade vis\u00edvel da fila, para determinar os pr\u00f3ximos passos. Se um ligeiro aumento do <strong>thread_pool_size<\/strong> Se obtiver uma melhor lat\u00eancia sem satura\u00e7\u00e3o da CPU, registo o valor e repito a medi\u00e7\u00e3o. Se o tempo de resposta piorar, recuo um passo e verifico os bloqueios, os tempos de espera de E\/S e os pontos cr\u00edticos de bloqueio. Assim, cria-se um intervalo robusto, no qual o conjunto de threads funciona corretamente e o <strong>Estabilidade<\/strong> aumenta visivelmente.<\/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\/mariadb-thread-pool-performance-2289.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interpretar o monitoriza\u00e7\u00e3o e as m\u00e9tricas<\/h2>\n\n<p>Estou atento aos valores de Threadpool_threads e Threadpool_idle_threads para perceber se os workers est\u00e3o livres ou permanentemente em atividade. Se os threads inativos se mantiverem elevados e o <strong>Lat\u00eancia<\/strong> se, mesmo assim, continuar a aumentar, o gargalo est\u00e1 noutro local, como o disco ou os bloqueios. Se as filas continuarem a crescer durante muito tempo, reduzo a concorr\u00eancia ou aumento cuidadosamente os pools. Ao mesmo tempo, verifico a utiliza\u00e7\u00e3o da CPU, o or\u00e7amento de mem\u00f3ria e as liga\u00e7\u00f5es ativas, para n\u00e3o obter uma vis\u00e3o isolada. S\u00f3 a intera\u00e7\u00e3o destes <strong>Valores medidos<\/strong> mostra se o pool est\u00e1 a utilizar as alavancas certas.<\/p>\n\n<h2>O ajuste em intera\u00e7\u00e3o com a mem\u00f3ria e as liga\u00e7\u00f5es<\/h2>\n\n<p>Mantenho o buffer pool do InnoDB com dimens\u00e3o suficiente para que os registos mais acessados permane\u00e7am na RAM e a <strong>Disco r\u00edgido<\/strong> n\u00e3o atrasa. Dimensiono o Max_connections de forma realista, porque qualquer reserva para o pior cen\u00e1rio consome RAM e aumenta os riscos de lat\u00eancia. Ao n\u00edvel da aplica\u00e7\u00e3o, prefiro apostar em <a href=\"https:\/\/webhosting.de\/pt\/ligacao-a-base-de-dados-pooling-hosting-poolscale\/\">Agrupamento de liga\u00e7\u00f5es<\/a>, para promover a reutiliza\u00e7\u00e3o e suavizar os picos. Em conjunto com as caches de threads, a sobrecarga de cria\u00e7\u00e3o das liga\u00e7\u00f5es diminui significativamente. Esta combina\u00e7\u00e3o estabiliza o d\u00e9bito, enquanto o <strong>Conjunto de threads<\/strong> que canaliza o paralelismo por vias ordenadas.<\/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\/mariadb_thread_pool_9238.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplo pr\u00e1tico: alojamento partilhado com picos de tr\u00e1fego<\/h2>\n\n<p>Nos clusters de WordPress com elevado tr\u00e1fego, observo padr\u00f5es recorrentes com muitas opera\u00e7\u00f5es curtas de leitura e grava\u00e7\u00e3o. Sem o pool, as mudan\u00e7as de contexto aumentam e a <strong>CPU<\/strong> entra em concorr\u00eancia constante, o que eleva a lat\u00eancia P95 a valores perigosos. Com o \u201epool-of-threads\u201c e um tamanho do pool pr\u00f3ximo do n\u00famero de n\u00facleos, a vari\u00e2ncia diminui significativamente, enquanto os picos de carga ocorrem de forma mais controlada. Os tempos de resposta permanecem mais agrupados nos per\u00edodos de pico, porque o servidor permite que o trabalho seja distribu\u00eddo de forma mais moderada. Ao mesmo tempo, o consumo de mem\u00f3ria por liga\u00e7\u00e3o ativa diminui, o que proporciona um al\u00edvio adicional aos hosts sobrecarregados.<\/p>\n\n<h2>Erros frequentes e medidas de preven\u00e7\u00e3o eficazes<\/h2>\n\n<p>N\u00e3o vou ultrapassar os limites das piscinas s\u00f3 porque, a curto prazo, a fila parece ser menor; isso acaba por se virar contra mim com uma nova <strong>Concorr\u00eancia<\/strong> em termos de tempo de CPU. Quem ignora os stalls perde rapidamente o controlo sob carga, por isso ajusto o `stall_limit` com cuidado. Se as lat\u00eancias continuarem elevadas apesar de haver threads livres, verifico minuciosamente os pontos cr\u00edticos de bloqueio e os comprimentos das transa\u00e7\u00f5es. Para tal, \u00e9 \u00fatil dar uma vista de olhos em <a href=\"https:\/\/webhosting.de\/pt\/bloqueio-de-linhas-na-base-de-dados-otimizacao-da-concorrencia-no-mysql-desempenho-bloqueios\/\">Bloqueio de linhas e concorr\u00eancia<\/a>, pois muitas situa\u00e7\u00f5es de espera surgem longe do conjunto de threads. Al\u00e9m disso, elimino consultas ineficientes antes de otimizar os conjuntos, para n\u00e3o tratar os sintomas em vez das causas.<\/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\/mariadb_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de verifica\u00e7\u00e3o para a entrada em funcionamento<\/h2>\n\n<p>Come\u00e7o por analisar os padr\u00f5es de carga de trabalho e defino objetivos claros em termos de lat\u00eancia e d\u00e9bito. Em seguida, ativo o <strong>Conjunto de threads<\/strong> Com um tamanho de pool conservador, fa\u00e7o medi\u00e7\u00f5es reprodut\u00edveis e documento cada altera\u00e7\u00e3o. Se os valores medidos indicarem gargalos fora do pool, dou prioridade \u00e0 mem\u00f3ria, \u00e0s E\/S e ao planeamento das consultas. S\u00f3 quando estas \u00e1reas estiverem bem definidas \u00e9 que vale a pena fazer o ajuste fino do tamanho do pool, dos limites de estabilidade e das caches. Por fim, guardo a configura\u00e7\u00e3o, automatizo a monitoriza\u00e7\u00e3o e agendo revis\u00f5es peri\u00f3dicas.<\/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\/hosting-serverraum-8421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arquitetura, equidade e defini\u00e7\u00e3o de prioridades<\/h2>\n\n<p>Apostamos no princ\u00edpio de agrupamento do pool, porque equilibra melhor a equidade e o rendimento do que o modelo \u201eum thread por liga\u00e7\u00e3o\u201c. Cada grupo processa uma fila e evita que in\u00fameras consultas de curta dura\u00e7\u00e3o sejam suplantadas por um pequeno n\u00famero de consultas de longa dura\u00e7\u00e3o. Isto compensa especialmente em cargas de trabalho OLTP: as instru\u00e7\u00f5es curtas s\u00e3o processadas rapidamente, enquanto as opera\u00e7\u00f5es de maior dura\u00e7\u00e3o, embora sejam iniciadas com menos frequ\u00eancia, s\u00e3o conclu\u00eddas de forma est\u00e1vel. Internamente, garanto que as solicita\u00e7\u00f5es em espera tenham periodicamente uma oportunidade, para que nenhuma <strong>Fome<\/strong> \u00e9 criada. Esta prioriza\u00e7\u00e3o mant\u00e9m as lat\u00eancias P95\/P99 mais pr\u00f3ximas e impede que determinados utilizadores dominem a m\u00e1quina.<\/p>\n\n<h2>Outros ajustes em pormenor<\/h2>\n\n<p>Para al\u00e9m dos par\u00e2metros principais, utilizo controlos adicionais, consoante a vers\u00e3o, para aperfei\u00e7oar o comportamento. Um limite m\u00e1ximo de threads por grupo restringe os picos de atividade, enquanto um <strong>Tempo limite de inatividade<\/strong> encerra os workers n\u00e3o utilizados, poupando assim mem\u00f3ria. Al\u00e9m disso, verifico as defini\u00e7\u00f5es que atribuem um impulso de prioridade \u00e0s consultas em espera ap\u00f3s um determinado per\u00edodo de tempo, para que as opera\u00e7\u00f5es curtas e de dura\u00e7\u00e3o m\u00e9dia sejam tratadas de forma justa. Para mim, \u00e9 importante: altero sempre apenas uma vari\u00e1vel por ronda de testes e documento os efeitos de forma clara. Assim, evito configura\u00e7\u00f5es que se neutralizem mutuamente ou que reajam de forma imprevis\u00edvel sob carga.<\/p>\n\n<h2>Transa\u00e7\u00f5es, isolamento e conce\u00e7\u00e3o de consultas<\/h2>\n\n<p>O conjunto de threads n\u00e3o substitui um bom desenho de transa\u00e7\u00f5es. Procuro manter as transa\u00e7\u00f5es deliberadamente curtas, encapsulo apenas as instru\u00e7\u00f5es necess\u00e1rias e presto aten\u00e7\u00e3o \u00e0 consist\u00eancia <strong>N\u00edveis de isolamento<\/strong>. Em ambientes com muitas grava\u00e7\u00f5es simult\u00e2neas, reduzo frequentemente a probabilidade de conflitos evitando varreduras que implicam bloqueios, definindo \u00edndices adequados e desagregando \u00abhot rows\u00bb. O REPEATABLE READ continua a ser adequado para muitas cargas de trabalho de CMS\/lojas online; em situa\u00e7\u00f5es de elevada concorr\u00eancia com muitas atualiza\u00e7\u00f5es, o READ COMMITTED resulta, em casos espec\u00edficos, em menos conflitos de bloqueio. Acompanho de perto os efeitos da transi\u00e7\u00e3o, uma vez que a sem\u00e2ntica e o comportamento do cache se alteram. Al\u00e9m disso, utilizo limites de tempo de espera para bloqueios, para que as transa\u00e7\u00f5es bloqueadas n\u00e3o ocupem recursos indefinidamente. As instru\u00e7\u00f5es AUTOCOMMIT curtas continuam a ser a melhor op\u00e7\u00e3o, pois adaptam-se perfeitamente ao comportamento do pool e \u00e0 CPU <strong>pr\u00f3ximo do n\u00facleo<\/strong> utilizar ao m\u00e1ximo.<\/p>\n\n<h2>Replica\u00e7\u00e3o, clusters e topologias<\/h2>\n\n<p>Encararei sempre o pool no contexto da topologia. Nos servidores prim\u00e1rios e de r\u00e9plica, este ajuda a distribuir melhor as opera\u00e7\u00f5es de leitura e grava\u00e7\u00e3o. A replica\u00e7\u00e3o paralelizada beneficia de uma carga de CPU mais uniforme, desde que o disco e a rede n\u00e3o constituam um limita\u00e7\u00e3o. Em configura\u00e7\u00f5es de cluster com replica\u00e7\u00e3o s\u00edncrona, presto especial aten\u00e7\u00e3o ao controlo de fluxo e aos conflitos de certifica\u00e7\u00e3o: o pool uniformiza a execu\u00e7\u00e3o local, mas n\u00e3o resolve conflitos entre n\u00f3s. Por isso, sempre que poss\u00edvel, separo as cargas de relat\u00f3rios e de processamento em lote das cargas de trabalho interativas \u2013 quer em r\u00e9plicas pr\u00f3prias, quer com desfasamento temporal. Isto mant\u00e9m as lat\u00eancias previs\u00edveis para os utilizadores finais e evita que consultas demoradas congestionem as filas do pool.<\/p>\n\n<h2>Sistema operativo, virtualiza\u00e7\u00e3o e NUMA<\/h2>\n\n<p>Para que o pool tenha o efeito pretendido, \u00e9 essencial que a base esteja bem estabelecida. Asseguro atribui\u00e7\u00f5es fixas de CPU e RAM nas m\u00e1quinas virtuais ou nos contentores e evito uma sobre-subscri\u00e7\u00e3o excessiva. Em sistemas NUMA, procuro garantir uma distribui\u00e7\u00e3o uniforme dos grupos de threads e a proximidade em termos de mem\u00f3ria, para que os acessos \u00e0 mem\u00f3ria n\u00e3o causem <strong>Lat\u00eancias<\/strong> aplicar. Defino os perfis de energia para \u201eDesempenho\u201c, de modo a minimizar as mudan\u00e7as de frequ\u00eancia. Dimensiono os descritores de ficheiros, os limites dos processos e os buffers dos sockets de acordo com a carga de liga\u00e7\u00f5es prevista, para que o sistema operativo n\u00e3o se torne um estrangulamento. Este trabalho de base evita que o pool seja responsabilizado por problemas do sistema.<\/p>\n\n<h2>Metodologia de testes de carga e crit\u00e9rios de sucesso<\/h2>\n\n<p>Estou a planear testes de carga com cen\u00e1rios mistos realistas: propor\u00e7\u00f5es de escrita\/leitura, distribui\u00e7\u00e3o de consultas curtas e m\u00e9dias e picos de tr\u00e1fego que a aplica\u00e7\u00e3o realmente gera. Realizo aumentos graduais da carga, mantenho n\u00edveis est\u00e1veis e medo os valores P50\/P95\/P99, e n\u00e3o apenas as m\u00e9dias. Paralelamente, observo a satura\u00e7\u00e3o da CPU, os tempos de espera relacionados com as filas e a propor\u00e7\u00e3o entre threads ativos e threads inativos. Para mim, o sucesso \u00e9 alcan\u00e7ado quando o P95 diminui, a vari\u00e2ncia diminui e a CPU n\u00e3o permanece constantemente no limite. S\u00f3 quando v\u00e1rias repeti\u00e7\u00f5es confirmarem isso \u00e9 que transfiro os valores para a produ\u00e7\u00e3o.<\/p>\n\n<h2>Planeamento da capacidade entre a aplica\u00e7\u00e3o e a base de dados<\/h2>\n\n<p>Eu voto <strong>thread_pool_size<\/strong> Apostar no paralelismo efetivo da aplica\u00e7\u00e3o. Se o PHP-FPM ou os conjuntos de trabalhadores permitirem mil pedidos simult\u00e2neos, mas o servidor da base de dados tiver apenas 16 n\u00facleos, defino limites m\u00e1ximos claros e trabalho com conjuntos de liga\u00e7\u00f5es do lado da aplica\u00e7\u00e3o. Desta forma, evito o efeito \u201eThundering Herd\u201c e mantenho as filas no pool curtas. Ao n\u00edvel do utilizador, gosto de definir <strong>max_user_connections<\/strong>, para evitar que os tenants individuais fiquem desproporcionados. No conjunto, resulta um equil\u00edbrio entre a paraleliza\u00e7\u00e3o das aplica\u00e7\u00f5es, o agrupamento de liga\u00e7\u00f5es e o tamanho do pool da base de dados, que permite uma escalabilidade est\u00e1vel, em vez de se limitar a deslocar os picos de tr\u00e1fego.<\/p>\n\n<h2>Governan\u00e7a, prote\u00e7\u00e3o e padr\u00f5es de erros<\/h2>\n\n<p>Estabele\u00e7o mecanismos de prote\u00e7\u00e3o contra valores at\u00edpicos: tempos m\u00e1ximos por instru\u00e7\u00e3o, tamanhos de pacotes realistas, janelas de lote limitadas. Reconhe\u00e7o padr\u00f5es de erro inesperados pelo facto de os threads inativos se manterem elevados, mas os valores P95\/P99 aumentarem \u2014 nesse caso, procuro causas fora do pool, por exemplo, em E\/S, pesquisas de DNS, jitter de rede ou conte\u00fados de bloqueios. Por outro lado, se observar filas permanentemente cheias com uma carga moderada da CPU, aumentei cuidadosamente o tamanho do pool ou resolvo os pontos de congestionamento nos esquemas. Para mim, tamb\u00e9m \u00e9 importante agendar conscientemente as tarefas de longa dura\u00e7\u00e3o (relat\u00f3rios, tarefas de migra\u00e7\u00e3o) \u2014 seja por intervalos de tempo, em r\u00e9plicas dedicadas ou com prioridade mais baixa \u2014, para que as cargas de trabalho interativas n\u00e3o sejam afetadas.<\/p>\n\n<h2>Estrat\u00e9gia de implementa\u00e7\u00e3o e planos alternativos<\/h2>\n\n<p>Estou a implementar as altera\u00e7\u00f5es na base de dados de forma gradual: primeiro no ambiente de teste com dados representativos, depois numa pequena parte do ambiente de produ\u00e7\u00e3o, com acompanhamento rigoroso. Para situa\u00e7\u00f5es de emerg\u00eancia, tenho preparada uma via de retorno clara \u2013 por exemplo, reverter as altera\u00e7\u00f5es para <strong>gest\u00e3o de threads<\/strong> para \u201eum thread por liga\u00e7\u00e3o\u201c, se a sem\u00e2ntica o permitir \u2013, e documentar os efeitos secund\u00e1rios. As altera\u00e7\u00f5es em pools, caches e limites m\u00e1ximos de liga\u00e7\u00f5es andam, no meu caso, de m\u00e3os dadas, para que nenhum componente se torne subitamente um novo estrangulamento. Esta disciplina evita surpresas e garante que as otimiza\u00e7\u00f5es continuem a surtir efeito mesmo semanas depois.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Eu uso o <strong>Pool de threads do MariaDB<\/strong>, para processar de forma ordenada muitas consultas curtas e reduzir as lat\u00eancias em ambientes de alojamento com elevada carga. O agrupamento adaptativo evita picos de threads, reduz as mudan\u00e7as de contexto e mant\u00e9m a CPU mais produtiva. Com par\u00e2metros adequados, um dimensionamento correto e testes realistas, o mecanismo demonstra a sua efic\u00e1cia de forma fi\u00e1vel. A monitoriza\u00e7\u00e3o de threads, filas, CPU e mem\u00f3ria garante que as otimiza\u00e7\u00f5es se mant\u00eam robustas. Quem, al\u00e9m disso, utilizar o agrupamento de liga\u00e7\u00f5es, valores adequados para max_connections e consultas bem organizadas, consegue sistemas visivelmente mais est\u00e1veis com <strong>Tempos de resposta<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Pool de threads do MariaDB: como esta tecnologia melhora o desempenho em servidores de alojamento com elevada carga de trabalho e contribui para um ajuste eficiente da base de dados.<\/p>","protected":false},"author":1,"featured_media":20509,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20516","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-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":"131","_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":"MariaDB Thread Pool","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":"20509","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20516","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=20516"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20516\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20509"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20516"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20516"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20516"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}