Question CPU boosted and panel crashes

[jonatanplay]

I have an XUI panel, usually everything is normal, but when series are deleted or added, the CPU increases exponentially and the system crashes. I made some modifications to the DB but it continues to happen, it becomes a bottleneck and it throws everything away. This happens when there are more than 12,000 connections taken. Is there any way to optimize it? I share my MySQL configuration file. In addition, many connections remain in sleep mode. I don't know if this has happened to anyone.

# XUI
[client]
port                            = 3306

[mysqld_safe]
nice                            = 0

[mysqld]
user                            = mysql
port                            = 3306
basedir                         = /usr
datadir                         = /var/lib/mysql
tmpdir                          = /tmp
lc-messages-dir                 = /usr/share/mysql
skip-external-locking
skip-name-resolve
bind-address                    = *

key_buffer_size                 = 128M
myisam_sort_buffer_size         = 4M
max_allowed_packet              = 256M
myisam-recover-options          = BACKUP
max_length_for_sort_data        = 8192
query_cache_limit               = 0
query_cache_size                = 0
query_cache_type                = 0
expire_logs_days                = 10
max_binlog_size                 = 100M
max_connections                 = 13000
back_log                        = 10000
open_files_limit                = 262144
innodb_open_files               = 60000
max_connect_errors              = 1000000
table_open_cache                = 14000
table_definition_cache          = 14000
tmp_table_size                  = 256M
max_heap_table_size             = 256M

innodb_buffer_pool_size         = 10G
innodb_buffer_pool_instances    = 8
innodb_read_io_threads          = 16
innodb_write_io_threads         = 16
innodb_thread_concurrency       = 0
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method             = O_DIRECT
performance_schema              = 0
innodb-file-per-table           = 1
innodb_io_capacity              = 20000
innodb_table_locks              = 0
innodb_lock_wait_timeout        = 50

sql_mode                        = "NO_ENGINE_SUBSTITUTION"

[mariadb]

thread_cache_size               = 3072
thread_handling                 = pool-of-threads
thread_pool_size                = 56
thread_pool_idle_timeout        = 20
thread_pool_max_threads         = 2048

[mysqldump]
quick
quote-names
max_allowed_packet              = 16M

[mysql]

[isamchk]
key_buffer_size                 = 16M

 

[meowrzvpn]

I have an XUI panel, usually everything is normal, but when series are deleted or added, the CPU increases exponentially and the system crashes. I made some modifications to the DB but it continues to happen, it becomes a bottleneck and it throws everything away. This happens when there are more than 12,000 connections taken. Is there any way to optimize it? I share my MySQL configuration file. In addition, many connections remain in sleep mode. I don't know if this has happened to anyone.
# XUI
[client]
port = 3306

[mysqld_safe]
nice = 0

[mysqld]
user = mysql
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
skip-name-resolve
bind-address = *

key_buffer_size = 128M
myisam_sort_buffer_size = 4M
max_allowed_packet = 256M
myisam-recover-options = BACKUP
max_length_for_sort_data = 8192
query_cache_limit = 0
query_cache_size = 0
query_cache_type = 0
expire_logs_days = 10
max_binlog_size = 100M
max_connections = 13000
back_log = 10000
open_files_limit = 262144
innodb_open_files = 60000
max_connect_errors = 1000000
table_open_cache = 14000
table_definition_cache = 14000
tmp_table_size = 256M
max_heap_table_size = 256M

innodb_buffer_pool_size = 10G
innodb_buffer_pool_instances = 8
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_thread_concurrency = 0
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
performance_schema = 0
innodb-file-per-table = 1
innodb_io_capacity = 20000
innodb_table_locks = 0
innodb_lock_wait_timeout = 50

sql_mode = "NO_ENGINE_SUBSTITUTION"

[mariadb]

thread_cache_size = 3072
thread_handling = pool-of-threads
thread_pool_size = 56
thread_pool_idle_timeout = 20
thread_pool_max_threads = 2048

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]

[isamchk]
key_buffer_size = 16M

check your panel setting maybe some setting mistake turn on.

 

[jonatanplay]

https://imgur.com/a/jxcEisk

I don't know what it is or what it is due to

 

[Juanwom]

Te escribí al privado

 

[beninuk]

its always done this for me for massive shows, never crashes last a few seconds, shouldnt worry about it, just dont make a change during peak hours.

 

[magotv2025]

Hi, you can try optimize index of tables.. tables stream and table users.. the xui panel generate more Sleep query , you can aggressiv add rule check Sleep query and clean for 69 sec, another optimize Is in file template for pool PHP... The Number children Is very big and the processo PHP run time at loop.... You can try insert rule kill or check process PHP old pool ...After select correct Number pool example: for 24 core
Cpu you can use 12 pool mit more children connection in template file... Optimize cache....the sistem has default cache /*5 ...in the big event, the rigeneration of cache can effect High cpu...you can rigenerate cache manually , and make cron at 2 hours, the finish event, you can turn of /*20 minut.... You can try...

 

[Infest84]

The issue you're seeing is pretty common when dealing with large libraries.


When you add new series, the panel will reassign all the TMDb metadata to every episode and also rename the series accordingly — this process is quite heavy. It’s not really about how many CPU cores you have, but how efficiently your CPU handles single-threaded tasks.


If you're using a recent generation CPU, you probably won’t notice much impact. But with older hardware, this becomes a bottleneck and leads to crashes, especially with over 12,000 active connections.


Also, when you need to delete series, use the "mass delete" option — it’s faster and consumes less resources, though it still has a load.


So yes, what you’re experiencing is normal under these conditions. Optimizing helps, but hardware and how the panel handles these background tasks plays a big role.