image
Intro: 
Being a production DBA means you must have ability to quickly look at the system and figure out the issues. A quick look at perfmon or Task manager can tell us of high CPU usage, but what is a good way to quickly look at proper memory usage.
Checking out the Page Life Expectancy (PLE) counter is a great way to check for memory pressure. A low value for your system indicates that system is flushing pages from the buffer pool too quickly. The longer a page can stay in the buffer pool and be read from memory the better. As fetching the data from the disk is the resource intense operation that slows down the system that can perform way better if reads from buffer.
Before we go extremely technical let’s have a brief introduction on the topic:
·         What is page Life expectancy:
Page Life Expectancy; is the number of seconds the average page of data has been in the buffer pool.  Keeping the data in memory gives SQL Server quicker access to it instead of making the long, slow trip to disk.  While none of the counters in SQL Server means everything on its own, this one can open your eyes and lead you towards issues that can be resolved.
·         Detailed Information;
The commonly cited value to aim for is 300 seconds or more. This translates to five minutes, meaning a page will remain in memory for only five minutes. Therefore, all of the contents of the buffer pool will be renewed every five minutes, given the current pressure on the buffer pool to find new buffers for pages. For example, if you have a buffer pool that’s 60GB, your SQL Server system is reading 60GB of data every five minutes, which is a pretty large amount.

The value of 300 seconds is a Microsoft recommendation in a white paper that was written five years ago. It’s not a relevant guideline nowadays, and even back in 2006, aiming for a set value isn’t a valid recommendation.
T-SQL Query to find the page life expectancy:
SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE ’%Manager%’
AND [counter_name] = 'Page life expectancy’
The problem is that many people see the 300 value for Page Life Expectancy you can still find documented is wrong, very wrong. If you have a server with 64 GB of memory with 56 GB allocated to SQL Server that means you’re reading about 56 GB of data from disk every 300 seconds. If you look at Page 36 of Troubleshooting SQL Server – A Guide for the Accidental DBA by Jonathan Kehayias and Ted Krueger you’ll see an actual scalable version of this; PLE should be 300 for every 4 GB of RAM on your server. That means for 64 GB of memory you should be looking at closer to 4,800 as what you should view as a critical point.
The reason you see 300 written everywhere is because we were limited by 32-bit servers for so long while at the same time SQL Server documentation was really being developed well.  Those servers could only have 4 GB of memory, thus making this number make sense as well as the Buffer Pool / 4 GB * 300 formula.  I’ll go so far as to say that you should be cautious of anything that doesn’t have a formula to it because our servers keep getting faster, our databases keep getting bigger, and static values…don’t.
Formula to be used as per today’s technology advancements:
PLE threshold = ((MAX BP(MB)/1024)/4)*300
One of the options we have is to enable the Microsoft feature that locks pages in the memory to avoid frequent and easy flush of pages from memory.
Lock pages in memory:
This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk.
Normally, an application running on Windows can negotiate for more physical memory, and in response to the request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use.
Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could lead to performance degradation.
 References:
·         Lock pages in memory;
·         How to enable this option;
·         MS BLOG Detailed: