the PHP5.4 is installed by OS vendor

5.4.16 by OS vendor FPM application

This is listed in plesk. Maybe I need to update the digital oceans php version to 7.1 instead of plesk...

I think your going to have to identify what high level area is causing the slowness. I would start reviewing the operating system. if you run top it will give you a overview of the current system utilisation for CPU, memory, Load, etc

top - 07:41:25 up 211 days, 18:07,  1 user,  load average: 1.84, 1.29, 0.91
Tasks: 200 total,   1 running, 199 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  1.2%sy,  5.8%ni, 91.6%id,  0.2%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   4056252k total,  2780968k used,  1275284k free,   165484k buffers
Swap:  4128764k total,   108648k used,  4020116k free,   491984k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1793 mysql     20   0 2268m 468m 5412 S  1.3 11.8   1213:50 mysqld
...

If you monitor the output for a minute or so to baseline normal operation then in a second terminal manually run your artisan command. Do you notice any of the figures for CPU, Memory, etc dramatically change e.g. CPU idle goes to 0%. Do you see you process in bottom part of the output. what does it show? If you can narrow down the general area you can then drill down using the sar command (use CTRL + C to stop top) . You can check if sar is installed by running the following and you should see something like below

sar -V
sysstat version 9.0.4
(C) Sebastien Godard (sysstat <at> orange.fr)

if you get a sar not found you can install from the vendor repositories with yum install sysstat

You can then use one of these sar examples to get more information. General format of the command is sar <ITEM> <FREQUENCY> <OCCURRENCES> so to get the CPU activity every second for 2 minutes you can run

sar -P ALL 1 120

Linux 2.6.32-696.16.1.el6.x86_64         10/03/2018      _x86_64_        (4 CPU)

07:56:15 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
07:56:16 AM     all      0.00      0.00      0.25      0.25      0.00     99.50
07:56:16 AM       0      0.00      0.00      1.00      0.00      0.00     99.00
07:56:16 AM       1      0.00      0.00      0.00      0.99      0.00     99.01
07:56:16 AM       2      0.00      0.00      0.00      0.00      0.00    100.00
07:56:16 AM       3      0.00      0.00      0.00      0.00      0.00    100.00

07:56:16 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
07:56:17 AM     all      0.00      0.00      0.50     12.78      0.00     86.72
07:56:17 AM       0      0.00      1.00      1.00      1.00      0.00     97.00
07:56:17 AM       1      0.00      0.00      0.00      0.00      0.00    100.00
07:56:17 AM       2      0.00      0.00      0.00     50.51      0.00     49.49
07:56:17 AM       3      0.00      0.00      0.00      0.00      0.00    100.00

If you run your artisan command again while sar is running you can get a log of how your server is performing (You may want to do this multiple times to rule out any one-off issues). Repeat this for the other system areas, memory, disk, network until you are sure you have found the problem area (or ruled everything out!).

If you want to drill into the php process in more detail you can use pidstat (from sysstat package). Below is what I see when I run a php artisan migrate:fresh when running pidstat.

pidstat -C php -ruhl 1 120
Linux 4.9.93-linuxkit-aufs        10/03/2018      _x86_64_        (2 CPU)

#      Time   UID       PID    %usr %system  %guest    %CPU   CPU  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
 1538550035     0      2836    6.00    3.00    0.00    9.00     0   1984.00    132.00  294752  31516   1.55  php artisan migrate:fresh

#      Time   UID       PID    %usr %system  %guest    %CPU   CPU  minflt/s  majflt/s     VSZ    RSS   %MEM  Command
 1538550036     0      2836   12.00    5.00    0.00   17.00     1    153.00    340.00  303212  40204   1.98  php artisan migrate:fresh

Again this wont fix your problem but will help rule things in or out of your problem.

One thing I would check is what modules you have compiled into php on the command line. If you run php -m It will give you a list. Do you see anything related to debugging that might be slowing down the application, such as xdebug. if so disable the module and retry and see if you still have issues.

Any questions let em know.

Is your hardware clock set to the same as your php/system time ?

hwclock --show

If at all possible on your setup , let's try the most simple tip we IT people always give. Put it off and on again....

/sbin/service crond stop

 /sbin/service crond start

If not on production , restart the server even.

If I remember correctly the hardware clock is set on server shutdown.

I really don't think your problem will be solved by above , but I have seen weirder things getting solved just by a reboot.

Also , check if there are not multiple instances of cron running and that they are setup correctly ( daily.cron set wrong?)

Good luck! would love to hear what the solution is, if someone finds it

@Hondnl - never one to go against turn it off and on again but in this scenario I don't think there is much value as when testing cron with a shell script and not php the jobs ran as expected, on the minute every minute.

Worth checking the time though, especially as it's a VM.

@D9705996 Really strange news. I have talked with plesk support, an engineer logged in and he returns to me that "he cant reproduce the issue".

So I logged in and now even I can't reproduce the issue, apparently all is running on time. I have asked him if he changed anything but I'm still waiting for an answer. All crons are fired on time and tasks on time.

I have checked all logs and there is no accumulation or delay for tasks. Really strange but good (for now). Yesterday and all past days the server failed one time in 10 minutes average. Now it is running for about 5 hours without any issue.

an engineer logged in and he returns to me that "he cant reproduce the issue.

... and it "mysteriously gets fixed" after they do that...

Hah, that's what they usually say when they find an issue caused by them and they fix it. That is so typical. I'd bet that's what happened.

@Charrua , @Cronix :

haha so recognizable , breaking your brain on an issue that is actually out of your reach. Finally contacting support and it magically disappears , while they state they cannot find the issue and you feel like an idiot.

Most of the time the guy had a big oops moment and does not want his boss to know and fixes it in silent.

I hope the guy want to tell us the story. Was it a bug in centos ( fixed with an update)? was it a badly configured VM ? Did it really resolve itself, what did update?

One of the reasons I get dedicated servers for my projects, when I f*ck up , at least I know It was me and not some external force.

If you really search for them , they are not that expensive. A bit of a learning curve , but the amount of documentation available to setup a healthy server is staggering.

Good luck and let us know what you found out.

The issue was caused by depleted entropy by PHP script.

To resolve the issue generate entropy by using haveged daemon:

1. Enable EPEL repository:

yum install epel-release

1. Install daemon with the following command and enable it:

yum install haveged

chkconfig haveged on

systemctl start haveged

What part of the script depleted your entropy? You have a big random hash generator?

Thanks for the update , good to know...

@hondnl this is the Plesk engineer answer:

This is a known issue with plesk-php7x which have libsodium package included for stronger cryptography. Forced initialization of crypto library on startup each PHP script depletes entropy (/dev/random) and next processes wait for another portion of randomness. So any php script can cause entropy depletion. The developers have submitted this issue as a bug PPPM-9444 which is planned to be fixed in one of the future Plesk updates. Please subscribe to the following article to be notified when the bug is fixed: https://support.plesk.com/hc/en-us/articles/360010129094