Componentes e threads para distribuição de conteúdo

Este artigo ajuda você a entender componentes e threads para distribuição de conteúdo.

Versão original do produto: Configuration Manager branch atual, Microsoft System Center 2012 Configuration Manager, Microsoft System Center 2012 R2 Configuration Manager

Os componentes usados para distribuição de conteúdo

Aqui está uma lista rápida dos componentes primários usados para distribuição de conteúdo:

Nome	Nome do componente	Nome amigável	Descrição
Gerenciador de Distribuição	SMS_DISTRIBUTION_MANAGER	DistMgr	Gerencia conteúdo e cria trabalhos para PkgXferMgr
Gerenciador de Transferência de Pacote	SMS_PACKAGE_TRANSFER_MANAGER	PkgXferMgr	Transfere pacotes para pontos de distribuição
Manager de Hierarquia	SMS_HIERARCHY_MANAGER	Hman	Processa e replica alterações na hierarquia do site
Remetente	SMS_SENDER	Remetente	Inicia comunicações entre sites em redes TCP/IP
Despooler	SMS_DESPOOLER	Despooler	Processa arquivos de replicação de entrada de sites pai ou filho
Agendador	SMS_SCHEDULER	Agendador	Cria trabalhos de remetente
Monitor de Notificação de Banco de Dados	SMS_DATABASE_NOTIFICATION_MONITOR	SmsDbMon	Observa o banco de dados para obter alterações em determinadas tabelas e cria arquivos nas caixas de entrada dos componentes responsáveis pelo processamento dessas alterações
Provedor de SMS	Provedor de SMS	SMSProv	Provedor WMI (Instrumentação de Gerenciamento do Windows) que atribui acesso de leitura e gravação ao banco de dados Configuration Manager em um site
Provedor de DP sms	Provedor de DP sms	SMSDPProv	Provedor WMI (Instrumentação de Gerenciamento do Windows) que gerencia operações da Biblioteca de Conteúdo no DP
Host do Agente SMS	Host do Agente SMS	CcmExec	O Host do Agente SMS é o serviço Configuration Manager agente cliente que também hospeda componentes do lado do servidor, como Ponto de Gerenciamento e Ponto de Distribuição pull
Serviço de Transferência de Dados	DataTransferService	DTS	O Serviço de Transferência de Dados é um componente do CcmExec responsável por baixar arquivos via BITS.

Threads do DistMgr (Distribution Manager)

O DistMgr (Gerenciador de Distribuição) executa uma variedade de operações para distribuir conteúdo para os DPs (pontos de distribuição). Essas operações são tratadas pelos diferentes tipos de threads e o diagrama abaixo explica a hierarquia de thread DistMgr para a configuração de thread padrão:

• Thread DistMgr principal

  Entrada de log para identificação: SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER as thread ID 3648 (0xE40)

  Esse thread é iniciado pela SMS_Executive inicialização do serviço. O thread DistMgr main inicia o processamento de replicação, o DP Manager, a limpeza de conteúdo, o monitoramento de certificados DP, a movimentação da biblioteca de conteúdo, o processamento de alterações de configuração do IIS, a reatribuição do DP e a atualização dos threads de processamento quando ele é iniciado. Ele também inicia threads de processamento de pacote sob demanda quando ocorre uma alteração de pacote

  Além de gerenciar esses threads, esse thread também lida com alterações no Arquivo de Controle de Site e atualiza as configurações de DP (configure DP/PXE, atualize as configurações do registro, crie tarefas de monitoramento/uso no DP e assim por diante).

• Thread de processamento de replicação

  Entrada de log para identificação: Starting thread for processing replication, thread ID = 0x1A14 (6676)

  Esse thread é iniciado pelo thread DistMgr main e processa os seguintes arquivos no DistMgr.box\incoming diretório:

  Arquivo	Descrição
  . STA	Atualizações pacote status na PkgStatus tabela no banco de dados.
  . FWD	Encaminha o pacote especificado para o site de destino especificado criando um mini-trabalho para enviar o pacote.
  . DMD	Distribui solicitações sob demanda. Direciona o pacote especificado para o DP especificado.
  . PUL	Atualizações pull DP package response in the PullDPResponse table in the DB.

  Observação

  Esse thread é de thread único e não cria mais threads para processar nenhum desses arquivos.

