Descobri acidentalmente que, quando o React é renderizado no servidor, quando Node_env! = Produção, isso causará vazamentos de memória. Questões específicas: https://github.com/facebook/react/issues/7406. Com o uso generalizado de nó e reação isomorfismo e outras tecnologias, questões como vazamento de memória do lado do nó devem atrair nossa atenção. Por que o nó está propenso a vazamentos de memória e como solucionar problemas depois que ocorre? A seguir, é apresentada uma breve introdução e exemplo.
Primeiro de tudo, o Node é baseado no mecanismo V8 e seu método de gerenciamento de memória é consistente com o V8. A seguir, é apresentada uma breve introdução aos efeitos relevantes da memória do V8.
V8 Limite de memória
O Node é construído no V8 e pode alocar e gerenciar objetos JS através do V8. O V8 possui limitações no uso da memória (cerca de 1,4g para a geração antiga do sistema de 64 bits de memória, cerca de 0,7g para o sistema de 32 bits, cerca de 32 MB para a nova geração de sistema de 64 bits de memória e cerca de 16 MB para o sistema de 32 bits). Sob tais restrições, grandes objetos de memória não poderão operar. Se esse limite for acidentalmente tocado, o processo sairá.
Causa: V8 bloqueia a lógica do aplicativo JavaScript ao executar a coleta de lixo e, em seguida, reexeca a lógica do aplicativo JavaScript até que a coleção de lixo termine. Esse comportamento é chamado de "Stop-the World". Se a memória de heap de V8 for de 1,5 GB, é preciso mais de 50ms para o V8 fazer uma pequena coleta de lixo e leva mais de 1 segundo para uma coleta de lixo não incremental.
Defina a memória de nova geração e a memória antiga para quebrar o limite de memória padrão definindo o nó-max-antn-scace-size = xxx (unidade MB) e o nó-max-new-space-size = xxx (unidade kb).
V8 composição da pilha
O heap V8 não é realmente composto de duas partes: a geração antiga e a nova geração. A pilha pode ser dividida em várias regiões diferentes:
GC Tipo de reciclagem
GC incremental
Indica se o coletor de lixo coleta (acrescenta) lixo ao digitalizar espaço de memória e limpa o lixo no final do ciclo de varredura.
GC não incremental
Ao usar um coletor de lixo não incremental, o lixo está vazio assim que for coletado.
O coletor de lixo realizará apenas a coleta de lixo para a área de memória de nova geração, a área do ponteiro da geração antiga e a área de dados da antiga geração. O objeto primeiro entra na memória de nova geração que ocupa menos espaço. A maioria dos objetos falhará rapidamente e o GC não incremental recicla diretamente essas pequenas quantidades de memória. Se alguns objetos não puderem ser reciclados por um período de tempo, eles serão inseridos na área de memória da antiga geração. Esta área executa o GC incremental pouco frequente e leva muito tempo.
Então, quando ocorrerá o vazamento de memória?
Caminhos de vazamento de memória
A composição da memória do nó é principalmente a parte alocada através do V8 e a parte alocada pelo próprio nó. A principal limitação da coleção de lixo do V8 é a memória da heap do V8. Os principais motivos dos vazamentos de memória: 1. Cache; 2. O consumo de filas não é oportuno; 3. Escopo não liberado
Análise de vazamento de memória
Verifique o uso da memória V8 (byte unitária)
process.MemoryUSAGE (); {Ress: 47038464, Heaptotal: 34264656, HOUPUSED: 2052866}RESS: a parte da memória residente do processo
PELAPTOTAL, HOUPUSUSENHA: V8 Heap Memory Information
Verifique o uso da memória do sistema (byte de unidade)
os.totalmem()
OS.FREEMEM ()
Retorna a memória total do sistema e a memória ociosa
Visualize o registro de coleta de lixo
Node -Trace_GC -e "var a = []; para (var i = 0; i <1000000; i ++) {a.push (nova matriz (100);}" >> gc.log // saída de coleta de lixo Log de coleta de lixo
Node --prof // OUTRONHO DE EXECUÇÃO DO Nó de saída Log. Use Windows-Tick.processor para visualizar.
Ferramentas de monitoramento analítico
O V8-Profiler captura instantâneos da memória V8 e analisa a CPU
Node-Heapdump pega instantâneos de memória de heap V8
Uso da pilha de análise de nó-mate
Node-Memwatch ouve a situação de coleta de lixo
Nó-Memwatch
memwatch.on ('estatísticas', function (info) {console.log (info)}) memwatch.on ('vazamento', function (info) {console.log (info)})Evento de estatísticas: Cada vez que uma coleção de lixo de heap é realizada, o evento STATS será acionado. Este evento passará estatísticas de memória.
{"num_full_gc": 17, // Quantas coleta de lixo de pilha completa "num_inc_gc": 8, // Quantas vezes a coleta de lixo incremental "heap_compactions": 8, // quantas vezes a geração antiga é classificada "estimativa_base": 2592568, // a estimativa " 2499912, // Mínimo "Max": 2592568, // Máximo "USAGE_TREND": 0 // Trendência do usuário}Observe num_full_gc e num_inc_gc refletem a coleta de lixo.
Evento de vazamento: se a memória ainda não for liberada após 5 coleções consecutivas de lixo, isso significa que os vazamentos de memória ocorrem. Desta vez, um evento de vazamento será acionado.
{Start: sex, 29 de junho de 2012 14:12:13 GMT, fim: sex, 29 de junho de 2012 14:12:33 GMT, crescimento: 67984, razão: 'Crescimento da pilha em 5 GCs consecutivos (20s) - 11,67 Mb/hr'}Amete a mistura de memória de heap
Abaixo, usamos um exemplo para demonstrar como solucionar problemas de memória:
Primeiro, criamos um exemplo que causa vazamentos de memória:
//ppp.jsvar app = requer ('expresso') (); var http = requer ('http'). servidor (app); var heapdump = requer ('heapdump'); var vaziobjs = []; function; <1000; function () {console.log ('escuta na porta 3000');});Aqui simulamos vazamentos de memória configurando uma matriz que está aumentando constantemente e não recupera.
Use o módulo HEAP-DUMP para gravar instantâneos de memória regularmente e importar instantâneos através dos perfis de ferramentas do desenvolvedor do Chrome para comparação e análise.
Podemos ver que, depois que o navegador acessa localhost: 3000 e atualiza muitas vezes, o tamanho do instantâneo tem crescido e, mesmo que não seja solicitado, não diminui, indicando que ocorreu um vazamento.
Em seguida, importamos instantâneos através dos perfis da ferramenta de desenvolvedor do Chrome. Ao definir a comparação, compare o instantâneo inicial, envie solicitações e envie solicitações para enviar instantâneos de memória nesses três estágios. Você pode descobrir que a Classe de Classificação tem aumentado no novo à direita. Sempre positivo no Delta, significa que não foi reciclado.
resumo
Para vazamentos de memória, você pode usar o MemWatch para implantar ou relatar o processo.
Quando os vazamentos de memória são encontrados, se permitidos, você pode executar o Node-Heapdump localmente e usar instantâneos de memória cronometrados a serem gerados. E use o instantâneo para analisar a causa do vazamento através dos perfis do Chrome. Se a depuração local não for possível, use o V8-Profiler para produzir instantâneos de memória no servidor de teste para comparar e analisar o JSON (é necessária intrusão de código).
Em que circunstâncias devem ser consideradas, o Memwatch/HeapDump está ativado. Considere a frequência do Heapdump para evitar ficar sem CPU. Outras maneiras de detectar o crescimento da memória também podem ser consideradas, como o processo de monitoramento diretamente.MemoryUSAGE ().
Cuidado com o erro de julgamento, os picos de uso da memória de curto prazo se comportam como vazamentos de memória. Se o seu aplicativo consumir repentinamente muita CPU e memória, o tempo de processamento poderá abranger vários ciclos de coleta de lixo e, em seguida, o Memwatch poderá julgá -lo como um vazamento de memória. No entanto, neste caso, uma vez que seu aplicativo use esses recursos, o consumo de memória voltará aos níveis normais. Portanto, é importante observar que os vazamentos de memória são relatados continuamente e um ou dois alarmes repentinos podem ser ignorados.