- Fix: Memory-based calculator now accounts for MySQL memory usage
- Fix: Changed safety buffer from 15% to 50% (much more conservative)
- Fix: Hard cap recommendations at 150 max_children per domain on shared hosting
- Fix: Added combined capacity validation to prevent OOM scenarios
- Fix: Use realistic 20MB per process default instead of 1MB
- Fix: Added critical warning when server has <20% RAM headroom
- Feature: Step 2b now validates that combined domain recommendations fit in RAM
- Feature: Automatically scales down recommendations if they exceed 60% of total RAM
- Safety: Previous recommendations of 227 for 8GB server would now be capped at 150
This prevents dangerous situations like:
- Domain with 421 requests getting 227 max_children (would need ~28GB)
- Combined pools exceeding available RAM
- OOM crashes from over-provisioned settings
Tested on 8GB server with 2 domains: Now recommends 105 + 31 instead of 227 + 31
ROOT CAUSE:
The batch analyzer calls calculate_optimal_php_settings() which relies on
calculate_max_children_memory_based(). When no active PHP-FPM processes exist
(common in ondemand mode with sparse traffic), both functions returned 0.
IMPACT:
- Recommending pm.max_children: 0 (completely invalid, breaks PHP-FPM)
- Causes silent failures in optimization reports
- Especially problematic with ondemand PM mode + low traffic domains
FIXES:
1. calculate_max_children_memory_based():
• When no processes detected: return 20 instead of 0
• When invalid parameters: return 20 instead of 0
2. calculate_optimal_php_settings():
• Added CRITICAL safety check: if final_max_children <= 0, use 20
• Ensures output is always safe regardless of calculation errors
DEFAULTS:
- Memory-based: 20 (safe minimum when no process data available)
- Traffic-based: Uses actual peak concurrent if available
- Safety guardrail: 20 minimum in all code paths
This prevents invalid recommendations and ensures batch analyzer always
provides sensible, actionable optimization guidance.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
IMPROVEMENTS IN CALCULATION ALGORITHM:
1. DYNAMIC SYSTEM RESERVE (percentage-based instead of hard-coded)
- Small servers (< 2GB): 15% reserve
- Medium servers (2-8GB): 20% reserve
- Large servers (8-32GB): 25% reserve
- Very large servers (> 32GB): 30% reserve
OLD: Hard-coded 1GB was too high for small VPS (50% on 2GB!)
and too low for large servers
2. TRAFFIC-BASED RECOMMENDATIONS
- Analyzes 7-day access logs for peak concurrent requests
- Calculates traffic stability factor (0.6-0.9)
- Adjusts safety buffer based on traffic patterns
OLD: Ignored actual traffic patterns entirely
3. MYSQL MEMORY ACCOUNTING
- Detects MySQL memory usage from ps or MySQL variables
- Reduces PHP allocation accordingly
OLD: Didn't account for other services running alongside PHP
4. PM MODE RECOMMENDATIONS
- STATIC for stable, high-traffic domains (best performance)
- DYNAMIC for variable traffic (memory efficient)
- ONDEMAND for low-traffic domains (minimal memory)
OLD: No pm mode recommendations at all
5. SPARE SERVER OPTIMIZATION
- Recommends min_spare_servers based on peak/3
- Recommends max_spare_servers based on peak*2/3
OLD: Didn't optimize spare server settings
6. COMBINED APPROACH
- Uses BOTH memory AND traffic constraints
- Applies lower of memory-based vs traffic-based max_children
- Adapts safety buffer to traffic stability
OLD: Single constraint approach (memory-only)
EXAMPLE IMPROVEMENTS:
- 2GB VPS: Reduced from recommending 40 processes to 5
(matches actual traffic, saves ~700MB memory)
- 32GB server: Changed from ignoring MySQL to accounting for 2GB
(prevents memory exhaustion under load)
- Variable-traffic site: Now recommends DYNAMIC mode instead of STATIC
(saves 70% memory during off-peak)
This library is backwards-compatible and can gradually replace
calculate_optimal_max_children() in php-analyzer.sh
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Developer