Componentes e threads para distribuição de conteúdo
Este artigo ajuda você a entender os componentes e threads para distribuição de conteúdo.
Versão original do produto: ramificação atual do Configuration Manager, 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 principais componentes usados para distribuição de conteúdo:
Nome | Nome de componente | Nome amigável | Descrição |
---|---|---|---|
Gerente 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 |
Gerenciador 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 |
Desbobinador | SMS_DESPOOLER | Desbobinador | 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 em busca de 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 do Configuration Manager em um site |
Provedor de DP de SMS | Provedor de DP de 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 de agente cliente do Configuration Manager que também hospeda componentes do lado do servidor, como Ponto de Gerenciamento e Ponto de Distribuição de Pull |
Serviço de transferência de dados | Serviço de Transferência de Dados | DTS | O Serviço de Transferência de Dados é um componente do CcmExec responsável pelo download de arquivos via BITS. |
Threads do Gerenciador de Distribuição (DistMgr)
O Gerenciador de Distribuição (DistMgr) executa uma variedade de operações para distribuir conteúdo para os pontos de distribuição (DPs). Essas operações são tratadas pelos diferentes tipos de threads e o diagrama abaixo explica a hierarquia de threads DistMgr para a configuração de thread padrão:
Thread principal do DistMgr
Entrada de registro para identificação:
SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER as thread ID 3648 (0xE40)
Este thread é iniciado na
SMS_Executive
inicialização do serviço. O thread principal do DistMgr inicia o processamento de replicação, o Gerenciador de DP, a limpeza de conteúdo, o monitoramento de certificado DP, a movimentação da biblioteca de conteúdo, o processamento de alterações de configuração do IIS, a reatribuição de DP e os threads de processamento de atualização quando ele é iniciado. Ele também inicia threads de processamento de pacotes sob demanda quando ocorre uma alteração de pacoteAlém de gerenciar esses threads, esse thread também lida com alterações no Arquivo de Controle do Site e atualiza as configurações do DP (definir DP/PXE, atualizar configurações do Registro, criar tarefas de monitoramento/uso no DP e assim por diante).
Thread de processamento de replicação
Entrada de registro para identificação:
Starting thread for processing replication, thread ID = 0x1A14 (6676)
Esse thread é iniciado pelo thread principal do DistMgr e processa
DistMgr.box\incoming
os seguintes arquivos no diretório:Arquivo Descrição . STA Atualiza o status do PkgStatus
pacote na tabela no banco de dados.. FWD Encaminha o pacote especificado para o site de destino especificado criando um minitrabalho para enviar o pacote. . DMD Distribui solicitações sob demanda. Direciona o pacote especificado para o DP especificado. . PUL Atualiza a resposta do PullDPResponse
pacote DP pull na tabela no banco de dados.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 registro para identificação:
Starting the DP Manager thread, thread ID = 0x5D8 (1496)
Esse thread é iniciado pelo thread principal do DistMgr e processa a remoção de DPs ao detectar uma alteração no Arquivo de Controle de Site. Quando ocorre uma alteração apropriada no 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 por Action = 3 na
DistributionPoints
tabela).Observação
Esse thread é de thread único e não cria mais threads para executar o trabalho.
Tópico de limpeza de conteúdo
Entrada de registro para identificação:
Starting the content cleanup thread, thread ID = 0x1604 (5636)
Esse thread é iniciado pelo thread principal do 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 de lote padrão de 50 para o número de conteúdo que ele 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 registro para identificação:
Starting the DP cert monitoring thread, thread ID = 0x7290 (29328)
Esse thread é iniciado pelo thread principal do DistMgr. Este tópico processa . CER e configura a associação de certificado no IIS quando o modo HTTP avançado está habilitado. Esse modo requer o uso de certificados gerados pelo Configuration Manager no IIS.
Observação
Esse thread é de thread único e não cria mais threads para executar o trabalho.
Tópico de movimentação da biblioteca de conteúdo
Entrada de registro para identificação:
Starting the content library move thread, thread ID = 0x11D6C (73068)
Esse thread é iniciado pelo thread principal do DistMgr e move a biblioteca de conteúdo para o novo local após um . O arquivo CML é colocado 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ções de configuração do IIS
Entrada de registro para identificação:
Starting the IIS config change processing thread, thread ID = 0x408C (16524)
Esse thread é iniciado pelo thread principal do DistMgr e manipula a configuração de diretórios virtuais do IIS para pontos de distribuição padrão e pull depois que os arquivos do IIS são soltos no
DistMgr.box
. Esse thread lê aIISConfigChangeThreadLimit
propriedade SCF (Arquivo de Controle de Site) doSMS_DISTRIBUTION_MANAGER
componente para determinar o número de threads que ele pode iniciar para executar alterações do IIS simultaneamente. O valor padrão daIISConfigChangeThreadLimit
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 paraIISConfigChangeThreadLimit
.Observação
Esse thread cria mais threads para executar alterações de configuração do DP IIS. Cada thread de trabalho lida com a configuração de diretórios virtuais do IIS de um DP específico.
Thread de reatribuição de DP
Entrada de registro para identificação:
Starting the shared DP reassignment thread, thread ID = 0x9C0C (39948)
Esse thread é iniciado pelo thread principal do DistMgr e lida com reatribuições de DP para pontos de distribuição padrão e pull quando um . DPU é solto no
DistMgr.box
arquivo . Esse thread lê aSharedDPImportThreadLimit
propriedade SCF (Arquivo de Controle de Site) doSMS_DISTRIBUTION_MANAGER
componente para determinar o número de threads que ele pode iniciar para executar reatribuições de DP simultaneamente. O valor padrão daSharedDPImportThreadLimit
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 paraSharedDPImportThreadLimit
.Observação
Esse thread cria mais threads para executar reatribuições de DP. Cada thread de trabalho lida com a reatribuição de um DP específico.
Atualizar thread de processamento
Entrada de registro para identificação:
Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)
Esse thread é iniciado pelo thread principal do DistMgr e lida com instalações e atualizações de DP para pontos de distribuição padrão e pull. Ele chama
spGetDPsForUpgrade
para obter uma lista de DPs que precisam ser atualizados. Esse thread lê aDPUpgradeThreadLimit
propriedade SCF (Arquivo de Controle de Site) doSMS_DISTRIBUTION_MANAGER
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 daDPUpgradeThreadLimit
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 paraDPUpgradeThreadLimit
.Observação
Este thread cria mais threads para executar o trabalho de instalação/atualização do DP. Cada thread de trabalho lida com a instalação/atualização de um DP específico.
Segmento de processamento de embalagens
Entrada de registro para identificação:
Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)
Esses threads são iniciados pelo thread principal do DistMgr. O número de threads de processamento de pacotes é determinado pela configuração Número máximo de threads de pacotes nas propriedades 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 pacotes sejam executados simultaneamente, eles são responsáveis por hash e compactação da origem do pacote. Há uma seção crítica em torno da compactação, o que significa que apenas um thread pode compactar o conteúdo por vez. Se vários pacotes novos e grandes forem criados e distribuídos, os threads por pacote poderão ser bloqueados em uma cadeia aguardando sua vez de obter o bloqueio de compactação.
Dependendo das ações do pacote (adicionar/atualizar/excluir), cada thread de processamento de pacote também cria:
- 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 remoto a 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 pacotes cria mais threads para executar o trabalho. Cada thread de trabalho lida com operações de adição/atualização/remoção para os DPs.
Configuração de thread do Gerenciador de Distribuição
Todos os sites do 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 pontos de distribuição (DPs). 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. Aqui está uma olhada na configuração padrão:
Na maioria dos casos, você só estaria preocupado com as configurações Número máximo de pacotes e Máximo de threads por pacote .
- Número máximo de pacotes: Especifica o número máximo de pacotes que o ConfigMgr pode enviar para os DPs simultaneamente. O valor especificado deve estar entre 1 e 50.
- Máximo de threads 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 de Número máximo de pacotes=3 e Máximo de threads por pacote=5 também pode ser chamada de 3x5. É assim que a configuração do thread será frequentemente indicada 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 se decompõe, 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 pacote é gerado pelo thread principal do DistMgr. Esse thread de processamento de pacotes usa um dos 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 - DistMgr não inicia vários threads de processamento de pacote para o mesmo pacote. Isso significa que três pacotes exclusivos utilizarão três threads de processamento de pacotes 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 por DistMgr, PkgXferMgr usa um thread. A configuração de thread de 3x5 significa que a capacidade de envio do PkgXferMgr está definida como 15, o que significa que o PkgXferMgr não pode trabalhar em mais de 15 trabalhos simultaneamente, limitando-o a um máximo de 15 threads.
Quanto tempo dura um thread
Threads DistMgr
A finalidade de um thread DP é criar um trabalho para o Gerenciador de Transferência de Pacotes, que faz a cópia real do conteúdo para o DP. Os threads DP são concluídos após a criação do 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 definir uma configuração agressiva de thread para acelerar a distribuição de conteúdo. Em vez de definir valores agressivos, procure Escolhendo os valores corretos (mais informações abaixo).
Threads PkgXferMgr
Para DPs padrão, como os threads PkgXferMgr executam o trabalho real de enviar o 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 enfileirar um grande número de trabalhos para PkgXferMgr, criando uma lista de pendências de trabalhos na fila.
Para DPs pull, os threads PkgXferMgr notificam o DP pull, solicitando que o DP pull baixe o conteúdo. Como resultado, o tempo de vida dos threads PkgXferMgr para DPs pull é curto. PkgXferMgr inicia outro thread para executar a sondagem de DP pull (com base no intervalo de sondagem configurado) para verificar o progresso do trabalho. No entanto, esta também é uma operação rápida e esses fios também têm uma vida útil curta.
Escolhendo os valores certos
Para determinar os valores apropriados para essas configurações, primeiro você precisa entender a hierarquia do Configuration Manager. Vamos considerar o seguinte ambiente hipotético do Configuration Manager:
- Site da administração central: CS1
- Site primário: PS1
- Número de pontos de distribuição regulares reportados 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 for encerrado, outro thread DP será gerado e o processo continuará até que todos os DPs sejam processados. Esse processo levará algum tempo para percorrer todos os 200 DPs.
Para otimizar isso, primeiro precisamos fazer algumas perguntas:
- Quantos pacotes você prevê serem adicionados/atualizados/distribuídos simultaneamente em média?
- 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 o máximo de threads por pacote como 200, permitindo que o Configuration Manager envie até cinco pacotes para todos os 200 DPs simultaneamente. No entanto, isso significa que quando há mais do que a carga média, podemos criar até 1000 threads, o que é muitos threads. Mais threads geralmente são bons, mas nem sempre, pois o trabalho que está sendo executado também depende de configurações de hardware e rede. Muitas threads às vezes podem causar gargalos e retardar as coisas em vez de melhorá-las.
A coisa mais importante a lembrar ao definir 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é 5x50 , dependendo do hardware/rede), o que ainda permite que o Configuration Manager processe até 100 DPs simultaneamente para cinco pacotes diferentes. Com essas configurações, o número máximo de threads que podem ser gerados durante a alta carga não excederá 500.
Observação
Como diretriz geral, recomenda-se que o número total de threads não exceda 750. Isso significa que você pode definir a configuração do thread para 3x250, 5x150, 10x75 e assim por diante.
Na mesma hierarquia, você pode se deparar com 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 para algo como 50x10 que é 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 para 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; Ele varia para cada ambiente e deve ser definido após entender seu ambiente e requisitos. Lembre-se sempre de encontrar um equilíbrio!
Configuração do thread do remetente
Cada site do 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 conectar a um site, o remetente usa a rota de replicação de arquivos até 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 sites do Configuration Manager permitem que você configure 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 . Aqui está uma olhada na 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 quando restritos pelo valor máximo especificado em Por site.
Por site: o número máximo de comunicações simultâneas permitidas para um único site de destino. 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 isto 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 alocar 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 o Configuration Manager transfira mais arquivos ao mesmo tempo. O aumento desse número também aumenta a demanda de largura de banda de rede entre os sites.
Escolha os valores certos
Para determinar os valores apropriados para essas configurações, primeiro você precisa entender a hierarquia do Configuration Manager. Vamos considerar o seguinte ambiente hipotético do Configuration Manager:
- Site da administração central: CS1
- Site primário: PS1
- Site primário: PS2
- Site principal: 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 4 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, não deixando espaço para enviar dados simultaneamente para PS4. Neste ponto, o remetente terá que esperar que um dos 5 threads existentes seja concluído antes de enviar mais dados. Quando um thread existente for concluído, o Sender poderá usar outro thread para enviar mais dados para os sites PS2/PS3/PS4.
Recomenda-se reservar 10 threads para cada site com o qual o remetente se comunicará. Nesse caso, o site CS1 pode se comunicar com quatro outros sites, o que significa que um valor Por site de 10 para quatro sites exigirá a configuração do valor 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
No Configuration Manager, você pode definir um agendamento e definir configurações de limitação específicas para pontos de distribuição remotos, bem como para rotas de replicação de arquivos para sites. Os controles de agendamento e limitação para o ponto de distribuição remoto 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 do Site -> DP), as configurações de limitação são definidas nas propriedades de um ponto de distribuição padrão que não está em um servidor do site.
Para o componente Remetente (para Servidor< de Site-Servidor> de Site), as configurações de limitação são definidas nas propriedades da rota de replicação de arquivo em Replicação de arquivo de configuração>de hierarquia.
Observação
As configurações de hora são baseadas no fuso horário do site de envio, não no ponto de distribuição.
Opções de agendamento
Para restringir os dados, selecione o período de tempo e, em seguida, selecione uma das seguintes configurações de disponibilidade:
Aberto para todas as prioridades: especifica que o Configuration Manager envia dados para o ponto de distribuição sem restrições.
Permitir prioridade média e alta: especifica que o Configuration Manager envia apenas dados de prioridade média e alta para o ponto de distribuição.
Permitir somente alta prioridade: especifica que o Configuration Manager envia apenas dados de alta prioridade para o ponto de distribuição.
Fechado: especifica que o Configuration Manager não envia dados para o ponto de distribuição.
Você pode restringir os 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. É possível escolher um das seguintes opções:
- Ilimitado ao enviar para este destino: especifica que o 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 que são enviados para o ponto de distribuição. Você também pode especificar um retardo de tempo entre o envio de cada bloco de dados. Use essa opção quando precisar enviar dados por meio de 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 de seu uso em um determinado momento.
- Limitado às 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 a porcentagem de tempo que você configurar. Quando você usa essa opção, 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 quando os dados não são enviados. Por exemplo, se a taxa máxima for definida como 50%, o Configuration Manager transmitirá dados por um período de tempo seguido por um período igual de tempo em que nenhum dado será enviado. A quantidade de tamanho real de dados ou o tamanho do bloco de dados não é gerenciado. 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 no Configuration Manager.
Como isso afeta os threads Sender e PkgXferMgr
Quando o controle de largura de banda estiver habilitado para um site, o componente remetente ignorará a configuração do 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, o PkgXferMgr ignorará a configuração do thread e usará apenas um thread para o DP.
Observação
Isso se aplica mesmo se o Limite da largura de banda disponível (%) está definido como 100%.
Quando o controle de largura de banda estiver em vigor, PkgXferMgr.log registrará uma destas linhas:
Agendamento:
~O 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 de pulso:
~Addres a DPNAME.CONTOSO.COM está atualmente 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.