• Thread do Gerenciador de DP

  Entrada de log para identificação: Starting the DP Manager thread, thread ID = 0x5D8 (1496)

  Esse thread é iniciado pelo thread DistMgr main e processa a remoção de DPs ao detectar uma alteração do Arquivo de Controle de Site. Quando ocorre uma alteração apropriada do Arquivo de Controle de Site, o SMSDBMON descarta um arquivo DPN (Notificação DP) que DistMgr.box é processado por esse thread.

  Os arquivos DPN são usados para notificar uma alteração de DP, que envolve a remoção de DP (detectada pela Ação = 3 na DistributionPoints tabela).

  Observação

  Esse thread é de thread único e não cria mais threads para executar o trabalho.

• Thread de limpeza de conteúdo

  Entrada de log para identificação: Starting the content cleanup thread, thread ID = 0x1604 (5636)

  Esse thread é iniciado pelo main thread DistMgr e executa a limpeza de conteúdo. Ele determina se a limpeza de conteúdo é necessária detectando conteúdo órfão do banco de dados. Esse thread usa o tamanho padrão do lote de 50 para o número de conteúdo que pode instruir um DP remoto a excluir por vez. No entanto, esse valor pode ser substituído definindo a seguinte chave do registro:

  SMS\Components\SMS_DISTRIBUTION_MANAGER\RemoteContentCleanupBatchSize

  O valor DWORD pode estar entre 1 e 500.

  Observação

  Não altere esse valor sem consultar o profissional de suporte da Microsoft. Esse thread é de thread único e não cria mais threads para executar o trabalho.

• Thread de monitoramento de certificado DP

  Entrada de log para identificação: Starting the DP cert monitoring thread, thread ID = 0x7290 (29328)

  Esse thread é iniciado pelo thread DistMgr main. Esse thread processa . Cer arquivos e configura a associação de certificado no IIS quando o modo HTTP aprimorado está habilitado. Esse modo requer o uso de certificados gerados Configuration Manager no IIS.

  Observação

  Esse thread é de thread único e não cria mais threads para executar o trabalho.

• Thread de movimentação da biblioteca de conteúdo

  Entrada de log para identificação: Starting the content library move thread, thread ID = 0x11D6C (73068)

  Esse thread é iniciado pelo thread DistMgr main e move a biblioteca de conteúdo para o novo local após um . O arquivo CML é descartado em DistMgr.box.

  Observação

  Esse thread é de thread único e não cria mais threads para executar o trabalho.

• Thread de processamento de alteração de configuração do IIS

  Entrada de log para identificação: Starting the IIS config change processing thread, thread ID = 0x408C (16524)

  Esse thread é iniciado pelo thread DistMgr main e manipula a configuração de diretórios virtuais do IIS para pontos de distribuição padrão e pull depois que os arquivos IIS são descartados em DistMgr.box. Este thread lê a IISConfigChangeThreadLimit propriedade SCF (Arquivo de Controle de Site) para SMS_DISTRIBUTION_MANAGER o componente para determinar o número de threads que ele pode iniciar para executar alterações do IIS simultaneamente. O valor padrão da IISConfigChangeThreadLimit propriedade SCF é 50, mas pode ser alterado, se necessário. No entanto, se essa propriedade SCF não existir por algum motivo, o valor padrão de 50 será usado para IISConfigChangeThreadLimit.

  Observação

  Esse thread cria mais threads para executar alterações de configuração do IIS DP. Cada thread de trabalho manipula a configuração de diretórios virtuais do IIS de um DP específico.

