[Solved] 500 internal server error

[Fsmv2]

It seems completely at random that my entire website hosted here, every page that is, gets a 500 internal server error. Then a couple minutes later when I refresh it works perfectly. Does this happen on every heliohost hosted site or just mine? Is this my code or the server? Also my pages are all php or cgi (perl) but both go down at the same time. The site is http://fsmv.co.cc

[Wizard]

Could just be server load or it could be that your scripts are resource intensive, or perhaps a combination of the two. The first point on the Support FAQ gives details on server load.

[awin]

So that I don't make a new topic (since I seem to be doing that often), I'm commenting here to say that I'm having the same trouble with my site and keep receiving the 500 Internal Server Error message.

[arjentm]

Could just be server load or it could be that your scripts are resource intensive, or perhaps a combination of the two. The first point on the Support FAQ gives details on server load.

I highly doubt it. All that runs on my account is Wordpress. Without anything fancy.

 

I'm commenting here to say that I'm having the same trouble with my site and keep receiving the 500 Internal Server Error message.

Once again, I'd like to jump on the bandwagon here, also.

It seems to be a persistant problem for every php script powered website on Stevie. This has been going on all of September; because it's been doing it since I signed up.

 

I don't mind a little downtime from time to time...

...But 'down' [unavailable; html pages are fine!] for six hours+ is getting a bit ridiculous, especially when the the server load isn't necessarily high at that time.

 

So what the heck is causing apache to disallow the loading of php scripts while the load is that high? And WHY is that load so high?! Is someone being an asshat?

Edit: No, really; why would simple php scripts be rejected to run simply because the load is at a certain percentage?

 

<3

[awin]

[Wizard]

Djbob can explain this better than I can. This support request is being escalated to our root admin.

[rvt]

In short, PHP scripts require memory and CPU cycles to interpret your code. Wordpress tends to be a very "heavy" blogging script, even with the base installation. Plus, MySQL based scripts also take extra resources.

 

Why is the server load high?

 

10,000+ accounts, each serving websites to users = lots of files being accessed at one time = CPU cycles to process those files. All those CPU cycles increase server load and load times.

 

Again, my opinion, but my suggestions to fix the CPU load would be:

 

-Ditch cPanel as it is way to resource intensive and switch to something more light weight. I'd probably use something like LayeredPanel in its place as it doesn't use as many resources. Downside of this is cPanel is name brand web hosts get "respect" for using cPanel and people view them as reputable hosts then.

 

-Divide the accounts here amongst 2 servers to lighten the load. Buy shared hosting somewhere for heliohost.org/helionet.org to be hosted on to increase speed and uptime.

 

-Stop giving out IP's for SSL as every SSL tranfer requires considerably more resources to encrypt/decrypt the content then just a regular connection

 

I had another thought but can't remember it off hand right now.

 

For those people who would like guaranteed uptime for their site (with no 500 errors), I would suggest you investigate paid hosting such as HostGator. They give you unlimited space and bandwidth plus all the cPanel features you get here. You also get a 99.9% uptime guarantee and considerably less server load. As an added bonus, I've created a special coupon just for HelioHost members to use. Enter the coupon code "HelioHost994" at checkout time and we will give you $9.94 off of your hosting package. This is a GREAT deal and will only be available for a limited time. If you have any questions about this, feel free to ask me.

[Wizard]

@rvt: We can't ditch cPanel, it helps keep our standing as #1 on freewebhosts. Also, we are putting up another server soon. Read the Support FAQ.

[rvt]

@Wizard: I know you can't ditch cPanel. Believe me, I know the hassles of keeping features like this and such. And I know you are putting up a new server "Charlie" and I have read the support FAQ. My point is, the current accounts on Stevie need to be split between at least 2 servers and all new accounts go on a new server (#3). Obviously, this is very difficult financially and I don't see it happening.

 

Ultimately, this is a forum where different people offer their opinions. I knew when I posted that my points were difficult to put in to action and probably wouldn't be but they were my opinion which I am entitled to post.

[Ashoat]

