Pressão de memória no SQL Server - Ativar o LPIM ou não?

existe uma pressão de memória neste servidor.

Com a informação limitada, não posso dizer com certeza. Precisa de mais parâmetros e saída do perfmon para informar sobre a pressão da memória. Mas sim, a partir da saída da consulta que você postou para o momento 2018-10-23 11:22:30:457, havia de fato pouca memória para alguns processos, não para o sistema SQL Server como um todo.

o sinalizador RESOURCE_MEMPHYSICAL_LOW está sendo definido pelo sistema operacional ou processo externo ou servidor SQL.?

Olhe para a saída que diz que RESOURCE_MEMPHYSICAL_LOWtem valores de 2que IndicatorProcesssignifica que certos processos que estavam em execução estavam de fato enfrentando pressão de memória, se IndicatorSystemtivesse valor de 2, teria sido pressão de memória em todo o sistema. Observe também que a pressão da memória está vindo de baixa memória física (RAM) e não de baixa memória virtual (VAS). Então você pode ver que apenas tomando um valor para um pedaço de tempo é difícil dizer que há uma pressão de memória contínua . Eu sugiro que você leia Usando sys.dm_os_ring_buffers para diagnosticar problemas de memória no SQL Server para entender o que significam os valores Indicatorsystem e IndicatorProcess

devo habilitar o LPIM para corrigir esse problema.?

O LPIM não corrigirá o problema, apenas mascarará o problema e será uma solução alternativa. Você precisa descobrir o que está fazendo com que o monitor de recursos sinalize a notificação de pouca memória, é possível que algum processo em execução esteja causando isso. Agora, planejar o cache sendo limpo com frequência é algo que muitas pessoas relataram do SQL Server 2016 em diante e pode ser devido ao armazenamento de consultas, você está usando um?. O armazenamento de consultas costumava ser o culpado pela limpeza do cache do plano, mas como você está no SP mais recente, duvido desse fator.

Para ver a pressão da memória para o cache, também podemos usar DMV sys.dm_os_memory_cache_clock_hands

SELECT  *
FROM sys.dm_os_memory_cache_clock_hands
WHERE rounds_count > 0

Se rounds_countestiver aumentando, isso significa que houve pressão que forçou os relógios a varrer o cache com mais frequência e remover as entradas.

EDITAR:

Estou enfrentando uma enorme concessão de memória por algumas consultas e isso está fazendo com que RESOURCE_SEMAPHORE aguarde outras consultas. Essa enorme concessão de memória (uma consulta que verifiquei, a concessão de memória é ~ 7 GB) resulta em uma pressão de memória do servidor SQL e essa pode ser a causa de limpeza de cache do plano e sinalizador RESOURCE_MEMPHYSICAL_LOW.

Sim, muito provavelmente, eu vi que você levantou um tópico específico para esta questão e gostaria apenas de acrescentar que, antes de fazer qualquer coisa, certifique-se de ter as estatísticas atualizadas e os índices desfragmentados. Uma estatística desatualizada pode levar a um plano ruim que pode acabar pedindo mais memória e, portanto, esperas de semáforo.

Abaixo estão lista de tópicos falando sobre problema semelhante

• Tópico do Stackexchange sobre o cache do plano sendo limpo com frequência.
• Thread do MSDN sobre o cache do plano sendo limpo.