• Thread de reatribuição de DP

  Entrada de log para identificação: Starting the shared DP reassignment thread, thread ID = 0x9C0C (39948)

  Esse thread é iniciado pelo thread DistMgr main e manipula as reatribuções de DP para pontos de distribuição padrão e pull quando um . O arquivo DPU é descartado em DistMgr.box. Este thread lê a SharedDPImportThreadLimit propriedade SCF (Arquivo de Controle de Site) para SMS_DISTRIBUTION_MANAGER o componente para determinar o número de threads que ele pode iniciar para executar reatribuções de DP simultaneamente. O valor padrão da SharedDPImportThreadLimit propriedade SCF é 50, mas pode ser alterado, se necessário. No entanto, se essa propriedade SCF não existir por algum motivo, o valor padrão de 50 será usado para SharedDPImportThreadLimit.

  Observação

  Esse thread cria mais threads para executar reatribuções de DP. Cada thread de trabalho manipula a reatribução de um DP específico.

• Atualizar thread de processamento

  Entrada de log para identificação: Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)

  Esse thread é iniciado pelo thread main DistMgr e manipula instalações de DP e atualizações para pontos de distribuição padrão e pull. Ele chama spGetDPsForUpgrade para obter uma lista de DPs que precisam ser atualizados. Este thread lê a DPUpgradeThreadLimit propriedade SCF (Arquivo de Controle de Site) para SMS_DISTRIBUTION_MANAGER o componente para determinar o número de threads que ele pode iniciar para executar instalações/atualizações de DP simultaneamente. O valor padrão da DPUpgradeThreadLimit propriedade SCF é 50, mas pode ser alterado, se necessário. No entanto, se essa propriedade SCF não existir por algum motivo, o valor padrão de 5 será usado para DPUpgradeThreadLimit.

  Observação

  Esse thread cria mais threads para executar o trabalho de instalação/atualização de DP. Cada thread de trabalho manipula a instalação/atualização de um DP específico.

• Thread de processamento de pacotes

  Entrada de log para identificação: Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)

  Esses threads são iniciados pelo thread DistMgr main. O número de threads de processamento de pacotes é determinado pelo número máximo de pacotes de configuração de thread nas propriedades de Configuração do Componente de Distribuição de Software . Cada thread de processamento de pacote executa o hash do conteúdo do pacote e cria uma cópia compactada do conteúdo.

  Observação

  Embora todos os threads de processamento de pacote sejam executados simultaneamente, eles são responsáveis pelo hash e pela origem do pacote de compactação. Há uma Seção Crítica em torno da compactação, o que significa que apenas um thread pode estar compactando conteúdo por vez. Se um monte de pacotes novos e grandes forem criados e distribuídos, os threads por pacote poderão bloquear em uma cadeia aguardando sua vez para obter o bloqueio de compactação.

  Dependendo das ações do pacote (adicionar/atualizar/excluir), cada thread de processamento de pacotes também cria:

  • Threads DP para criar um trabalho do Gerenciador de Transferência de Pacotes para adicionar/atualizar conteúdo em um DP.
  • Threads DP para instruir um ponto de distribuição remota para remover conteúdo da biblioteca de conteúdo.

  O número de threads DP que cada thread de processamento de pacote pode criar é determinado pela configuração máximo de threads por pacote nas propriedades configuração do componente de distribuição de software .

  Observação

  Os threads de processamento de pacotes são multi threaded e cada thread de processamento de pacote cria mais threads para executar o trabalho. Cada thread de trabalho manipula operações de adicionar/atualizar/remover para os DPs.

Configuração de thread do Distribution Manager

Todos os sites Configuration Manager (incluindo o site de administração central) permitem configurar o número de threads que podem ser usados para distribuir conteúdo para os DPs (pontos de distribuição). Essa configuração é específica para cada site e pode ser acessada clicando com o botão direito do mouse no site no nó Sites e selecionando Configurar Distribuição de Software de Componentes> do Site. Veja a configuração padrão:

