Search results

If you've got 1-2 site, cpu x 2 might be fine, but keep in mind it's a per site configuration, so 4 for both sites actually gives you 8. Not to mention buffers should be reserved other processes.

Why are those ports even open then? Just close them up with a firewall F2b uses regexs for matching so you can always write your own filter (which is generally recommended over modifying Plesk default filters) F2b docs and the preexisting f2b templates are good starting points.

Worker = max_children - they're interchangeable. Probably 2-4.

On a 2 GB machine? No

600M...700M...700M...300s...You're setting up yourself for a DOS attack. Make them something sane, (256M, 8/16M, 30-45s)

You could just start the migration job a d let it run through the day, and then re-sync everything once more after it finishes - resyncing only affects changed and added files, so it will be much faster.

How often does what happen? Plesk is a LAMP stack. There's not going to be a crazy difference between other LAMP stacks if configured well

Consider hiring a system administrator. "Correctly" varies from use case beyond basic security and performance recommendations commonly found on the internet

+1 for what @learning_curve said. Proper security practices should dictate discretionary ACLs for accessing any service. Things like SFTP/FTP are hard in a "shared hosting" environment. Everything else should be perfectly possible, and ideally you have more authentication than just a priv...

Not sure why there are spam links all over this place. @IgorG may want to edit those out. If you truly need 100% uptime, you would need some sort of "HA" set up. But, do you really need that? And, this is a Plesk forum

Check your fail2ban.log. any recent reloads?

Scan your system, trace the process, find and sandbox the binary

That looks like malware

Unlike say, NGINX, MySQL/MDB don't error out with duplicate configurations - the closest one takes precedence iirc - so for the most part, that's not an issue. It is worth taking a look at the other files though to see if there's a configuration causing issues that wasn't posted here.

What kind of reboot did you run? This behavior looks more like someone pulled the power on the instance lol.

Reloads are normal. As long as there isn't any downtime, Apache reloads are to be expected. The spikes are interesting - anything in logs around that time? I would also look into exactly what is causing those spiked - PHP or Apache?

You're not running mod_php/cgi are you? Edit: Ignore my reply. I re-read your initial thread Edit2: Have you checked your system logs? There's lots of things that can prevent forking - ie, kernel/security limits . I'd also take a look at some monitoring to see just how many processes are being...

Did you read my solution?

Nothing in any logs? Is there any Apache restart/reload? Are you hitting request worker limits?

I do want to point out - innodb_flush_log_at_trx_commit = 2 is generally safe unless you need ACID compliance - only an OS-level crash will cause the latest 1 sec or so of data to potentially not be flushed - something like OOM won't impact i (it will if it's 0) Also: > Today at noon it was...