rvt is pretty close, but for the us the high server load isn't caused by CPU overuse. From a theoretical perspective, server load represents how much processes are waiting on the run queue. Though usually the run queue gets really long because the CPU can't handle everything at once, our bottleneck is usually disk I/O. In short, our hard drives are too slow. Every request on our server requires that a file is opened up, requiring that process to stay in a "D" state where it waits on the hard drive(s).

 

At a typical moment in time, our hard drives are at around 90% utilization and processors are below 50%. Another interesting fact is that almost every one of our downtimes is caused by RAM running out and the system being forced to use swap (page file for Windows folks), which skyrockets disk I/O to the point where the server can't handle the load.

[Krydos]

rvt is pretty close, but for the us the high server load isn't caused by CPU overuse. From a theoretical perspective, server load represents how much processes are waiting on the run queue. Though usually the run queue gets really long because the CPU can't handle everything at once, our bottleneck is usually disk I/O. In short, our hard drives are too slow. Every request on our server requires that a file is opened up, requiring that process to stay in a "D" state where it waits on the hard drive(s).

 

At a typical moment in time, our hard drives are at around 90% utilization and processors are below 50%. Another interesting fact is that almost every one of our downtimes is caused by RAM running out and the system being forced to use swap (page file for Windows folks), which skyrockets disk I/O to the point where the server can't handle the load.

 

I have also been having the internal server error a lot on my pages, and came to these forums to try to figure out what was going on. I am using mostly php files that I have written myself. Is there anything I can do to reduce the amount of errors or the length of time that these errors are being displayed to anyone trying to look at my page?

[rvt]

...our bottleneck is usually disk I/O. In short, our hard drives are too slow. Every request on our server requires that a file is opened up...

 

Just to go in to detail a bit for other users. This issue isn't just "server" related. This issue is present on your own computer as well. One of the issues with any programming language is how to implement it. For example, Java, C, C++, etc are designed such that you have to COMPILE code in to a "machine language" in order to run it. By doing this, you could in theory speed up the time needed for execution because the computer has already "translated" your code in to something it can understand. However, programs in languages like these suffer from the same bottlenecks djbob talks about. The CPU can process this "machine code" very quickly but it can't transfer quick enough from the hard drive to RAM thus slowing program execution time down. On the flip side, some people think that in order to be "efficient" code should be compiled at run time (such as PHP, ASP, etc). The problem here is that every time you use a method in code like that it has to open up another file to get the code for that method. So, in theory, your single file PHP script could require 5-10+ files to be opened and interpreted by the computer. If your script accesses a database, that is another set of files that has to be opened up. HTML pages only require 1 file be opened - that HTML file (and any files it includes like CSS and Javascript). Thus fewer 500 errors occur with just HTML sites because they don't require as many file accesses.

 

To sort of bring this "full circle", you tend not to notice this problem as much on your computer because there is just 1 of you. However, there are thousands of accounts here which means thousands of times the file accesses as your computer at home. Hence, the increased I/O.

 

Now, some people could say that in order to fix the "downtime" issue the swap should be disabled to prevent the I/O spike but then the server is going to have RAM issues and I suspect lots of people will start getting "FATAL ERROR: XXXXX BYTES EXHAUSTED (TRIED TO ALLOCATE XXX BYTES)" which essentially means all the RAM is full and there is no where else to put anything. Which would bring a whole other slew of complaints.

[lucasbytegenius]

Whew, was waiting for someone else besides me to report this. My forum (www.enigmacomputerforum.co.cc) kept getting the E500s all day yesterday, then it was solid E500 until about 2 hours ago. Couldn't access the HH forums, couldn't get into the cPanel, nothing. My error log read things like "Could not allocate memory" and such, which confirms djbob's statement.

 

I use a php based forum client called MyBB, and I'm wondering if GZip compression is causing too much load on Stevie? If it is, (I'm not sure) I'll turn it off to help minimize these errors.

[Piotr GRD]

(...) all day yesterday (...)

 

Just to confirm that there was quite a lot of problems, not all day, but...

 

 

 

Turning off gzip compression may decrease CPU load - which is not the problem according to what djbob wrote - but will increase bandwidth usage. Let someone else say which would be better in here in current situation.

 

 

[Ashoat]

HelioNet doesn't take up that much of our load.

 

And yeah, we've been having lots of downtimes recently. I'm looking into it.