SharePoint 2013 - How much memory is recommended by Microsoft?

In a nutshell: for a Web server or an Application server in a three-tier farm, you will need to have at least 12 GB of RAM, and 64-bit, 4 cores!

This is according to the official Microsoft’s documentation: https://technet.microsoft.com/en-us/library/cc262485(v=office.15).aspx

Just some notes on this topic:
The 12 GB ensures that the system has enough memory for running all the services. But you should also consider the following recommendations:

- Make sure that you activate the minimal features and components on your server.
- Make sure that you turn off all the services that you're not using or even, minimize the logging.
- If you have additionally the SQL server co-located, make sure that you install only the required components on SQL Server.

It is better to implement everything with the minimal amount of RAM and then, optimize each layer.

Some notes also on the RAM and the Distributed Cache specifically:

When the Distributed Cache service runs in collocated mode, the physical memory of the server should be increased and all non-essential services stopped.
We do not recommend that any of the following services or applications run on the same server as the Distributed Cache service:

• SQL Server 2008 or SQL Server 2012
• Search service
• Excel Services in SharePoint
• Project
  Server services

https://technet.microsoft.com/en-us/library/jj219572(v=office.15).aspx

Additionally: When SharePoint 2013 is initially set up and the Distributed Cache service is configured to run, it is set to use 10% of the server’s total (physical) memory.
That means 1.2GB of memory for the 12GB.
You can always change that ccording to the following guidelines:

When SharePoint Server 2013 is installed, it assigns the Distributed Cache service 10 percent of the total physical memory on the server.
The Distributed Cache service uses half of that memory allocation for data storage (also known as cache size), and the other half of
that memory allocation is used for memory management overhead.
When the cached data grows, the Distributed Cache service uses the entire 10 percent of the allocated memory.

You should increase the memory allocation of the Distributed Cache service in these scenarios:

• When you add physical memory to the server. The Distributed Cache service does not automatically recalculate the 10% memory allocation, so when you increase the
  total physical memory on the server, you have to manually increase the Distributed Cache service's memory allocation.
• When your server farm has a dedicated Distributed Cache server. Use the following method to calculate how much memory can be assigned to the Distributed Cache
  service:

1. Determine the total physical memory on the server. For this example, we will use 16 GB as the total physical memory available on the server.
2. Reserve 2 GB of memory for other processes and services that are running on the cache host. For example, 16 GB – 2 GB = 14 GB.
   This remaining memory is allocated to the Distributed Cache service.
3. Take half of the remaining memory, and convert it to MB. For example, 14 GB/2 = 7 GB or 7168 MB. This is the cache size of the Distributed Cache service.
4. Use the following procedure to update the memory allocation accordingly.

https://technet.microsoft.com/en-us/library/jj219613.aspx#memory

 

From the following article you get very useful information and what to avoid during the design operations (especially related to Search):

Redesign enterprise search topology for specific performance requirements in SharePoint 2013
https://technet.microsoft.com/en-us/library/dn727118(v=office.15).aspx

Don’t mix competing search components

Avoid mixing search components on a physical server or machine if the components will compete for the same resources. Here’s a table that illustrates the relative amount of resources
that each component needs...

For example, it might not be a good idea to put a crawl and analytics processing component on the same server because they both use a lot of network bandwidth.
But, if the physical server or virtual machine has enough network capacity, the components won’t compete.

Which hardware requirements should I be aware of?

The next step is to plan the hardware you’ll need:

• Choose amount of hardware resources for
  the host servers
• General storage
• Minimum resources for the index component
• Minimum resources for the analytics
  processing component
• Minimum resources for the crawl, content
  processing, query processing, and search administration component
• Minimum resources for search databases
• Plan storage performance

o   Choose type of storage

o   Search component IOPS requirements

o   Search database IOPS requirements

• Choose how your search architecture supports high availability

Choose amount of hardware resources for the host servers

Each search component and search database requires a minimum amount of hardware resources from the host server to perform well.
But, the more hardware resources you have, the better the performance of your search architecture will be. So it’s a good idea to have more than the
minimum amount of hardware resources. The resources each search component requires depends on the workload, mostly determined by the crawl rate, the
query rate, and the number of indexed items.

For example, when hosting virtual machines on Windows Server 2008 R2 Service Pack 1 (SP1), you can’t use more than four CPU cores per virtual machine.
With Windows Server 2012 or newer, you use eight or more CPU cores per virtual machine. Then you can scale out with more CPU cores for each
virtual machine instead of scaling up with more virtual machines.
Set up servers or virtual machines that host the same search components, with the same hardware resources. Let’s use the index component as an example.
When you host index partitions on virtual machines, the virtual machine with the weakest performance determines the performance of the overall search architecture.

The minimum storage that the analytics reporting database requires can vary. This is because the amount of storage depends on how users interact with SharePoint 2013.
When users interact frequently, there usually are more events to store. Check the amount of storage your current search architecture uses for the analytics database, and assign at
least this amount for your redesigned topology.

So, in general, the planning and design operation is a matter of calculations BUT also, you need to check all the aspects of the design - in the manner that is mentioned for example, in the previous article above… and the following ones:

Planning worksheets for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262451(v=office.15).aspx

System requirements for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262749(v=office.15).aspx

Plan for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc261834(v=office.15).aspx

Plan for performance and capacity management in SharePoint Server 2013
https://technet.microsoft.com/en-us/library/cc262971(v=office.15).aspx

Capacity management and sizing for SharePoint Server 2013
https://technet.microsoft.com/en-us/library/cc261700(v=office.15).aspx

Capacity planning for SharePoint Server 2013
https://technet.microsoft.com/en-us/library/ff758645(v=office.15).aspx