Pegjs: [pergunta] Conselhos sobre {cache: true} e como lidar com casos de falta de memória razoável

Criado em 22 nov. 2018 · 3Comentários · Fonte: pegjs/pegjs

Tipo de problema

Questão: sim

Pré-requisitos

Você pode reproduzir o problema ?: sim
Você pesquisou cache nos problemas do GitHub, encontrei alguns problemas no cache, mas não é o que estou pedindo.
Você verificou os fóruns ?: sim, tentei googlegroups / cache , nenhum resultado relacionado
Você fez uma pesquisa na web (google, yahoo, etc) ?: sim

Descrição

Estou analisando uma parte bastante pesada (500 KB) de texto fornecido pelo usuário usando uma gramática de aproximadamente 1000 linhas.

Ao passar {cache: true} ...
- ... e dizendo ao Node para usar 3 GB de heap (com --max-old-space-size=3000 ), o heap cresce para 2,5 GB e a análise é bem-sucedida em 12s.
- ... e deixando o padrão do Nó 10 para 800 MB de heap, a análise de travamentos com um OOM.
Ao passar {cache: false} , como esperado, a análise de relógios é um pouco mais rápida em 10s (caso não patológico) e não aumenta o uso de memória.

Esses são os dados do usuário e os recursos do meu servidor são limitados, portanto, fazer com que o Node use X GB de heap não é uma opção, pois amanhã posso obter 1 MB de dados do usuário que exigiriam X + 1 GB de heap. E, claro, gostaria de continuar usando {cache: true} quando possível, para "evitar o tempo de análise exponencial em casos patológicos" , que conheci.

Que abordagem você recomenda?

Existe alguma coisa embutida no PEG.js para salvar quando o uso de memória se torna crítico?
Minhas tentativas de lidar com isso com tempos limite não são boas, pois o uso de memória pode crescer mais rápido do que o tempo limite.
Pelo que eu sei, é impossível interceptar um Node OOM.
Finalmente, estou pensando em trocar o uso de {cache: true} base no tamanho da entrada. Isso vai me custar mais uso da CPU, mas pelo menos não vou OOM.
Outras idéias?

Obrigado pelo PEG.js! 🙂

Programas

PEG.js: 0.10.0
Node.js: 10.13.0
NPM ou Yarn: npm 6.4.1
Navegador: N / A
SO: AWS Linux

performance question

Fonte

ronjouch

Todos 3 comentários

Tempos de análise exponencial é algo que acontece em casos muito patológicos, e eu recomendo reescrever a gramática lá.
Considere https://github.com/sirthias/pegdown/issues/43#issuecomment -18469752
(Não sou um contribuidor)

polkovnikov-ph em 23 nov. 2018

👍1

Como @ polkovnikov-ph apontou, é melhor reescrever partes de sua gramática que lidam com casos patológicos, mas se você continuar acertando casos OOM, pode ser melhor fazer o que você (@ronjouch) sugeriu; alterne a opção _cache_ com base no tamanho da entrada: cache: input.length >= 250000

Depois disso (e apenas se você tiver acesso ao texto fornecido pelo usuário), sugiro examinar qualquer entrada que acesse os casos OOM para localizar quaisquer casos patológicos comuns e atualizar sua gramática para lidar explicitamente com eles para que você possa reduzir o número de casos OOM acessando seu aplicativo.

Se você ainda está acertando casos OOM com frequência e está disposto a não apenas reescrever sua gramática, mas também adicionar uma passagem extra (ou poucas) à sua cadeia de ferramentas, sugiro tentar qualquer um destes métodos:

dividir grande entrada e atualizar sua gramática para lidar com partes parciais da sintaxe que você está analisando, então, quando todas as partes de entrada forem analisadas, junte tudo (isso provavelmente só é viável se o analisador gerado retornar AST, não tenho certeza do contrário)
use um regex para identificar a sintaxe no texto fornecido pelo usuário que pode levar a casos patológicos antes de enviá-lo para um dos 2 analisadores gerados: um analisador normal e outro para lidar com casos patológicos
você sempre pode usar a gramática PEG.js para gerar um analisador que se comporta como tokenizadores e constrói um analisador que pode analisar de forma otimizada as entradas normais e as entradas que contêm sintaxe que pode levar a casos patológicos (exigirá que você invista mais tempo em aprender sobre analisadores e meio que frustra o propósito de um gerador de analisador, mas _é quase sempre uma opção viável se você souber o que está fazendo_)

futagoza em 26 nov. 2018

👍1

@ polkovnikov-ph @futagoza obrigado a vocês dois por terem voltado com conselhos 👍! Isso faz sentido. Implantei a solução alternativa de tamanho e considerarei reescrever a gramática da próxima vez que o problema aparecer. Dia bom; encerrando a questão.

ronjouch em 26 nov. 2018

Esta página foi útil?

0 / 5 - 0 avaliações