You could NEVER, EVER trust Task Manager to tell you how much memory SQL Server is using (maybe you are remembering a 32-bit system with a very small amount of memory). Stop using Task Manager for this, period. Use the performance counter - you can also query the performance counter using DMVs:
SELECT object_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Total Server Memory (KB)';
You could save that as a query shortcut in Tools > Options > Environment > Keyboard > Query Shortcuts, and get accurate results in a query window much faster than getting inaccurate results from Task Manager.
You can also check for memory pressure (and whether you can do anything about it) using these queries:
SELECT object_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN ('Total Server Memory (KB)', 'Target Server Memory (KB)');
-- SQL Server 2012:
SELECT physical_memory_kb FROM sys.dm_os_sys_info;
-- Prior versions:
SELECT physical_memory_in_bytes FROM sys.dm_os_sys_info;
EXEC sp_configure 'max server memory';
This isn't a complete answer, as I admit I don't know the complete answer, but can't fit into a comment.
Short detour - regarding SQLOS memory there is a wealth of information coming from a guy that worked on the internals of SQL Server storage team - Slava Oks. He has lots of articles on MSDN blogs regarding the SQLOS memory manager and they are all worth a read. Now I know we're on to SQL Server 2012, but the info is valuable nonetheless.
Now, regarding your first question, if there's a limit of max memory taken by db page cache before being cleared out and how is it controlled, I'll quote his word on it.
From article SQLOS's memory manager and SQL Server's Buffer Pool:
Buffer Pool commits pages on demand. Depending on internal memory requirements and external memory state, it calculates its target, amount of memory it thinks it should commit before it can get into memory pressure. To keep system out of paging target is constantly recalculated. Target memory can't exceed max memory that represents max server memory settings. Even if you set min server memory equal to max server memory Buffer Pool will only commit its memory on demand. You can observe this behavior by monitoring corresponding profiler event.
From this article's comment I understand that SQL Server uses a LRU algorithm (LRU = least recently used). If you really need to go in depth, SQL Server's LRU algorithm in particular is described in the following research paper: The LRU-K Page Replacement Algorithm For Database Disk Buffering.
Now, for your second question, the log caches are not really exposed so they can't be changed/tuned, as they are a part of the SQLOS internal memory structure. Quoting from an answer from MSDN forum:
Essentially each database has a log buffer/cache for its transaction
log which is a small contiguous memory allocation, that is 60K in size
and used by active transactions, and flushed when a transaction
commits, or when the buffer space fills up. Multiple active
transactions can be interleaved in the log buffer, and if any one
transaction commits, the buffer memory is written to the transaction
log file by the log writer. If the space fills up, the contents get
flushed to disk allowing the buffer/cache memory to be reused. This
is why log IO can range for 512bytes to 64K (its actually 60K), but it
is always sequential so varying write sizes doesn't matter that much.
The format of the log records is different than data pages as
documented in the BOL
(http://msdn.microsoft.com/en-us/library/ms190925.aspx), so the size
of a log record is variable, but the size of the log buffer/cache is
consistent.
Best Answer
I'm not sure about a single view for memory, but you can get the information from two queries. The first (taken from Glenn Berry's DMV queries) leverages sys.dm_os_buffer_descriptors and will show you buffer pool by database:
The second query I put together by looking at sys.dm_os_memory_cache_entries to show me non-buffer pool information:
There are a host of DMVs related to memory, notated by
dm_os_memory_*
. You can use these to investigate how memory is used by SQL Server on a variety of levels.