Na maioria dos casos, você só estaria preocupado com o número máximo de pacotes e threads máximos por configurações de pacote.

• Número máximo de pacotes: especifica o número máximo de pacotes que ConfigMgr podem enviar para os DPs simultaneamente. O valor especificado deve estar entre 1 e 50.
• Threads máximos por pacote: especifica o número máximo de threads atribuídos a cada pacote durante a distribuição. O valor especificado deve estar entre 1 e 999.

A configuração padrão do número máximo de pacotes=3 e threads máximos por pacote=5 também pode ser chamada de 3x5. É assim que a configuração do thread será frequentemente denotada no fluxo de trabalho.

O que isso realmente significa

Efeito no Gerenciador de Distribuição (DistMgr)

Com a configuração de thread padrão de 3x5, o DistMgr pode processar simultaneamente três pacotes e usar até cinco threads para cada pacote, permitindo que ele use até um total de 15 threads para executar o trabalho. Veja como isso é interrompido supondo que tenhamos mais de três pacotes que precisam ser distribuídos para mais de 5 DPs:

Para processar cada pacote individual, um thread de processamento de pacotes é gerado pelo thread DistMgr main. Esse thread de processamento de pacote usa um em cada três slots de processamento de pacotes da configuração número máximo de pacotes . Há um thread de processamento de pacote exclusivo por pacote – o DistMgr não inicia vários threads de processamento de pacotes para o mesmo pacote. Isso significa que três pacotes exclusivos utilizarão três threads de processamento de pacote exclusivos. Cada um desses threads de processamento de pacotes pode gerar até cinco threads DP para distribuir o pacote para cinco DPs simultaneamente.

Efeito no Gerenciador de Transferência de Pacotes (PkgXferMgr)

Para cada trabalho PkgXferMgr criado pelo DistMgr, PkgXferMgr usa um thread. A configuração de thread de 3x5 significa que a capacidade de envio de PkgXferMgr está definida como 15, o que significa que pkgXferMgr não pode funcionar em mais de 15 trabalhos simultaneamente, limitando-a a um máximo de 15 threads.

Quanto tempo um thread é executado

Threads DistMgr

A finalidade de um thread DP é criar um trabalho para o Gerenciador de Transferência de Pacotes, que, em seguida, faz a cópia de conteúdo real para o DP. Os threads DP terminam depois de criar o trabalho PkgXferMgr e, como resultado, o tempo de vida de um thread DP é curto. Devido a essa natureza, na maioria das vezes não há necessidade de configurar uma configuração de thread agressiva para acelerar a distribuição de conteúdo. Em vez de definir valores agressivos, procure escolher os valores certos (mais informações abaixo).

Threads PkgXferMgr

Para DPs padrão, uma vez que os threads PkgXferMgr executam o trabalho real de envio do conteúdo, o tempo de vida desses threads depende do tamanho dos pacotes. Para pacotes maiores, esses threads podem levar muito tempo, dependendo do tamanho do pacote e da velocidade da rede. Embora esses threads possam levar muito tempo para serem concluídos, o tempo de vida dos threads DistMgr é muito menor, o que significa que o DistMgr pode fazer fila em um grande número de trabalhos para PkgXferMgr, criando um backlog de trabalhos na fila.

Para pull DPs, os threads PkgXferMgr notificam o DP pull, solicitando que o pull DP baixe o conteúdo. Como resultado, o tempo de vida dos threads PkgXferMgr para DPs pull é curto. PkgXferMgr inicia outro thread para executar a votação pull DP (com base no intervalo de votação configurado) para marcar sobre o progresso do trabalho. No entanto, essa também é uma operação rápida e esses threads também têm um tempo de vida curto.

Escolhendo os valores certos

Para determinar os valores apropriados para essas configurações, primeiro você precisa entender a hierarquia Configuration Manager. Vamos considerar o seguinte ambiente hipotético Configuration Manager:

