Otimizando o desempenho da criação de cache de mapa no ArcGIS for Server 10.2.1

Eu sou relativamente novo no ArcGIS for Server, então espero que alguém possa me indicar a direção certa, caso o que eu esteja fazendo não seja uma boa prática.

Eu tenho 2 caixas com ArcGIS para servidor 10.2.1, ambas no mesmo site. Ambas as caixas têm 4 processadores e 16GB de RAM. Ambas as caixas são executadas no Windows Server 2008.

O site é usado para fornecer alguns serviços de mapa base para uma pequena quantidade de usuários (<5) e para gerar blocos de cache para serviços futuros.

No momento, estou gerando blocos de cache para um serviço de mapeamento (~ 50 GB). Eu esperava ver o uso da CPU nas 2 caixas rodando bastante alto. Mas tende a ficar entre 15% e 30% em cada caixa.

O máximo de instâncias para as ferramentas de armazenamento em cache é definido como 6.

O número máximo de instâncias por máquina é definido como 3.

Estou errado ao supor que eu deveria estar vendo um uso mais alto da CPU?

Não coloquei as figuras corretas?

Ou minha configuração não é uma prática recomendada? ou seja, devo usar um site apenas para veicular mapas e outro site apenas para cache?

Acho que segui as diretrizes mencionadas aqui e aqui . Mas tenho certeza de que o cache está executando mais lentamente do que deveria. Após 19 horas, ele armazenou apenas 1,17% de todos os meus ladrilhos.

Todas as sugestões de melhores práticas são muito bem-vindas.

ATUALIZAÇÃO: Após 21 horas, o uso da CPU nas duas máquinas é reduzido a zero:

máquina 1:

máquina 2:

A barra "em andamento" do status do cache no servidor ainda está em movimento, mas a porcentagem de cache não aumentou nas últimas 2 horas.

Parece que você fez um bom trabalho ao seguir as práticas recomendadas para criar o cache. Seus servidores têm potência suficiente, mas extrair os dados do mapa do seu banco de dados pode ser um problema. Aqui está um pequeno resumo deste site, com algumas dicas adicionais para obter o máximo retorno do seu investimento.

1 - Analise seu mapa antes de publicá-lo!

Isso pode ser óbvio, mas muitas vezes fui muito rápido para publicar no servidor sem verificar os resultados da análise. Basta ir File->Analyze Mape fazer uma verificação rápida para ver se o seu mapa tem algum problema. Quanto mais rápido o mapa for renderizado, mais rápido ele poderá armazenar em cache.

2 - Mantenha os dados locais

Se você tiver uma implantação em uma única máquina, mantenha os dados do mapa em um local FGDB para o servidor. Se você tiver várias máquinas, permita que cada máquina tenha uma cópia dos dados e use a opção "Usar diretório de cache local ao gerar blocos no servidor" ao configurar o cache.

O link acima tem algumas dicas úteis sobre como lidar com falhas, junto com este script útil que analisa erros de cache em uma área de cobertura de polígono, para que você possa voltar facilmente e tentar re-armazenar em cache as áreas com falha.

Esta questão surge de vez em quando. Talvez possamos obter mais respostas e transformar isso em um Wiki. :)

Outra coisa que você pode fazer é definir os controladores de cache e as ferramentas de cache para um cluster diferente. Isso deve isolar o processo de armazenamento em cache do conjunto regular de processos. Eu já vi isso produzir melhor desempenho isolando o cache das funções regulares do arcgisserver. Eu normalmente chamo esse novo cache de cluster. Então, quando você adicionar novas máquinas à sua instalação, adicione-as ao cluster de armazenamento em cache em relação ao padrão e isso aumentará seu poder de processamento. Além disso, se você vir uma baixa utilização, continue adicionando mais e mais recursos até chegar a cerca de 70 a 80% de utilização. Ainda assim, poderá deixar alguns cavalos de potência para copiar os arquivos e para trás e reduzir a contenção de recursos.

Com base na documentação da ESRI ( http://server.arcgis.com/en/server/latest/publish-services/linux/accelerating-map-cache-creation.htm ), a melhor prática para o número de instâncias a serem usadas no cache é n + 1 onde n é o número de núcleos em execução no servidor. Seus servidores possuem 4 processadores cada e cada processador X5690 possui 6 núcleos, de acordo com a documentação:

http://ark.intel.com/products/52576/Intel-Xeon-Processor-X5690-12M-Cache-3_46-GHz-6_40-GTs-Intel-QPI

Com base nisso, você teoricamente deve ser capaz de lidar com 25 instâncias de cache por servidor. Agora eu sei que o documento da ESRI é para a 10.3, mas essa foi a prática recomendada para as últimas versões.

Eu tenho uma configuração de servidor semelhante e posso dizer que minha CPU chegaria a 100% antes de chegar perto de 25 instâncias, mas posso usar 10 a 15 bastante confortavelmente.

Portanto, se você testou que a E / S de disco ou o banco de dados não são os gargalos, recomendo aumentar o número de instâncias para 10. Se isso não aumentar o uso da CPU, significa que não foi o fator limitante. Se aumentar, mas ainda for razoável, você pode tentar aumentar ainda mais.

De qualquer forma, a moral da história é não se acanhe em pôr em marcha as instâncias. Uma vez, também trabalhei em um servidor com pouca capacidade, com apenas 2 núcleos e 3 instâncias, que me levaram a lugar nenhum. No entanto, quando aumentei as instâncias para 5, o uso da CPU era razoável. A melhor prática é apenas um ponto de partida.