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.

Important Legal Notice
Xtream-Masters is a software development company. We build and license professional software. We don't host, store, stream, index, or distribute any audio, video, playlists, channels, or DRM-protected content of any kind. What we sell is an empty technical platform; whatever content runs through it is added, configured, and controlled entirely by the end user, who is responsible for holding the proper rights and following the law in their region. Any copyright or DMCA complaints should go to whoever is operating the stream or hosting the URL in question — not to us. For the full picture, have a look at our Terms, Privacy Policy, and Refund Policy.