• Site de administração central: CS1
• Site primário: PS1
• Número de pontos de distribuição regulares relatando ao PS1: 200
• Número total de pacotes: 1000

Nesse ambiente, a configuração de thread padrão (3x5) significa que, se um novo pacote precisar ser distribuído para todos os 200 DPs, processaremos apenas 5 DPs por vez. Depois que um thread DP sair, outro thread DP será gerado e o processo continuará até que todos os DPs sejam processados. Esse processo levará algum tempo para fazer loop em todos os 200 DPs.

Para otimizar isso, primeiro precisamos fazer algumas perguntas:

1. Quantos pacotes você prevê ser adicionado/atualizado/distribuído simultaneamente em uma média?
2. Quantos DPs você tem no site? Como é a configuração de rede entre o servidor do site e esses DPs?

Supondo que a resposta para a primeira pergunta seja 5 e a resposta para a segunda pergunta seja 200 com boa conectividade de rede, você poderia teoricamente definir o número máximo de pacotes como 5 e Threads máximos por pacote para 200, permitindo que Configuration Manager envie até cinco pacotes para todos os 200 DPs simultaneamente. No entanto, isso significa que, quando houver mais do que a carga média, podemos criar até 1000 threads, o que é muitos threads. Geralmente, mais threads são bons, mas nem sempre, pois o trabalho que está sendo executado também depende de configurações de hardware e rede. Muitos threads às vezes podem causar gargalos e retardar as coisas em vez de melhorá-los.

A coisa mais importante a ser lembrada ao configurar essas configurações é encontrar um equilíbrio. Para o exemplo acima, uma opção razoável seria definir a configuração do thread como 5x100 (ou até mesmo 5x50 dependendo do hardware/rede) que ainda permite que Configuration Manager processe até 100 DPs simultaneamente para cinco pacotes diferentes. Com essas configurações, o número máximo de threads que podem gerar durante a alta carga não excederá 500.

Observação

Como diretriz geral, é recomendável que o número total de threads não exceda 750. Isso significa que você pode definir a configuração do thread como 3x250, 5x150, 10x75 e assim por diante.

Na mesma hierarquia, você pode encontrar uma situação em que está trazendo um novo DP no ambiente e precisa distribuir todos os 1000 pacotes para o DP. Nesse caso, a configuração de thread de 5x100 não será eficaz, pois só podemos processar 5 pacotes por vez e o processamento de 1000 pacotes levará um tempo considerável. Nesse cenário, você pode optar por:

• Defina temporariamente a configuração do thread como algo como 50x10 mais adequado para o requisito atual, mas não é uma boa opção a longo prazo, considerando que temos 200 DPs.
• Defina permanentemente a configuração do thread como algo como 20x25 que fornece um equilíbrio muito melhor e oferecerá desempenho semelhante em um cenário em que mais pacotes precisam ir para um punhado de DPs, bem como um cenário em que um punhado de pacotes precisa ir para muitos DPs.

Importante

Não há uma recomendação definida sobre valores para configuração de thread; ela varia para cada ambiente e deve ser definida depois de entender seu ambiente e requisitos. Lembre-se sempre de encontrar um equilíbrio!

Configuração do thread do remetente

Cada site Configuration Manager (incluindo o site de administração central e sites secundários) tem um remetente. O remetente gerencia a conexão de rede de um site para um site de destino e pode estabelecer conexões com vários sites ao mesmo tempo. Para se conectar a um site, o remetente usa a rota de replicação de arquivo para o site para identificar a conta a ser usada para estabelecer a conexão de rede. O remetente também usa essa conta para gravar dados no compartilhamento do site de SMS_SITE destino.

Por padrão, o remetente grava dados em um site de destino usando vários threads simultâneos. Cada thread simultâneo pode transferir um objeto baseado em arquivo diferente para o site de destino. Por padrão, quando o remetente começa a enviar um objeto, ele continua a gravar blocos de dados para esse objeto até que todo o objeto seja enviado.

