To diagnose and solve the recurring Apache memory issue on your 2 GB RAM + 2 GB swap Debian 13 VPS, let's break this down systematically.

---

Root Cause Analysis

From your logs:

• Apache crashed with status=1/FAILURE and a memory peak of 1G (RAM) + 771.9M (swap).
• This means Apache (or its child processes) consumed ~1.77 GB total, likely triggering the OOM (Out of Memory) killer or hitting system limits.
• The issue recurs every few weeks, suggesting a memory leak or misconfigured resource limits.

---

Immediate Steps to Diagnose

1. Check Apache Error Logs

Run:

bash
Copy
tail -n 100 /var/log/apache2/error.log

Look for:

• Out of memory errors.
• PHP-FPM or module crashes (e.g., mod_php, mod_perl).
• Segmentation faults or malloc failures.

2. Check System Logs for OOM Events

Run:

bash
Copy
dmesg | grep -i "oom\|kill"

If the kernel killed Apache, you'll see entries like:

text
Copy
Out of memory: Kill process 12345 (apache2) score 900 or sacrifice child

3. Monitor Memory Usage Over Time

Use htop, glances, or sar to track memory usage before the next crash. Example:

bash
Copy
apt install htop
htop

• Sort by memory (F6 → MEM%).
• Check if a specific Apache child process is growing uncontrollably.

---

Likely Causes & Fixes

A. Memory Leak in Apache or Modules

• Symptoms: Memory usage grows over days/weeks until crash.
• Fix:
  • Restart Apache daily via cron (temporary workaround):

    bash
    Copy
    echo "0 3 * * * systemctl restart apache2" | sudo tee /etc/cron.d/apache_restart

  • Disable problematic modules:
    • Common culprits: mod_php, mod_perl, mod_wsgi (Python), or custom modules.
    • Test with minimal modules:

      bash
      Copy
      a2dismod php8.2 mpm_prefork  # Example: Disable PHP and prefork
      systemctl restart apache2

  • Switch to mpm_event (lower memory footprint):

    bash
    Copy
    a2dismod mpm_prefork
    a2enmod mpm_event
    systemctl restart apache2

B. PHP-FPM Memory Leaks

• If using PHP (e.g., WordPress, Laravel):
  • Check PHP-FPM logs:

    bash
    Copy
    tail -n 100 /var/log/php8.2-fpm.log

  • Limit PHP memory: In /etc/php/8.2/fpm/pool.d/www.conf:

    ini
    Copy
    pm.max_children = 10       # Reduce from default (e.g., 50)
    pm.start_servers = 2
    pm.min_spare_servers = 2
    pm.max_spare_servers = 4
    pm.max_requests = 500      # Restart workers after 500 requests

    Then restart:

    bash
    Copy
    systemctl restart php8.2-fpm apache2

C. Apache Configuration Tuning

• Reduce MaxRequestWorkers (formerly MaxClients): In /etc/apache2/apache2.conf or /etc/apache2/mpm_prefork.conf:

  apache
  Copy
  <IfModule mpm_prefork_module>
      StartServers             2
      MinSpareServers          2
      MaxSpareServers          4
      MaxRequestWorkers        10   # Default is often 150+! Reduce to 10-20 for 2GB RAM
      MaxConnectionsPerChild   1000
  </IfModule>

• Enable MaxRequestsPerChild: Forces Apache to recycle workers after N requests (prevents leaks):

  apache
  Copy
  MaxRequestsPerChild 1000

D. Swapiness and OOM Tuning

• Reduce swappiness (prevents excessive swap usage):

  bash
  Copy
  echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
  sysctl -p

• Reserve memory for critical processes: Edit /etc/sysctl.conf:

  ini
  Copy
  vm.min_free_kbytes = 65536  # Reserve 64MB for kernel

  Then run sysctl -p.

E. Use a Lightweight Alternative

• Switch to Nginx + PHP-FPM: Nginx uses far less memory than Apache for static files and reverse proxying. Example:

  bash
  Copy
  apt install nginx php8.2-fpm
  systemctl disable apache2
  systemctl enable nginx php8.2-fpm

---

Long-Term Monitoring

1. Install netdata or prometheus for real-time monitoring:

   bash
   Copy
   bash <(curl -Ss https://my-netdata.io/kickstart.sh)

2. Set up alerts for memory usage > 80%.

---

Next Steps

1. Share your /etc/apache2/apache2.conf (as you mentioned attaching it) so I can check for misconfigurations.
2. Confirm if you're using PHP/WordPress or other memory-heavy apps.
3. Test with mpm_event + reduced MaxRequestWorkers and monitor for 24-48 hours.

---

Question: Are you running any specific web apps (e.g., WordPress, Nextcloud) or custom Apache modules? This will help narrow down the root cause.