NinjaWeb

1) The Myth – More RAM Means Faster Sites

Throwing RAM at a slow site rarely fixes the root cause. If your Time To First Byte is high, the bottleneck is usually PHP execution, cache misses, or database queries. RAM helps you survive concurrent requests without swapping. Speed comes from fewer dynamic hits and less blocking work per request.

2) What Actually Consumes RAM

• PHP workers – each active worker holds code, opcode cache pages, and request state.
• Database – buffer pool, query cache structures, temporary tables, connections.
• Web server – LiteSpeed or NGINX resident memory and connection buffers.
• Object cache – Redis or Memcached storing hot keys to avoid DB hits.
• Background tasks – cron jobs, image optimizers, search indexers, queues.

Rule of thumb – size RAM to your peak concurrent PHP workers plus DB and cache, with 20 to 30 percent safety margin.

3) Quick Reality Checks

• Low traffic brochure sites can run fine on 1 GB if caching is configured correctly.
• Ecommerce and membership sites need more headroom because logged-in traffic bypasses full page cache more often.
• RAM shortages show up as high CPU from context switching and slow TTFB from swap thrash.

4) The 1 GB, 2 GB, 4 GB, 8 GB Tiers

Numbers assume a modern stack with full page cache for anonymous users and Redis object cache for dynamic requests.

5) PHP and PHP-FPM Settings That Decide RAM

php.ini essentials

; php.ini
memory_limit = 256M
opcache.enable = 1
opcache.memory_consumption = 192
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
realpath_cache_size = 4096k
realpath_cache_ttl = 600

PHP-FPM pool

; /etc/php-fpm.d/www.conf
pm = dynamic
pm.max_children = 6      ; 1 GB: 3-4, 2 GB: 6-8, 4 GB: 10-12, 8 GB: 20-24
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

Estimate per worker memory by watching resident set size during load. Multiply by planned concurrency to avoid swap.

6) Database Memory That Actually Matters

MariaDB my.cnf baseline

# /etc/my.cnf.d/server.cnf
[mysqld]
innodb_buffer_pool_size = 512M      # 1 GB plan: 256M to 384M, 2 GB: 512M to 1G
innodb_log_file_size    = 256M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method     = O_DIRECT
query_cache_type        = 0
tmp_table_size          = 64M
max_heap_table_size     = 64M
max_connections         = 80        # keep realistic or DB will overcommit memory
table_open_cache        = 4000
thread_cache_size       = 100

Index heavy tables, especially for WooCommerce orders and search. Keep max_connections realistic or RAM will spike under slow app code.

7) Object Cache and Its Footprint

Redis config

# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru
appendonly no

Start small. If hit ratio is high and eviction is low, you can raise Redis memory. Do not starve the database to feed an overgrown Redis.

8) Swap – The Safety Net, Not a Crutch

# create a 2G swap file
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# make it persistent
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

Use swap to absorb short spikes. If you sit on swap during normal traffic, reduce workers or upgrade RAM.

9) Find Your Real RAM Usage

# live process view
htop

# per process memory during load
ps -o pid,cmd,%mem,rss --sort=-%mem | head -n 20

# PHP-FPM pool stats if enabled
curl -s http://127.0.0.1/status

# database memory insight
mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,80p'

Test with load. Warm the cache, then hit the site with a small concurrency test while watching resident memory. Adjust workers to the highest value that does not push the system into swap.

10) Practical Presets By Plan

• 1 GB – PHP max_children 3 to 4, Redis 64 to 128 MB, InnoDB buffer 256 to 384 MB. Strict caching and minimal plugins.
• 2 GB – PHP max_children 6 to 8, Redis 128 to 256 MB, InnoDB buffer 512 MB to 1 GB. Fine for light carts and small memberships.
• 4 GB – PHP max_children 10 to 12, Redis 256 to 384 MB, InnoDB buffer 1.5 to 2 GB. Stable for medium WooCommerce.
• 8 GB – PHP max_children 20 to 24, Redis 512 MB to 1 GB, InnoDB buffer 3 to 4 GB. Room for queues, search, and reporting.

11) Hidden RAM Killers

• Image optimizers running at full throttle during traffic peaks.
• Backup jobs compressing large archives on the same node.
• Search indexers or analytics daemons left on default settings.
• Cron storms from plugins firing at the same minute.
• Bot traffic bypassing cache due to query strings or cookies.

Schedule heavy jobs off-peak and pin them to low priority with nice and ionice. Protect cache hit rate with sensible bot rules.

12) The Ninja Verdict

RAM is not the weapon. Discipline is. Size PHP workers to real concurrency, give the database a healthy buffer pool, keep a lean object cache, and protect your cache hit rate. Most WordPress sites run best when they stop chasing giant RAM numbers and start tuning what actually does the work.