Todos os Configuration Manager sites permitem configurar o número de threads que podem ser usados pelo componente Remetente para enviar dados simultaneamente para outros sites. Essa configuração é específica para cada site e pode ser acessada nas Propriedades do Site no nó Sites selecionando a guia Remetente . Veja a configuração padrão:

Todos os sites: o número máximo de comunicações simultâneas permitidas para este remetente. O valor padrão é 5. Essas comunicações podem ser destinadas a sites diferentes ou todos para o mesmo site, exceto restritos pelo valor máximo especificado em Por site.

Por site: o número máximo de comunicações simultâneas permitidas a qualquer site de destino único. O valor padrão é 3.

Observação

Ao configurar o número total de threads de envio simultâneos a serem usados ao se comunicar com outros sites, o número total de threads de envio deve ser configurado como um número maior do que os threads configurados para a configuração por site. Se o número total de threads de envio for igual ao número configurado para ser usado por site e um site de recebimento não estiver disponível, isso poderá fazer com que todos os threads de envio sejam usados ao tentar se comunicar com o site indisponível e impedir a comunicação site a site com outros sites.

O que isso significa

O valor especificado em Todos os sites define o número total de threads que o Remetente pode usar para enviar dados simultaneamente para outros sites. Do número total de threads para Todos os sites, você pode distribuir um número máximo de threads em Por site que podem ser usados para enviar dados para qualquer site de destino. Por padrão, cada site é configurado para usar cinco threads simultâneos, com três disponíveis para uso ao enviar dados para qualquer site de destino. Ao aumentar esse número, você pode aumentar a taxa de transferência de dados entre sites, permitindo que Configuration Manager transfira mais arquivos ao mesmo tempo. Aumentar esse número também aumenta a demanda por largura de banda de rede entre sites.

Escolha os valores certos

Para determinar os valores apropriados para essas configurações, primeiro você precisa entender a hierarquia de Configuration Manager. Vamos considerar o seguinte ambiente hipotético Configuration Manager:

• Site de administração central: CS1
• Site primário: PS1
• Site primário: PS2
• Site primário: PS3
• Site primário: PS4

Nesse ambiente, a configuração padrão do thread do Remetente permitirá o uso de um total de 5 threads. Desses 5 threads, 3 podem ser usados para qualquer um dos quatro sites primários de destino. Se um administrador enviar 3 para todos esses sites, é possível que o remetente acabe usando três threads para um desses sites (digamos PS1), deixando apenas 2 threads para os sites restantes. Dos 2 threads restantes, o remetente pode usar 1 para PS2 e o outro para PS3 utilizando todos os cinco threads permitidos sem espaço para enviar dados simultaneamente para PS4. Neste ponto, o Remetente terá que aguardar a conclusão de um dos 5 threads existentes antes que ele possa enviar mais dados. Depois que um thread existente for concluído, o Remetente poderá usar outro thread para enviar mais dados para os sites PS2/PS3/PS4.

É recomendável reservar 10 threads para cada site com o qual o Remetente se comunicará. Nesse caso, o site do CS1 pode se comunicar com outros quatro sites, o que significa que um valor por sitede 10 para quatro sites exigirá a configuração do valor de Todos os sites como 40.

Observação

Essa é uma recomendação geral e esses valores podem exigir ajustes adicionais dependendo do número de pacotes que um site precisa enviar simultaneamente para outros sites.

Controle de largura de banda e threads

Em Configuration Manager, você pode configurar um agendamento e definir configurações de limitação específicas para pontos de distribuição remotas, bem como para rotas de replicação de arquivos para sites. Os controles para agendamento e limitação para o ponto de distribuição remota são semelhantes às configurações de um endereço de remetente padrão, mas, nesse caso, as configurações são usadas por um componente chamado Gerenciador de Transferência de Pacotes.

