Preloader
Panel Stability

Tutorial: How to Fix Memory Leak in XUI.ONE

Diagnose and resolve high RAM usage caused by PHP workers, FFmpeg, and Database caching.

Is XUI.ONE Leaking?

Usually, what looks like a memory leak is actually a misconfiguration in the underlying software stack. PHP-FPM workers may not be recycling, FFmpeg jobs might be getting stuck, or MariaDB might be caching too aggressively. This guide walks you through fixing these specific issues.

1Step 1: Identify the Culprit

Don't guess! Use system tools to see exactly what is consuming your memory. Run this command to see the top memory-using processes:

ps -eo pid,cmd,%mem,rss --sort=-rss | head -n 20

What to look for:

  • php-fpm: If these are at the top and growing, your workers aren't recycling.
  • ffmpeg: If you see hundreds of these, you might have stuck transcoding jobs.
  • mariadbd/mysqld: If this is huge, your buffer pool is likely too large for a shared server.

2Step 2: Service Controls

Before applying fixes, know how to restart XUI correctly to clear immediate issues. Depending on your installation, use one of these commands:

service xuione restart # OR systemctl restart xuione

3Step 3: Optimizing PHP-FPM (The Main Fix)

PHP workers often retain memory after processing requests. To prevent this "leak," we force them to recycle.

Edit your PHP pool config (commonly in /etc/php/7.x/fpm/pool.d/www.conf or similar):

nano /etc/php/7.4/fpm/pool.d/www.conf

Critical Settings to Change:

# Recycle worker after 200 requests to free memory pm.max_requests = 200 # Use ondemand to save RAM when idle pm = ondemand pm.process_idle_timeout = 10s # Restart master process if too many children fail emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 10s

Restart PHP-FPM: sudo systemctl restart php7.4-fpm (adjust version number as needed).

4Step 4: Managing FFmpeg & Transcoding

Stuck transcoding jobs are a major cause of memory exhaustion.

Check running jobs:

pgrep -a ffmpeg | wc -l

If the number is much higher than your active streams, you have zombies. If a single PID keeps growing in memory usage over hours, investigate the stream source. Ensure you are using the FFmpeg build provided or supported by XUI.ONE to avoid compatibility leaks.

5Step 5: Database Tuning

MariaDB/MySQL loves to eat RAM for caching. On a dedicated database server, this is good. On an "all-in-one" streaming server, it starves FFmpeg.

Check your current buffer pool size in MySQL console:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

If it is set to 80% of your RAM, reduce it in your my.cnf config. Leave enough headroom for PHP and FFmpeg spikes.

6Step 6: Verification

After applying these fixes, monitor your server for 24 hours. Use the watch command to see if memory stabilizes:

watch -n 60 "free -h; echo; ps -eo cmd,rss --sort=-rss | head -n 15"

Success means PHP workers appear and disappear (ondemand) or reset their memory usage (max_requests), and Swap usage remains at zero.