Ciclo de Crash
O site entra num ciclo vicioso de crashes que se repete a cada 1-2 dias. O diagrama seguinte ilustra este ciclo:
flowchart TD
A["Site sem trafego durante ~20 min"] -->|Always On desativado| B["Azure descarrega a aplicacao"]
B --> C["Utilizador acede ao site"]
C --> D["Cold Start: Umbraco reinicia"]
D --> E["Umbraco reconstroi XML cache a partir da BD"]
E --> F["BD tem 870K linhas em cmsPropertyData\n+ 1.6M registos em icUrlTracker"]
F --> G["Reconstrucao da cache demora varios minutos"]
G --> H["Site parece bloqueado/em baixo"]
H --> I["Administrador reinicia o App Service"]
I --> J["Site funciona normalmente"]
J --> K["1-2 dias depois, memoria esgota-se"]
K --> A
style A fill:#ff6b6b,color:#fff
style B fill:#ff6b6b,color:#fff
style G fill:#ff6b6b,color:#fff
style H fill:#ff6b6b,color:#fff
style K fill:#ff6b6b,color:#fff
Pressão de Memória
O worker process em 32-bit limita a aplicação a um máximo de 2 GB de RAM. O Umbraco precisa de manter em memória a cache XML de todos os conteúdos publicados.
pie title "Distribuicao Estimada de Memoria (2 GB max)"
"Umbraco XML Cache" : 45
"Property Data (870K linhas)" : 25
"Runtime .NET + IIS" : 15
"Donut Cache + Sessoes" : 10
"Outros (Hangfire, APIs)" : 5
Detalhes da Pressão de Memória
| Componente |
Impacto na Memória |
Notas |
| Umbraco XML Cache |
Elevado |
Cache completa de 4.468 nós de conteúdo |
| cmsPropertyData |
Elevado |
870.978 linhas (255 MB na BD, mais em memória) |
| Donut Caching |
Médio |
Camada adicional de cache sobre a cache do Umbraco |
| ContentApiController |
Médio |
Chamado em CADA navegação de página |
| Worker 32-bit |
Limitante |
Teto máximo de ~2 GB para tudo |
Fluxo de um Pedido de Pagina
sequenceDiagram
participant U as Utilizador
participant IIS as IIS/App Service
participant DC as Donut Cache
participant API as ContentApiController
participant UC as Umbraco Cache
participant DB as SQL Database
U->>IIS: GET /pagina
IIS->>DC: Verificar Donut Cache
alt Cache hit
DC-->>U: Resposta imediata
else Cache miss
DC->>API: ContentApiController
API->>UC: Pedir conteudo da cache Umbraco
alt Cache XML pronta
UC-->>API: Dados do conteudo
else Cache em reconstrucao (cold start)
UC->>DB: SELECT * FROM cmsPropertyData...
Note over DB: 870K linhas para processar
UC->>DB: Verificar icUrlTracker
Note over DB: 1.6M registos para carregar
DB-->>UC: Dados (demora minutos)
UC-->>API: Dados do conteudo
end
API-->>DC: Resposta
DC-->>U: Resposta (apos espera longa)
end
Problema do ContentApiController
O ContentApiController é invocado em cada navegação de página pelo frontend AngularJS. Este controller depende da cache do Umbraco estar disponível. Quando a cache não está pronta (durante um cold start), cada pedido de página fica bloqueado à espera que a cache seja reconstruída.
Hangfire Desativado
O Hangfire (sistema de tarefas em background) foi desativado propositadamente devido a problemas de memória. Isto confirma que a equipa já tinha conhecimento de que a memória era um problema, mas a causa raiz (32-bit + bloat da BD) não foi resolvida.
flowchart LR
A["Hangfire ativo"] --> B["Consumo adicional de memoria"]
B --> C["Crashes mais frequentes"]
C --> D["Hangfire desativado como workaround"]
D --> E["Problema de memoria persiste"]
E --> F["Causa raiz: 32-bit + BD bloated"]
style D fill:#ffa500,color:#fff
style F fill:#ff6b6b,color:#fff
Métricas-Chave
| Métrica |
Valor Atual |
Valor Normal |
| Nós de conteúdo |
4.468 |
- |
| Linhas em cmsPropertyData |
870.978 |
~30.000-50.000 |
| Registos em icUrlTracker |
1.631.926 |
< 10.000 |
| Versões de conteúdo |
47.485 |
< 10.000 |
| Memória máxima disponível |
2 GB (32-bit) |
8+ GB (64-bit) |
| Application Insights |
Desativado |
Ativo com alertas |
| Always On |
Desativado |
Ativado |
| Frequência de crashes |
A cada 1-2 dias |
Nunca |