DonRocks Posted July 21, 2012 Share Posted July 21, 2012 I just sent a desperate note to Invision (our Forum software) after receiving this response by DreamHost (our web host). I think it's pretty self-evident what the problems are - we've all gotten these "Internal Server Error" messages, and they don't seem to be getting any better. If anyone can help, I'd really appreciate it. I'm doing everything I can to avoid switching to a dedicated server because that's big bucks. --- Advice about Slow Performance Don Rockwell 21 July 2012 - 05:30 PM Hi, please notice the title says "Advice about" instead of "Help with" because our forum is hosted on Dreamhost, and I realize this is officially outside your area of control. But I was hoping that you could maybe give me some advice. Our website, for a long time now, has been very slow, and plagued with Internal Server Errors. This, despite having researched a good alternative for Invision as a host (recall that a few years ago, our website grew beyond the point of Invision wanting to host it anymore). We were way, way under the parameters that Dreamhost said they could handle. Nevertheless, there's this problem ticket (below) I submitted to Dreamhost, who suggested it's probably one of three things: 1) Third-Party Software Overhead - The only third-party plug-in we use is Google Analytics, and I can't imagine that would cause this (the problems existed before I inserted the Analytics code). 2) Database-Related Overhead - Maybe on occasion, but yesterday, for example, there were only about 50 users total, and I wasn't doing any type of administrative work. Yet, the server was virtually non-responsive. 3) A Spike In Traffic - It happens sometimes, but I saw with my own eyes that it didn't happen yesterday. So none of these three things should cause such a thing. Is it possible that the sheer size of our website (I guess it is pretty large) could be causing server inefficiencies? That seems unlikely to me since the hugely vast majority of it just sits there, not being accessed. I can understand Invision giving us the boot because you decided to focus on forum software and not website hosting, but Dreamhost's raison d'ĂȘtre is website hosting, and I don't think our website is THAT popular or resource-intensive. Do you have any advice or ideas about how to respond to DreamHost? The messages about "uid ram total exceeds limit" are pretty clear - *something* is causing memory to spike, but what could it be? Anyway, I'm grasping for straws here and obviously asking the Invision support team for a favor. Thank you if you have any advice, Don --- > Hi! donrockwell.com is plagued with internal server errors today. This, > despite the volume being much lower than normal. I know that sometimes things > can get denied resources when they're attempting to use too many, but I doubt > that's the case here because usage is so low. > > Thanks if you can look into it, > Don Rockwell > I'm sorry that you are encountering these issues. Your site that is running under your user "donrockwell" is occasionally hitting our shared server's memory limits. This is why your site is seemingly slow, and the 500 errors are directly related as well. Here is an excerpt from the log kept by our Process Watcher, the daemon that is killing your troublesome php5.cgi processes: Fri Jul 20 13:01:46 2012 procwatch3 INFO: PID 30836 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:01:56 2012 procwatch3 INFO: PID 32271 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:06 2012 procwatch3 INFO: PID 32289 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 32276 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 32285 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 30689 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 32303 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 30746 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:16 2012 procwatch3 INFO: PID 31515 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:02:27 2012 procwatch3 INFO: PID 32265 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:03:07 2012 procwatch3 INFO: PID 32312 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Fri Jul 20 13:05:38 2012 procwatch3 INFO: PID 32297 (php5.cgi) donrockwell:pg4101656 - killed for uid ram total exceeds limit Procwatch is a daemon that runs constantly on shared servers to monitor the usage of RAM/CPU and execution time so that no single user can use an inappropriately high percentage of the shared resources and impact the overall health of the server or the server's ability to serve all users' pages. Now, it's important to get these errors fixed to keep your site running with optimum speed, as well as keep our servers happy. Unfortunately it can often be a bit of a trial-and-error procedure, but I will provide as much information as I can to aide you in this process. It's important to keep your user's site optimized and running smoothly. There are quite a few things that can contribute to high memory consumption on any given site, but I will mention the most common causes... Plugins - Especially third-party plugins can often be poorly written and run up the memory consumption. I often recommend disabling all non-critical plugins and see if the problem gets better, then enabling them one-by-one until you are able to identify one that causes problems. Database related overhead, or an unnecessary amount of database queries - If you are trying to query your database for thousands of results at a time, this can also cause issues... Try to keep all database sizes and queries to a minimum by deleting irrelevant or old information from your database. You might also try optimizing tables in your databases by visiting your database through PHPMyAdmin. Simply use the "Check tables having overhead" link located directly underneath your tables and then "With Selected:", choose "Optimize Table". This might reduce overhead in your database, which is basically a lot of empty and redundant space that can slow your queries down. It is also possible that a spike in traffic, or a heavy run by a site indexer (such as the GoogleBot), or even abusive hits by a given IP address, could cause this on a short term basis, so you might want to inspect your access logs for such activity (you can often manage this problem by implementing a robots.txt or by blocking abusive IP addresses with .htaccess). You might as well want to try looking over the suggestions offered at our wiki pages on this matter: http://wiki.dreamhos...oor_performance http://wiki.dreamhos...timize_database http://wiki.dreamhos...ase_Maintenance http://wiki.dreamhos...troubleshooting http://wiki.dreamhos..._of_Heavy_Usage Implementing the above suggestions more often than not will fix the ProcWatch errors, but if you are still finding that your site encounters the same problems, you might want to consider moving to a VPS (http://wiki.dreamhost.com/DreamHost_PS) or dedicated server where you can reserve sufficient RAM for your own processes to run! I am sorry if this news is discouraging, but I felt it was important that you have the full benefit of knowing what is occurring here so you can make the appropriate decision to meet your needs for this site. If you have any other questions, or if I can help you further, please let me know! I hope you have a great day! Anthony S DreamHost Support Link to comment Share on other sites More sharing options...
DonRocks Posted July 22, 2012 Author Share Posted July 22, 2012 After having Invision and Dreamhost pointing at each other, and saying "it's not us," I optimized our files, and things seem to be running much more quickly since I did. We'll see if that's just coincidence. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now