8

Increasing memory usage on an AWS EC2 instance can be difficult to troubleshoot. Unlike CPU utilization, high memory consumption does not always indicate that something is immediately wrong. Linux uses available memory for processes, file system cache, and other purposes, so a server can appear to have very little free memory while still operating normally.

This guide explains how to identify why memory usage is increasing on an EC2 instance and how to address the underlying cause.

Why Is EC2 Memory Usage Increasing?

Memory consumption can increase for several reasons. Common causes include:

• Applications retaining memory unnecessarily
• Memory leaks
• Increasing website traffic
• Database workloads growing over time
• Too many application workers
• Large caching systems
• Background jobs or scheduled tasks
• Container workloads
• Insufficient RAM for the current workload

The first step is determining whether the memory increase represents normal Linux behavior or actual memory pressure.

Step 1: Monitor Memory Usage Over Time

Start by examining the instance’s historical performance.

AWS CloudWatch provides CPU, network, and disk-related metrics, but standard EC2 monitoring does not provide operating-system memory utilization by default. To monitor RAM usage, you generally need an agent such as the CloudWatch agent or another monitoring solution that collects memory metrics from inside the operating system.

Look for patterns such as:

• Memory increasing gradually throughout the day
• Sudden memory spikes
• Memory increasing after every application restart
• Memory usage increasing during traffic peaks
• Memory remaining high even after workloads finish

A gradual increase that eventually results in an out-of-memory condition can be a strong indication of a memory leak or a process that continually accumulates data.

Step 2: Check Memory Directly From Linux

Connect to the EC2 instance and use free to obtain an overview of memory usage:

free -h

A typical output includes total, used, free, shared, buff/cache, and available memory.

Pay particular attention to the available memory value rather than focusing only on the free-memory figure.

Linux intentionally uses unused RAM for file system caching. Therefore, low “free” memory does not automatically mean that the server is running out of RAM.

You can also inspect /proc/meminfo for more detailed information:

cat /proc/meminfo

This can help identify how memory is distributed between caches, buffers, available memory, and other kernel-managed areas.

Step 3: Identify the Processes Using the Most Memory

Once you establish that memory pressure exists, identify which processes are responsible.

The top command provides a real-time view:

top

Look at the %MEM column to identify processes consuming the largest percentage of RAM.

You can also sort processes by memory usage using:

ps aux –sort=-%mem | head

This is useful for quickly identifying large web-server workers, database processes, application servers, PHP processes, Java applications, or other memory-intensive services.

Do not terminate a process simply because it appears near the top of the list. A database server, for example, may legitimately consume substantial memory because it uses RAM for caching and query processing.

Step 4: Check for a Memory Leak

A memory leak occurs when an application continues allocating memory without releasing it properly.

One useful method is to monitor a process over time.

First identify its PID:

pgrep -f application_name

Then monitor its memory consumption periodically:

ps -p <PID> -o pid,%mem,rss,vsz,cmd

If the process’s resident memory steadily increases while the workload remains relatively consistent, investigate the application for a possible memory leak.

Application logs, error messages, recent software changes, and dependency updates can provide additional clues.

Restarting the affected service may temporarily release the memory, but it does not solve the underlying problem. The application should be investigated and corrected where possible.

Step 5: Investigate Database Memory Usage

Databases commonly consume significant amounts of RAM by design.

MySQL, MariaDB, PostgreSQL, and other database systems use memory for caches, buffers, connections, sorting, and query execution.

If database memory usage has increased, examine whether the number of connections or workload has also increased.

For MySQL or MariaDB, review configuration parameters such as buffer pools, connection limits, and per-query buffers.

An incorrectly sized database configuration can cause excessive memory consumption, particularly when many connections are active simultaneously.

Step 6: Check Web Server and Application Workers

Web servers can consume increasing amounts of memory when worker counts are too high.

For example, PHP-FPM may create multiple worker processes to handle concurrent requests. If each worker uses significant RAM, increasing the number of workers can quickly exhaust available memory.

Check the number of active processes:

pgrep -c php-fpm

The exact process name may vary depending on the operating system and PHP configuration.

Review application traffic and worker settings together. Increasing worker limits without sufficient RAM can make the problem worse.

Step 7: Check Swap Usage

Swap provides disk-backed virtual memory when RAM becomes constrained.

Check swap usage with:

free -h

You can also inspect active swap devices:

swapon –show

Some swap usage is not necessarily a problem. However, heavy and continuous swapping can significantly reduce performance because disk storage is much slower than RAM.

If the server frequently exhausts physical memory and heavily relies on swap, identify the process causing memory pressure rather than treating swap as a replacement for adequate RAM.

Step 8: Investigate Out-of-Memory Events

Linux may terminate processes when the system cannot satisfy memory allocation requests.

Search system logs for OOM-related messages:

dmesg | grep -i “out of memory”

On systems using systemd, you can also check:

journalctl -k | grep -i “out of memory”

Messages mentioning the OOM killer can help identify which process was terminated.

If an application repeatedly gets killed by the OOM mechanism, investigate its memory requirements and determine whether the workload or configuration needs adjustment.

Step 9: Review Scheduled Jobs and Background Tasks

Memory usage may increase because of scheduled tasks that are not immediately obvious.

Review cron jobs:

crontab -l

Also check system-wide scheduled directories:

ls -lah /etc/cron.*

Backups, reporting scripts, log processing, database maintenance, security scans, and data-processing jobs can temporarily consume substantial amounts of memory.

If several memory-intensive tasks execute simultaneously, staggering their schedules can reduce peak memory pressure.

Step 10: Determine Whether the Instance Needs More RAM

Sometimes the server is functioning correctly but simply does not have enough memory for its workload.

If applications consistently require more RAM, consider moving to an EC2 instance with greater memory capacity.

Before resizing, establish a performance baseline. Review memory usage during normal operation, peak traffic, scheduled jobs, and unexpected workload periods.

Scaling should complement optimization rather than replace it. Increasing RAM can provide additional capacity, but an application with a genuine memory leak will eventually consume the additional resources as well.

Preventing Future Memory Problems

Continuous monitoring is the best way to detect memory issues before they become outages.

Set alerts for available memory, swap activity, and application-specific metrics. Maintain historical data so you can identify gradual changes instead of investigating only after the server becomes unstable.

It is also useful to document normal memory consumption for critical services. This makes it easier to distinguish normal workload growth from abnormal behavior.

Regularly review application updates, database configuration, worker limits, and scheduled jobs. Changes in any of these areas can significantly affect memory requirements.

Conclusion

Increasing memory usage on an AWS EC2 instance should be investigated systematically rather than assuming that high memory consumption is automatically a problem.

Start with historical monitoring, verify actual memory pressure using Linux tools, and identify the processes consuming the most RAM. Then investigate applications, databases, web-server workers, scheduled tasks, swap usage, and OOM events.