{"id":21087,"date":"2026-08-27T18:20:06","date_gmt":"2026-08-27T16:20:06","guid":{"rendered":"https:\/\/webhosting.de\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/"},"modified":"2026-08-27T18:20:06","modified_gmt":"2026-08-27T16:20:06","slug":"zfs-arc-cache-consumo-de-memoria-explicacao-otimizacao-io","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/zfs-arc-cache-speicherverbrauch-erklaerung-tuning-io\/","title":{"rendered":"Cache ARC do ZFS: Compreender corretamente o consumo de mem\u00f3ria"},"content":{"rendered":"<p><strong>ZFS ARC<\/strong> utiliza a RAM de forma intensiva para disponibilizar rapidamente os blocos lidos com frequ\u00eancia, ajustando dinamicamente o consumo real de mem\u00f3ria \u00e0 carga. Vou explicar como interpretar corretamente o consumo aparentemente elevado, quais s\u00e3o os indicadores que importam e como controlar com seguran\u00e7a o tamanho da cache, sem <strong>Desempenho<\/strong> para perder.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Para uma orienta\u00e7\u00e3o r\u00e1pida, resumo as afirma\u00e7\u00f5es mais importantes e destaco palavras-chave essenciais para uma compreens\u00e3o clara <strong>Vis\u00e3o geral<\/strong>.<\/p>\n<ul>\n  <li><strong>Tamanho ARC<\/strong>: Din\u00e2mico, control\u00e1vel atrav\u00e9s de zfs_arc_max\/min<\/li>\n  <li><strong>Recuper\u00e1vel<\/strong>: A mem\u00f3ria RAM de cache \u00e9 libertada imediatamente, sempre que necess\u00e1rio<\/li>\n  <li><strong>Taxa de acerto<\/strong>: Uma elevada taxa de acertos demonstra uma utiliza\u00e7\u00e3o adequada da cache<\/li>\n  <li><strong>L2ARC<\/strong>: Complemento ao SSD\/NVMe, n\u00e3o substitui a RAM<\/li>\n  <li><strong>Regras do conjunto de dados<\/strong>: ajustar com precis\u00e3o a cache prim\u00e1ria\/cache secund\u00e1ria<\/li>\n<\/ul>\n<p>Utilizo estes pontos no dia a dia para manter os percursos de leitura curtos e otimizar a mem\u00f3ria de forma justa <strong>partilhar<\/strong>. Um ARC cheio indica uma utiliza\u00e7\u00e3o ativa e n\u00e3o um defeito ou um problema oculto <strong>Fuga<\/strong>. S\u00f3 quando ocorrem eventos de swapping ou OOM \u00e9 que estabele\u00e7o limites claros. Depois, valido as altera\u00e7\u00f5es com valores de medi\u00e7\u00e3o e ajusto gradualmente o <strong>Moldura<\/strong>. \u00c9 assim que mantenho os sistemas a funcionar sem atrasar outros servi\u00e7os nem tomar decis\u00f5es precipitadas e arriscadas <strong>escolher<\/strong>.<\/p>\n\n<h2>O que o ARC faz realmente na mem\u00f3ria<\/h2>\n\n<p>O ARC \u00e9 uma cache de leitura adaptativa e combina <strong>MRU<\/strong> (utilizado recentemente) com <strong>MFU<\/strong> (utilizado com frequ\u00eancia). Esta combina\u00e7\u00e3o adapta-se automaticamente ao padr\u00e3o gerado pelas minhas cargas de trabalho e mant\u00e9m dispon\u00edveis exatamente os blocos que proporcionam o maior efeito. Desta forma, as lat\u00eancias diminuem sensivelmente, uma vez que os acessos s\u00e3o efetuados diretamente a partir da RAM e n\u00e3o a partir de <strong>placas<\/strong> ou SSDs. Beneficio-me sobretudo em acessos repetitivos, pois a taxa de acertos aumenta a cada resposta correta <strong>Pedido de informa\u00e7\u00e3o<\/strong>. \u00c9 sobretudo no caso de imagens de m\u00e1quinas virtuais, bases de dados e muitos ficheiros pequenos que a cache demonstra todo o seu potencial.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/zfs-arc-cache-5723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>\u00c9 precisamente devido a este modo de funcionamento que a RAM parece \u201echeia\u201c, apesar de eu continuar a <strong>Reservas<\/strong> tenho. A cache ocupada pode ser libertada a qualquer momento, assim que os processos solicitarem mem\u00f3ria. Desta forma, o sistema utiliza ativamente a capacidade ociosa, em vez de a deixar sem uso, e mant\u00e9m, mesmo assim, os picos de carga abaixo de <strong>Controlo<\/strong>. Quem achar interessante uma compara\u00e7\u00e3o direta entre sistemas de ficheiros, pode consultar o meu resumo conciso <a href=\"https:\/\/webhosting.de\/pt\/ext4-xfs-zfs-comparacao-de-desempenho-de-alojamento-armazenamento\/\">Compara\u00e7\u00e3o de desempenho<\/a> . A\u00ed mostro porque \u00e9 que uma cache inteligente, em cargas de trabalho reais, tem frequentemente um impacto mais significativo do que a simples <strong>Teoria<\/strong>.<\/p>\n\n<h2>Por que \u00e9 que o elevado consumo de RAM \u00e9 intencional<\/h2>\n\n<p>Considero positivo o facto de a RAM estar \u201echeia\u201c no ARC, desde que o sistema n\u00e3o esteja a sofrer de uma verdadeira escassez de mem\u00f3ria <strong>sofre<\/strong>. O ZFS liberta imediatamente a mem\u00f3ria em cache \u00e0 medida que as aplica\u00e7\u00f5es crescem e ajusta continuamente o tamanho alvo. Em ferramentas t\u00edpicas, esta RAM aparece como \u201eocupada\u201c, embora esteja dispon\u00edvel para novos processos sem qualquer atraso para a <strong>Disposi\u00e7\u00e3o<\/strong> . Um verdadeiro estrangulamento s\u00f3 se torna evidente atrav\u00e9s do swapping, de atrasos percet\u00edveis ou da atividade do OOM Killer. Para compreender melhor, vale a pena dar uma olhadela em <a href=\"https:\/\/webhosting.de\/pt\/linux-cache-de-paginas-transparente-diferencas-entre-caches-de-paginas-otimizacao-cache-de-dados\/\">Diferen\u00e7as no cache de p\u00e1ginas<\/a>, porque a cache do sistema operativo e o ARC est\u00e3o interligados e ambos influenciam o consumo vis\u00edvel <strong>marcar<\/strong>.<\/p>\n\n<p>O que \u00e9 decisivo \u00e9, portanto, o contexto, e n\u00e3o uma captura de ecr\u00e3 isolada de uma ferramenta de monitoriza\u00e7\u00e3o que indique \u201e0 GB de espa\u00e7o livre\u201c como <strong>Terror<\/strong>. Al\u00e9m disso, verifico os tempos de espera de E\/S, a evolu\u00e7\u00e3o da mem\u00f3ria de swap e os perfis de carga dos principais servi\u00e7os. Se estes valores n\u00e3o apresentarem anomalias, deixo margem ao ARC para maximizar as opera\u00e7\u00f5es de leitura recorrentes <strong>acelerar<\/strong>. Se surgirem dificuldades, aumentei moderadamente os limites m\u00e1ximos, em vez de aplicar o ARC de forma rigorosa <strong>cortar<\/strong>. Desta forma, mant\u00e9m-se o equil\u00edbrio entre os benef\u00edcios do cache e as necessidades da aplica\u00e7\u00e3o.<\/p>\n\n<h2>Como o ZFS determina o tamanho do ARC<\/h2>\n\n<p>Na aus\u00eancia de configura\u00e7\u00f5es, o ZFS estabelece um limite m\u00e1ximo razo\u00e1vel com base no espa\u00e7o dispon\u00edvel <strong>RAM<\/strong>. Controlo esta din\u00e2mica atrav\u00e9s de dois par\u00e2metros: <strong>zfs_arc_max<\/strong> como limite m\u00e1ximo e <strong>zfs_arc_min<\/strong> como limite m\u00ednimo. Se zfs_arc_max estiver definido como 0 ou n\u00e3o estiver definido, o ZFS seleciona automaticamente um intervalo adequado, frequentemente cerca de metade do <strong>mem\u00f3ria<\/strong>. Em picos de carga, o ARC diminui, mas n\u00e3o abaixo do valor zfs_arc_min, para que os blocos importantes permane\u00e7am na RAM. Se definir limites demasiado restritivos, a taxa de acertos diminui e as opera\u00e7\u00f5es de E\/S de leitura voltam com maior frequ\u00eancia para a <strong>Prato<\/strong> de volta.<\/p>\n\n<p>Na pr\u00e1tica, isto significa que: uma grande quantidade de RAM permite um cache de grande dimens\u00e3o, o que \u00e9 muito importante para bases de dados e alojamento de m\u00e1quinas virtuais <strong>obras<\/strong>. Se faltar espa\u00e7o de armazenamento para outros servi\u00e7os, limito deliberadamente o zfs_arc_max e mantenho o zfs_arc_min flex\u00edvel. Fa\u00e7o testes por etapas, observo os efeitos e ajusto com base em valores reais de tend\u00eancia. Desta forma, evito que um pico pontual afete a <strong>Configura\u00e7\u00e3o<\/strong> dominado. A adapta\u00e7\u00e3o gradual conduz a um comportamento fi\u00e1vel, sem surpresas desagrad\u00e1veis <strong>Surpresas<\/strong>.<\/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\/zfs_arc_cache_meeting_3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como interpretar corretamente os indicadores ARC<\/h2>\n\n<p>Para ter uma vis\u00e3o geral, analiso regularmente os indicadores mais importantes e registo as rela\u00e7\u00f5es entre eles numa apresenta\u00e7\u00e3o clara <strong>Tabela<\/strong> de forma constante. Ferramentas como o arcstat ou o arc_summary fornecem dados continuamente, que eu associo ao Pool-I\/O e \u00e0s m\u00e9tricas da aplica\u00e7\u00e3o. Neste contexto, o panorama geral \u00e9 mais importante do que um \u00fanico valor at\u00edpico no <strong>Diagrama<\/strong>. \u00c9 precisamente a rela\u00e7\u00e3o entre acertos e erros que mostra se a cache cobre adequadamente a carga de trabalho. Elevadas taxas de acertos indicam um desempenho est\u00e1vel e percursos de leitura curtos no <strong>RAM<\/strong> l\u00e1.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>\u00cdndice<\/th>\n      <th>Descri\u00e7\u00e3o<\/th>\n      <th>Em que \u00e9 que presto aten\u00e7\u00e3o<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tamanho ARC<\/td>\n      <td>Tamanho atual da cache no <strong>RAM<\/strong><\/td>\n      <td>Aumenta com a carga e encolhe sensivelmente quando necess\u00e1rio<\/td>\n    <\/tr>\n    <tr>\n      <td>ARC c \/ c_max<\/td>\n      <td>Valor-alvo e valor-alvo m\u00e1ximo<\/td>\n      <td>Aproxima\u00e7\u00e3o a c_max com carga elevada, ar em repouso<\/td>\n    <\/tr>\n    <tr>\n      <td>Acertos \/ Erros<\/td>\n      <td>Golos marcados ou falhas desde <strong>In\u00edcio<\/strong><\/td>\n      <td>O n\u00famero de erros de mem\u00f3ria est\u00e1 constantemente elevado? Verifique a carga de trabalho ou a pol\u00edtica de cache<\/td>\n    <\/tr>\n    <tr>\n      <td>Taxa de sucesso<\/td>\n      <td>Visitas em rela\u00e7\u00e3o ao total de acessos em <strong>%<\/strong><\/td>\n      <td>Muitas repeti\u00e7\u00f5es: 80\u201390 % \u00e9 um valor realista; caso contr\u00e1rio, um valor mais baixo<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>A partir destes valores, defino medidas concretas: se a taxa de acertos continuar baixa, apesar de haver mem\u00f3ria RAM livre suficiente, aumento cautelosamente o valor de zfs_arc_max e observo o <strong>Tend\u00eancias<\/strong>. Quando as aplica\u00e7\u00f5es est\u00e3o sob press\u00e3o, reduzo o limite e volto a medir as lat\u00eancias e a carga de E\/S. Se um cache maior n\u00e3o aliviar a carga, isso deve-se frequentemente a um padr\u00e3o de acesso muito aleat\u00f3rio, que prejudica o armazenamento em cache <strong>serve<\/strong>. Nesse caso, outras medidas, como uma melhor localiza\u00e7\u00e3o dos dados ou a divis\u00e3o da carga de trabalho, costumam ter um efeito mais significativo. O simples aumento da mem\u00f3ria cache n\u00e3o resolve todos os <strong>Problema<\/strong>.<\/p>\n\n<h2>Como a ARC toma as suas decis\u00f5es: listas \u00abfantasma\u00bb e adapta\u00e7\u00e3o<\/h2>\n\n<p>Al\u00e9m de <strong>MRU<\/strong> e <strong>MFU<\/strong> o ARC utiliza os chamados <strong>Listas \u00abfantasma\u00bb<\/strong> (MRU\/MFU-Ghost). Cont\u00eam apenas metadados de blocos recentemente deslocados. Se esses mesmos blocos reaparecerem pouco tempo ap\u00f3s terem sido substitu\u00eddos, o ZFS interpreta isso como um ind\u00edcio de que a \u00e1rea correspondente tinha dimens\u00f5es demasiado pequenas e redistribui a capacidade entre o MRU e o MFU. Assim, <strong>aprende<\/strong> A cache ativa a partir de erros de avalia\u00e7\u00e3o. Na pr\u00e1tica, isto significa que os padr\u00f5es vari\u00e1veis (por exemplo, janelas de processamento em lote ao fim da tarde) s\u00e3o melhor atendidos ap\u00f3s alguns ciclos, sem que eu tenha de intervir manualmente.<\/p>\n\n<p>Neste contexto, observo sobretudo se os erros ocorrem em ondas e se, posteriormente, a taxa de acerto aumenta visivelmente <strong>veste<\/strong>. Se isso acontecer, a l\u00f3gica ARC funciona como pretendido. Se o n\u00famero de erros continuar elevado apesar das repeti\u00e7\u00f5es, isso deve-se frequentemente ao facto de o conjunto de trabalho ser maior do que a cache dispon\u00edvel ou de os padr\u00f5es de acesso serem demasiado <strong>aleat\u00f3rio<\/strong>.<\/p>\n\n<h2>Quando \u00e9 que o ARC realmente causa problemas<\/h2>\n\n<p>Em configura\u00e7\u00f5es de alojamento partilhado, partilho a mem\u00f3ria com muitos servi\u00e7os; nesse caso, um ARC dominante pode limitar o espa\u00e7o dispon\u00edvel e provocar o swapping <strong>promover<\/strong>. Os administradores de hosts de virtualiza\u00e7\u00e3o conhecem bem este dilema: cada VM beneficia de mais RAM, enquanto o ZFS tamb\u00e9m pretende utilizar recursos de cache. Em sistemas pequenos, com poucos gigabytes, mantenho os limites mais restritos, para que o tempo de resposta dos servi\u00e7os n\u00e3o fique comprometido <strong>aparelho<\/strong>. Os problemas tornam-se evidentes atrav\u00e9s de aplica\u00e7\u00f5es lentas, do aumento da utiliza\u00e7\u00e3o da mem\u00f3ria de swap ou de alertas do OOM-Killer. Nestas situa\u00e7\u00f5es, defino limites m\u00e1ximos claros e, depois, dou ao sistema alguns dias para <strong>Compara\u00e7\u00f5es<\/strong>.<\/p>\n\n<p>Registo os sintomas, os hor\u00e1rios e as pessoas afetadas <strong>Servi\u00e7os<\/strong>. Se o pico de tr\u00e1fego ocorrer repetidamente nos mesmos intervalos de tempo, planeio medidas como janelas de backup, redu\u00e7\u00e3o da frequ\u00eancia de indexa\u00e7\u00e3o ou o adiamento de varreduras de grande dimens\u00e3o. S\u00f3 quando as medidas organizacionais n\u00e3o conseguirem atenuar o pico \u00e9 que ajusto a tecnologia e os limites <strong>sobre<\/strong>. Esta sequ\u00eancia preserva a margem de manobra e evita interven\u00e7\u00f5es precipitadas em ambientes de produ\u00e7\u00e3o sens\u00edveis. Desta forma, mant\u00e9m-se a vis\u00e3o da intera\u00e7\u00e3o entre a cache, as E\/S e as aplica\u00e7\u00f5es <strong>claro<\/strong>.<\/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\/zfs-arc-cache-speicherverbrauch-verstehen-8237.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Containers, Cgroups e particularidades do NUMA<\/h2>\n\n<p>Em ambientes de contentores, aplica-se o seguinte: o ARC \u00e9 <strong>em todo o servidor<\/strong> e n\u00e3o est\u00e1 limitado pelo cgroup. Se um pod\/contentor atingir o seu limite de mem\u00f3ria, isso n\u00e3o o protege do facto de o anfitri\u00e3o ficar sobrecarregado devido ao ARC e a outros processos. Por isso, prevejo no anfitri\u00e3o uma reserva fixa para servi\u00e7os do sistema e para o ZFS e defino os limites dos contentores de forma a que a RAM f\u00edsica n\u00e3o seja ocupada at\u00e9 ao limite. Em sistemas NUMA, procuro tamb\u00e9m evitar um acesso intenso entre n\u00f3s, pois, caso contr\u00e1rio, as lat\u00eancias aumentam. A distribui\u00e7\u00e3o equilibrada de grandes m\u00e1quinas virtuais e um limite ARC realista por <strong>Anfitri\u00e3o<\/strong> evitam muitas surpresas.<\/p>\n\n<h2>Boas pr\u00e1ticas para o dimensionamento<\/h2>\n\n<p>Em servidores de ficheiros dedicados, costumo atribuir ao ARC 60\u201380 % de RAM, porque os outros processos consomem pouca mem\u00f3ria <strong>procura<\/strong>. Se houver uma pilha de contentores ou servi\u00e7os mais pequenos a funcionar em paralelo, come\u00e7o com 50\u201360 % e observo a carga din\u00e2mica. Nos hipervisores, costumo definir 30\u201340 %, para que as m\u00e1quinas virtuais tenham RAM pr\u00f3pria suficiente <strong>ter<\/strong>. Normalmente, deixo o zfs_arc_min entre 25 e 50 % do zfs_arc_max, para que a cache possa ainda diminuir em picos de carga. Fa\u00e7o as altera\u00e7\u00f5es gradualmente e analiso os valores medidos ao longo de v\u00e1rios dias <strong>de<\/strong>.<\/p>\n\n<p>Prevejo margens de seguran\u00e7a para picos, em vez de fixar o limite m\u00e1ximo ao m\u00ednimo <strong>costurar<\/strong>. Para janelas de escrita, c\u00f3pias de seguran\u00e7a ou reindexa\u00e7\u00e3o, deixo espa\u00e7o de forma deliberada, para que o sistema n\u00e3o entre em swapping sem substitui\u00e7\u00e3o. Ap\u00f3s cada altera\u00e7\u00e3o, verifico se a taxa de acertos continua adequada e se as aplica\u00e7\u00f5es respondem mais rapidamente. Se o desempenho de leitura se mantiver elevado e os estrangulamentos desaparecerem, confirmo os valores e anoto os <strong>Motivo<\/strong>. Esta documenta\u00e7\u00e3o ser\u00e1 de grande ajuda em futuras quest\u00f5es relacionadas com a capacidade.<\/p>\n\n<h2>ARC comprimido e ajuste fino do prefetch<\/h2>\n\n<p>Muitas cargas de trabalho beneficiam do <strong>ARC comprimido<\/strong>: O ZFS mant\u00e9m os dados comprimidos na cache e s\u00f3 os descomprime quando s\u00e3o acedidos. Isto poupa mem\u00f3ria RAM e aumenta a capacidade efetiva da cache. Nesse contexto, mantenho a <strong>CPU<\/strong>-Tendo em conta a carga \u2013 em sistemas muito dependentes da CPU, nem sempre os benef\u00edcios s\u00e3o superiores. Para que fique claro <strong>comprim\u00edvel<\/strong> No caso de dados (registos, texto, imagens de m\u00e1quinas virtuais com pouca entropia), o efeito \u00e9, na maioria das vezes, significativo. Al\u00e9m disso, o <strong>Pr\u00e9-busca do ZFS<\/strong> (zfetch) procura padr\u00f5es sequenciais e pr\u00e9-carrega blocos subsequentes. No caso de leituras longas de fluxos, que de qualquer forma n\u00e3o pretendo armazenar em cache (c\u00f3pias de seguran\u00e7a, pipelines de multim\u00e9dia), configuro o primarycache, tal como descrito, para se concentrar principalmente em metadados e, caso contr\u00e1rio, deixo o zfetch tratar do <strong>Predefini\u00e7\u00f5es<\/strong>. Desativar o prefetch de forma abrupta leva frequentemente a um maior n\u00famero de falhas em cargas mistas e, para mim, \u00e9 a exce\u00e7\u00e3o, n\u00e3o a regra.<\/p>\n\n<h2>Implementar configura\u00e7\u00f5es persistentes de forma segura<\/h2>\n\n<p>Estabele\u00e7o os valores-limite para o ARC <strong>persistente<\/strong>, para que sobrevivam aos rein\u00edcios, e altere-os apenas de forma gradual. Os aumentos n\u00e3o s\u00e3o cr\u00edticos, pois o sistema vai utilizando o espa\u00e7o adicional aos poucos. <strong>Afundamentos<\/strong> podem provocar, temporariamente, um aumento da evic\u00e7\u00e3o e do I\/O \u2013 por isso, reduzo em incrementos de 10\u201320-% e observo durante 24\u201348 horas. Ap\u00f3s grandes altera\u00e7\u00f5es ou atualiza\u00e7\u00f5es do kernel\/ZFS, verifico se os valores continuam a ser plaus\u00edveis, uma vez que as heur\u00edsticas autom\u00e1ticas podem ser afetadas pelas novas vers\u00f5es <strong>Alterar<\/strong>.<\/p>\n\n<h2>Utilizar o L2ARC de forma inteligente<\/h2>\n\n<p>O L2ARC em SSD\/NVMe amplia a cache e proporciona um aumento not\u00e1vel, especialmente no caso de grandes volumes de dados que se prestam bem \u00e0 cache <strong>Impulso<\/strong>. S\u00f3 o utilizo quando os valores medidos indicam que o RAM-ARC est\u00e1 a funcionar constantemente no limite e que o lado Flash ainda tem margem. Importante: o L2ARC n\u00e3o substitui a RAM, pois os metadados dos blocos armazenados em cache t\u00eam de ficar no ARC principal <strong>ficar<\/strong>. Por isso, um L2ARC muito grande aumenta as necessidades de RAM e, se a configura\u00e7\u00e3o n\u00e3o for adequada, pode at\u00e9 causar um abrandamento do sistema. A grava\u00e7\u00e3o no L2ARC consome largura de banda de E\/S e <strong>CPU<\/strong>, isso n\u00e3o me escapa.<\/p>\n\n<p>O L2ARC funciona bem quando a carga de trabalho \u00e9 superior \u00e0 mem\u00f3ria RAM, mas diz respeito repetidamente a ficheiros semelhantes, como imagens de VM ou muitos ficheiros pequenos <strong>objetos<\/strong>. Antes da expans\u00e3o, verifico, atrav\u00e9s das estat\u00edsticas de E\/S, se a parti\u00e7\u00e3o Flash tem capacidade livre e n\u00e3o est\u00e1, de qualquer forma, no limite. Se estas condi\u00e7\u00f5es estiverem reunidas, o L2ARC proporciona frequentemente lat\u00eancias consistentemente mais baixas. S\u00f3 a combina\u00e7\u00e3o de uma monitoriza\u00e7\u00e3o rigorosa, uma reserva de RAM adequada e um L2ARC devidamente dimensionado proporciona o resultado esperado <strong>Efeito<\/strong>. A adi\u00e7\u00e3o indiscriminada de SSDs de maior capacidade raramente resolve verdadeiros pontos de estrangulamento.<\/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\/ZFS_ARC_Cache_Office_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detalhes do L2ARC: fase de aquecimento e persist\u00eancia<\/h2>\n\n<p>O L2ARC possui um <strong>Fase de aquecimento<\/strong>: Imediatamente ap\u00f3s a sua cria\u00e7\u00e3o ou ap\u00f3s um rein\u00edcio, o L2ARC est\u00e1 inicialmente vazio ou ainda n\u00e3o est\u00e1 totalmente operacional. As implementa\u00e7\u00f5es modernas podem manter os metadados de forma persistente, para que o L2ARC volte a estar operacional mais rapidamente <strong>obras<\/strong>. No entanto, o preenchimento demora algum tempo e consome largura de banda de E\/S. N\u00e3o limito o feed desnecessariamente, mas deixo reservas suficientes para as cargas de trabalho prim\u00e1rias. Particularmente importante: o L2ARC n\u00e3o deve sobrecarregar os mesmos SSDs que as cargas de trabalho de registo ou transacionais. Dispositivos pr\u00f3prios de baixa lat\u00eancia e uma percentagem de RAM calculada de forma realista para o L2ARC-<strong>Cabe\u00e7alho<\/strong> s\u00e3o obrigat\u00f3rios.<\/p>\n\n<h2>Defini\u00e7\u00f5es do conjunto de dados: primarycache e secondarycache<\/h2>\n\n<p>Limpo a cache atrav\u00e9s das op\u00e7\u00f5es do conjunto de dados, para que o ARC e o L2ARC apresentem os conte\u00fados corretos <strong>manter<\/strong>. O `primarycache` controla se os dados e\/ou metadados se encontram no ARC principal, enquanto o `secondarycache` define os conte\u00fados para o L2ARC. No caso de fluxos sequenciais de grande dimens\u00e3o (por exemplo, arquivos multim\u00e9dia), muitas vezes basta manter os metadados no ARC e n\u00e3o armazenar o fluxo de dados propriamente dito no <strong>Tamp\u00e3o<\/strong>. Em cargas de trabalho com grande volume de metadados, guardo em cache os dados e os metadados para reduzir as lat\u00eancias. Esta separa\u00e7\u00e3o evita o desperd\u00edcio e refor\u00e7a os elementos relevantes <strong>Acessos<\/strong>.<\/p>\n\n<p>Testo cada conjunto de dados de forma espec\u00edfica, em vez de aplicar a mesma regra de forma generalizada a todos os conjuntos <strong>definir<\/strong>. Uma configura\u00e7\u00e3o correta do primarycache\/secondarycache reduz as opera\u00e7\u00f5es de E\/S desnecess\u00e1rias e aumenta a taxa de acertos. Em suma, isto resulta frequentemente num comportamento mais est\u00e1vel do sistema, com tempos de resposta mais previs\u00edveis. Tamb\u00e9m neste caso se aplica o seguinte: medir, ajustar, repetir <strong>medida<\/strong>. S\u00e3o frequentemente os pequenos ajustes que d\u00e3o aquele toque final decisivo.<\/p>\n\n<h2>Caso espec\u00edfico da desduplica\u00e7\u00e3o (DDT) e necessidades de RAM<\/h2>\n\n<p>Ativar <strong>Desduplica\u00e7\u00e3o<\/strong>, a necessidade de mem\u00f3ria aumenta sensivelmente, porque a tabela de deduplica\u00e7\u00e3o (DDT) tem de ser mantida na RAM para se manter eficiente. Por cada bloco \u00fanico s\u00e3o gerados metadados; com tamanhos de bloco t\u00edpicos, isso soma rapidamente v\u00e1rios gigabytes. Se a RAM n\u00e3o for suficiente, o ZFS transfere os acessos \u00e0 DDT para os discos, o que aumenta as lat\u00eancias e ocupa espa\u00e7o na ARC. A minha regra geral: ativar a deduplica\u00e7\u00e3o apenas onde haja garantia de elevada redund\u00e2ncia (por exemplo, VDI, imagens de VM id\u00eanticas) e espa\u00e7o suficiente <strong>RAM<\/strong> est\u00e1 dispon\u00edvel. Caso contr\u00e1rio, \u00e9 <strong>Compress\u00e3o<\/strong> muitas vezes, \u00e9 claramente a melhor alavanca.<\/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\/zfs_arc_cache_9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e resolu\u00e7\u00e3o de problemas<\/h2>\n\n<p>Para garantir um funcionamento tranquilo, verifico continuamente o tamanho da ARC, a taxa de acertos, os perfis de E\/S e os par\u00e2metros a n\u00edvel do sistema <strong>Carga de armazenamento<\/strong>. Se o ARC se mantiver constantemente no limite, sem que as aplica\u00e7\u00f5es sejam afetadas, deixo-lhe espa\u00e7o. Se observar swapping ou sinais de que se est\u00e1 a aproximar do OOM, limito o limite e analiso as principais causas. Al\u00e9m disso, \u00e9 \u00fatil dar uma vista de olhos em <a href=\"https:\/\/webhosting.de\/pt\/vm-vfs-pressao-do-cache-linux-ajuste-do-cache-do-sistema-de-ficheiros-otimizacao\/\">vm.vfs_cache_pressure<\/a>, para determinar a rela\u00e7\u00e3o entre a cache de dentry\/inode e a mem\u00f3ria restante <strong>equil\u00edbrio<\/strong>. Eu analiso os valores no seu contexto, nunca isoladamente.<\/p>\n\n<p>Ferramentas como o arcstat\/arc_summary, o zpool, o iostat, bem como o top\/htop\/free\/vmstat fornecem-me as informa\u00e7\u00f5es necess\u00e1rias <strong>ind\u00edcios<\/strong>. Comparo os picos com as janelas de trabalho e verifico se os problemas s\u00e3o reproduz\u00edveis. Se o gargalo se repetir, ajusto as janelas de tempo, as restri\u00e7\u00f5es ou os limites da cache. Se a curva se nivelar e as aplica\u00e7\u00f5es continuarem r\u00e1pidas, mantenho a <strong>Defini\u00e7\u00e3o<\/strong>. \u00c9 assim que vou acumulando experi\u00eancias ao longo de semanas e meses, em vez de reagir apenas a momentos pontuais.<\/p>\n\n<h2>Distinguir entre ARC, Dirty Data e ZIL\/SLOG<\/h2>\n\n<p>Para se ter uma vis\u00e3o global, \u00e9 importante referir que, para al\u00e9m do ARC, tamb\u00e9m <strong>Dados incorretos<\/strong> (blocos alterados, ainda n\u00e3o gravados nos discos) ocupam mem\u00f3ria RAM. Esta \u00e1rea cresce at\u00e9 um limite m\u00e1ximo e \u00e9 depois esvaziada de forma ass\u00edncrona. Sob uma carga de grava\u00e7\u00e3o elevada, os \u00abDirty Data\u00bb podem atingir valores elevados a curto prazo e abrandar o sistema, antes de o ZFS reagir com mecanismos de limita\u00e7\u00e3o. Al\u00e9m disso, o <strong>ZIL<\/strong> (Registo de Inten\u00e7\u00f5es do ZFS) Grava\u00e7\u00f5es s\u00edncronas; um SLOG r\u00e1pido ajuda, mas n\u00e3o reduz o consumo de RAM do ARC. Distingo claramente estes aspetos: lat\u00eancias de grava\u00e7\u00e3o percet\u00edveis, apesar de uma boa taxa de acertos, indicam frequentemente estrangulamentos relacionados com dados sujos ou com o registo, em vez de um <strong>ARC<\/strong> l\u00e1.<\/p>\n\n<h2>Metodologia de medi\u00e7\u00e3o: intervalos de tempo e an\u00e1lise de tend\u00eancias<\/h2>\n\n<p>Uma vez que muitos contadores do ZFS s\u00e3o cumulativos desde o <strong>Barco<\/strong> Quando as execu, analiso-as numa janela di\u00e1ria ou semanal. Calculo taxas (acertos\/s, falhas\/s) e comparo-as com os tempos de espera de E\/S e a carga da CPU. Ap\u00f3s altera\u00e7\u00f5es de configura\u00e7\u00e3o significativas, \u201ezerar\u201c os meus valores de compara\u00e7\u00e3o ou assinalo o momento em que estas ocorreram, para que os efeitos possam ser atribu\u00eddos com clareza. Avalio a taxa de acertos por janela de carga de trabalho (hor\u00e1rio de pico de produ\u00e7\u00e3o, janela noturna, execu\u00e7\u00f5es em lote) \u2013 caso contr\u00e1rio, um \u00fanico valor global ocultaria os verdadeiros <strong>Gargalos de garrafa<\/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\/zfs-arc-serverraum-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplo pr\u00e1tico: servidor multifuncional com 64 GB de RAM<\/h2>\n\n<p>Um servidor misto com aplica\u00e7\u00f5es web, base de dados e c\u00f3pias de seguran\u00e7a chega rapidamente aos 30\u201340 GB sem um ajuste fino <strong>ARC<\/strong>. No entanto, a base de dados necessita de bastante mem\u00f3ria RAM pr\u00f3pria, pelo que defino o zfs_arc_max para cerca de 24\u201328 GB e o zfs_arc_min para 8\u201312 GB. Ap\u00f3s alguns dias, verifico uma redu\u00e7\u00e3o na utiliza\u00e7\u00e3o da mem\u00f3ria de troca e lat\u00eancias mais est\u00e1veis, enquanto os dados utilizados com frequ\u00eancia continuam na cache <strong>mentira<\/strong>. O sistema parece mais \u00e1gil, porque os picos de tr\u00e1fego j\u00e1 n\u00e3o ocorrem simultaneamente na base de dados e no ARC. Este limita\u00e7\u00e3o moderada mant\u00e9m o rendimento e melhora sensivelmente o tempo de resposta no <strong>atividades di\u00e1rias<\/strong>.<\/p>\n\n<p>No passo seguinte, otimizo os conjuntos de dados: no caso de grandes c\u00f3pias de seguran\u00e7a sequenciais, reduzo a propor\u00e7\u00e3o de dados puros no ARC e dou prioridade aos metadados <strong>para<\/strong>. A taxa de acertos continua a ser satisfat\u00f3ria e, ao mesmo tempo, a press\u00e3o sobre a RAM diminui durante os per\u00edodos noturnos. Ap\u00f3s a conclus\u00e3o das altera\u00e7\u00f5es, vou acompanhar a evolu\u00e7\u00e3o atrav\u00e9s do sistema de monitoriza\u00e7\u00e3o e s\u00f3 intervirei caso se verifique uma situa\u00e7\u00e3o persistente de <strong>Tend\u00eancias<\/strong>. A estabilidade a longo prazo supera os indicadores de refer\u00eancia a curto prazo em ambientes produtivos. Assim, a cache continua a ser uma fonte de lucros e n\u00e3o um motivo de alarme ou de medidas dr\u00e1sticas <strong>Estrangulamento<\/strong>.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Interpreto o elevado consumo de mem\u00f3ria do ARC como um sinal de atividade <strong>Use<\/strong> e n\u00e3o como uma falha. O ZFS liberta a cache quando necess\u00e1rio, enquanto os par\u00e2metros zfs_arc_max e zfs_arc_min definem claramente o intervalo <strong>Definir<\/strong>. As configura\u00e7\u00f5es s\u00f3 se tornam significativas quando acompanhadas de indicadores adequados, como a taxa de acertos, o tamanho do ARC e os perfis de E\/S. O L2ARC e as op\u00e7\u00f5es de conjuntos de dados proporcionam-me mais recursos quando a RAM escasseia ou quando os volumes de dados s\u00e3o significativamente maiores <strong>s\u00e3o<\/strong>. Quem seguir estes princ\u00edpios b\u00e1sicos conseguir\u00e1 utilizar o ZFS de forma r\u00e1pida, econ\u00f3mica e fi\u00e1vel a longo prazo <strong>Tempo de resposta<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda como funciona a cache ARC do ZFS, por que raz\u00e3o um elevado consumo de RAM \u00e9 normal e como ajustar corretamente o consumo de mem\u00f3ria para melhorar o desempenho do ZFS.<\/p>","protected":false},"author":1,"featured_media":21080,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21087","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":"157","_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":"ZFS ARC","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":"21080","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21087","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=21087"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21087\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21080"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21087"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21087"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21087"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}