Para o componente Gerenciador de Transferência de Pacotes (para Servidor de Site – >DP), as configurações de limitação são configuradas nas propriedades para um ponto de distribuição padrão que não está em um servidor de site.

Para o componente Remetente (para Servidor de<Site-Site> Server), as configurações de limitação são configuradas nas propriedades da rota de replicação de arquivo emReplicação de Arquivo de Configuração> de Hierarquia.

Observação

As configurações de tempo são baseadas no fuso horário do site de envio, não no ponto de distribuição.

Agendar opções

Para restringir os dados, selecione o período de tempo e selecione uma das seguintes configurações para disponibilidade:

• Abra para todas as prioridades: especifica que Configuration Manager envia dados para o ponto de distribuição sem restrições.

• Permitir prioridade média e alta: especifica que Configuration Manager envia apenas dados de média e alta prioridade para o ponto de distribuição.

• Permitir somente prioridade alta: especifica que Configuration Manager envia apenas dados de alta prioridade para o ponto de distribuição.

• Fechado: especifica que Configuration Manager não envia dados para o ponto de distribuição.

  Você pode restringir dados por prioridade ou fechar a conexão para períodos de tempo selecionados.

Opções de limite de taxa

Isso é usado para configurar limites de taxa para controlar a largura de banda de rede que está em uso ao transferir conteúdo para o ponto de distribuição. Você pode escolher uma das seguintes opções:

• Ilimitado ao enviar para este destino: especifica que Configuration Manager envia conteúdo para o ponto de distribuição sem restrições de limite de taxa.
• Modo de pulso: especifica o tamanho dos blocos de dados enviados para o ponto de distribuição. Você também pode especificar um atraso de tempo entre o envio de cada bloco de dados. Use essa opção quando precisar enviar dados em uma conexão de rede de baixa largura de banda para o ponto de distribuição. Por exemplo, você pode ter restrições para enviar 1 KB de dados a cada cinco segundos, independentemente da velocidade do link ou seu uso em um determinado momento.
• Limitado a taxas de transferência máximas especificadas por hora: especifique essa configuração para que um site envie dados para um ponto de distribuição usando apenas o percentual de tempo configurado. Quando você usa essa opção, Configuration Manager não identifica a largura de banda disponível das redes, mas divide o tempo que pode enviar dados em fatias de tempo. Em seguida, os dados são enviados por um curto bloco de tempo, que é seguido por blocos de tempo em que os dados não são enviados. Por exemplo, se a taxa máxima for definida como 50%, Configuration Manager transmitirá dados por um período de tempo seguido por um período igual de tempo em que nenhum dado é enviado. A quantidade real de dados ou tamanho do bloco de dados não é gerenciada. Em vez disso, somente a quantidade de tempo durante a qual os dados são enviados é gerenciada.

Para obter mais informações sobre essas configurações, consulte Configurando o Gerenciamento de Conteúdo em Configuration Manager.

Como isso afeta threads Sender e PkgXferMgr

Quando o controle de largura de banda estiver habilitado para um site, o componente do remetente ignorará a configuração de thread do Remetente para o site e usará apenas um thread para esse site. Da mesma forma, quando o controle de largura de banda estiver habilitado para um DP, pkgXferMgr ignorará a configuração do thread e usará apenas um thread para o DP.

Observação

Isso se aplica mesmo quando o limite de largura de banda disponível (%) é definido como 100%.

Quando o controle de largura de banda estiver em vigor, PkgXferMgr.log registrará uma dessas linhas:

Agendamento:

~Endereço para DPNAME.CONTOSO.COM está atualmente sob controle de largura de banda, portanto, apenas uma conexão é permitida, retornando a solicitação de envio para o pool.

Modo Pulse:

~Addres to DPNAME.CONTOSO.COM no momento está no modo de pulso, portanto, apenas uma conexão é permitida.
~Abandonando a solicitação de envio porque apenas uma conexão é permitida no modo de pulso.

Sender.log mostrará entradas semelhantes quando a limitação de largura de banda estiver configurada.