• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Login Client is slow

H.W.B

Regular Pleskian
Hello,

I have a question.
When clients login to Plesk it can take up to 30 seconds after the entered there login details, before they see a page. In the mean time they got a white screen.

I already noticed that this has something to do, for how many domains the client has.

Is this normal behaviour??

Henk
 
Do you have any related error messages in /var/log/sw-cp-server/error.log ?
 
Hello Igor,

The only entries are error messages from 'people' who tried to gain access, but nothing else.

Henk
 
Also nothing releaded to this....
When changing from Active list to Classic lists, then it takes less time to load....
 
@H.W.B

A lot of factors can explain the behaviour encountered.

However, there are two factors that you should be aware of, in the sense that they should be ruled out before changing something to the system.

These factors are related to the facts that

a) your server is low on resources, impeding or hindering access to the Plesk Panel. Make sure that you have enough resources (and 1 CPU core) available at all times. Just check that you do not have a lot of resources (memory, disk read/writes etc.) being used by the common suspects like Apache, mail (read: spam mail) and so on.

b) your Plesk instance is being targeted by brute-force hack attempts. Just enable Fail2Ban, activate the plesk-panel jail and set the maxretry value to a low number (consider: 2). Also have a look at /var/log/plesk/panel.log and /var/log/fail2ban.log.

If the above checks out fine (and you are not on a VPS), then we can proceed with some other checks.

Please post some output from the panel, while attempting to log in as admin and/or one of your customers.

Regards
 
Hello,

I don't think that a of b is the problem

When checking the health of the server no problems reported.

Services
Apache CPU usage 0.3 %
health-group-down-state.png
CpuTime->Web">(?)
nginx CPU usage 0.1 %
health-group-down-state.png
CpuTime->WebProxy">(?)
Mail server CPU usage 0 %
health-group-up-state.png
1.03 CpuTime->Mail">(?)
MySQL CPU usage 1.2 %
health-group-up-state.png
1.25 CpuTime->MySql">(?)
Plesk CPU usage 0 %
health-group-up-state.png
1.23 CpuTime->Panel">(?)
Apache memory usage 0.6% used (45.6 MB of 7.63 GB)
health-group-down-state.png
MemoryUsage->Web">(?)
nginx memory usage 0.2% used (18.9 MB of 7.63 GB) MemoryUsage->WebProxy">(?)
Mail server memory usage 0.1% used (8.38 MB of 7.63 GB)
health-group-down-state.png
MemoryUsage->Mail">(?)
MySQL memory usage 4.2% used (326 MB of 7.63 GB) MemoryUsage->MySql">(?)
Plesk memory usage 0.2% used (15.3 MB of 7.63 GB) MemoryUsage->Panel">(?)

CPU
Total usage 4.9% used
health-group-up-state.png
1.15 TotalUsage">(?)
Load average 0.6 processes
Processes 221.28
health-group-up-state.png
1.16
Running processes 0
Blocked processes 0
Paging processes 0
Sleeping processes 221.28
health-group-up-state.png
1.16
Stopped processes 0
Zombie processes 0

I am using SpamMagick, so very little spam. And Fail2Ban is active for allmost all jails

And no, no brute force attacks or so.

Henk
 
@H.W.B

Those statistics do not say anything: if anyone actually "tries" to access the system, you will barely notice anything in terms of CPU or memory.

However, each login attempt will take time to process, resulting in an endless "queue" in which the genuine login attempts are superseded by all other attempts.

More or less the same applies to Fail2Ban: it uses a lot of resources to scan logs over and over again, with every now and then some detection and some action.

In most cases, Fail2Ban miserably fails to recognize the hack attempts to the Plesk Panel, unless you have fine-tuned the default plesk-panel jail.

As a final (and important) remark, the statistics in question do show up Nginx related statistics, but as far as I know, those do not include the statistics associated with the custom (and separate) Nginx server being used for Plesk Panel: I am pretty sure that you can find a lot of activity in /var/log/plesk/httpsd_access_log

Nevertheless, there is no reason (so far) to rule out the potential causes, mentioned by me in points a and b.

The simplest way to analyse the problem is to restart psa service (in order to have a clean slate and not have bias interfere in the analysis of the problem).

Just provide some feedback in the form of the output (a couple of minutes after restart AND after trying to login as admin and as client) from

- /var/log/plesk/sw-cp-server/sw-engine.log
- /var/log/plesk/sw-cp-server/error_log (note: if everything is ok, no new entries should be found here)
- /var/log/plesk/httpsd_access_log (note: only provide output if you see something peculiar over there)
- /var/log/plesk/psa_service.log (note: if everything is ok, you will only see that psa service has been started. If that is the case, no need to provide output)
- /var/log/plesk/panel.log (this will be a huge file, only provide the relevant output)

Regards
 
Back
Top