Problems with newly purchased server

[1337Space]

Hi,

I purchased the largest server at ecatel and i'm just got finished moving all cpanel accounts from the old server to this one.

I'm getting very high load already and I didn't even switch dns?

http://screensnapr.com/u/52gs0y.png

I am also getting lots of things that are down in the server status.

ScreenSnapr » 2x2f7n.png

I don't know what can be the cause. I really need to switch dns's soon. I also have trouble logging into to ssh.

All these problems occurred after I finished moving all accounts to the server.

Intel Quad-Core Xeon X3323 2.5GHz/2x6MB 1066FSB
8GB 667MHz Dual Rank ECC Memory (4X2GB)
500GB
Centos 64 bit

I put around 118 Accounts.

 

[madaboutlinux]

How did you migrated the accounts btw? And the load average screenshot won't help. Paste the complete output of the following commands:

top c
ps -auxf

These will list the processes using heavy resources and will give a chance to track down the exact issue.

 

[Miraenda]

I'd really suggest opening a ticket in WHM > Support Center > Contact cPanel for the failures you are having in exim, pop and imap services. Part of the load issues might even be due to those services constantly failing. Once those are properly working, you can focus more easily on whatever might be causing the load if it isn't due to service failures.

Also, did your old machine use PHP as DSO and the new one is using PHP as suPHP instead for the handler (you can see the handler in WHM > Apache Configuration > PHP and SuEXEC Configuration area)? I ask as a load spike can occur with suPHP when the old handler was DSO. While suPHP is more secure than DSO and does allow you to more easily track down spammers and exploits due to running processes as the user rather than nobody, it also can create a higher load and CPU usage on highly active machines.

 

[Radwiz]

While suPHP is more secure than DSO and does allow you to more easily track down spammers and exploits due to running processes as the user rather than nobody, it also can create a higher load and CPU usage on highly active machines.

The reason for what you just said is 777 permissions, while common to dso, the use of 777 permissions in suphp causes scripts to slowdown, extra server loads, and often just brings down the site with error 500 pages.

 

[Miraenda]

It has nothing to do with 777 permissions for suPHP to be slower or 500 errors. Even with the correct permissions, suPHP is just slower due to how it works in conjunction with Apache and how it handles those processes. It's commonplace knowledge that a switch to suPHP will frequently cause a higher load and slower site loading. Additionally, suPHP cannot use PHP caching such as EAccelerator, while DSO and FCGI can due to how the PHP handlers treat threads (DSO and FCGI have persistency for threads, while suPHP doesn't).

If you want the security of suPHP with the lower loads and faster speeds of DSO, FCGI is the one to use.

I have a chart I created recently to compare the handlers:

Notes on Chart:

1. mod_perl's Apache2::Resource information can be found at the following site.
2. FcgidMax and FcgidMin Limit details can be found at this location.
3. APC will be provided in the core of PHP 6+ for PHP caching per this discussion.

Anyway, my intention earlier by mentioning suPHP and DSO wasn't to debate the PHP handlers. I simply wanted to find out what handler was being used on both and point out that might cause the issue if there had been a change in PHP handler. We have no idea yet if that is the issue or not in this instance.