• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Serach in Plesk Panel is Very Slow?

CairoKolton

New Pleskian
Hi

After include Email address or other option in search in plesk panel , show result very slow ( after 30 - 40 Sec ) , i have 400 domain - 300 Subscription - 350 customer and more than 1000 email on this serveromegle xender

i can customize search ? for example search only Domains or Customers or exclude email address form search in plesk panel

Thanks
 
Last edited:
hello @CairoKolton ,
we were not able to reproduce this problem on our environment ~200 domains with physical hosting and 1200 mailboxes around them
(cos7 & Plesk 18.0.35; win2016 & Plesk 18.0.35)

Is it true that average count of mailboxes eventually hosted around all domains
or there are a few domains with most of hosted mailboxes and another domains with hosting
on your installations ?

do your mailboxes contains same substrings in left and right parts (before and after @) or they are mostly different ?

do your domains have some partially identical names , like host1.domain.tld, host2.domain.tld, etc
or domain names are mostly different ?
 
Hi Dear

i found solution

1 - I Edit ( panel.ini ) in the folder ( %plesk_dir%admin\conf\ ) and add semicolon ( ; ) at the beginning of this 5 lines for Disable this :

****************************
;enabled = on

; filter.priority = 7


; show.sql_query = on

; show.util_exec = on

; show.util_exec_io = on
*****************************

More Details :


2 - and then Allocate RAM to the Plesk SQL server at this location :

%plesk_dir%MySQL\my.ini

change this :

innodb_buffer_pool_size=64M ( or larger if have enough RAM , for example 256M )
query_cache_size=32M

then save my.ini file and Restart ( Plesk SQL Server ) by Plesk Services Monitor

Speed is good now

Thanks

Masoud Saeidi
www.EsfahanHost.com
 
I'd like to make note of a few things:
;enabled = on

; filter.priority = 7


; show.sql_query = on

; show.util_exec = on

; show.util_exec_io = on
Unless you're actively debugging something, debug mode should always be off in production. It defaults to filter level 3, with other debug messages off. This is optimal, and shouldn't be changed unless you're debugging something.

More importantly:
query_cache_size=32M
The query_cache_size directive is one of hot debate around DBAs. There's certainly tangible speed improvements from turning it on (query_cache_size!=0) - at the same time, anyone doing so should also be fully aware of the implications.

MySQL's QC does not allow stale data. Anytime data is changed (INSERT/DELETE/UPDATE/etc), the MySQL thread will acquire a global mutex on the QC and prune any affected tables. At 32 M, this is somewhat fine, but raising this to large values = more time taken to prune affected tables. This mutex can potentially cause significant bottlenecks in concurrency and slow down your site (ie, if a flood of INSERTs cause sequential locks, blocking a read). My recommendation to anyone considering this would be to proceed with caution and to make sure you test everything.
 
Back
Top