"Error 500: Premature end of script headers" on admin pages

I just now re-opened (and then re-closed, after I saw this issue) #213260: Error 500: Premature end of script headers on Dreamhost -- has some "stale" content on it & I'd rather start fresh with this one.

Anyway, same exact problem (literally) as described above. Here's my post from the old issue:

This is driving me nuts. Here's my "deal":
- 500's almost 100% of the time (when logged in)
- If it's not a 500, it's a 404
- Running a multisite install w/ custom php.ini (FastCGI)
Any special perms? Settings? Modules (besides admin menu) that may be causing this?

Where it says "when logged in," just as described by jcisio's initial post, what I should have put was "when logged in as admin" instead. Gotta be a way to nail down why this is happening...

I was having the same problems running PHP as cgi .. i switched to mod_php and these errors went away

Starting to see these errors more on Dreamhost.

Got the reason: Dreamhost has a daemon called procwatch that terminates processes when they use too much memory. This has nothing to do with php.ini settings.

Dreamhost won't share how much is too much (for "security" reasons--bah!), but I guess it's somewhere between 130 and 145 MB.

How do we monitor memory usage? The trick is we need to monitor memory usage in a way that we have stats that are collected before Dreamhost's procmon shuts down the process. Two possibilities:

• Some super lightweight process that writes current process memory usage to a file every 1/10 second or so.
• A more traditional way to monitor memory usage, the kind that doesn't report usage to the browser until the page has loaded. Then you'd slowly increase complexity until things break. For example, I was recently adding 14 or so CCK text fields to a content type. The site got slower as I added fields, and after roughly the 8th-10th field, I started getting procmon-induced errors.

We could simulate this on some other machine, but I'm not sure that it's possible to accurately mimic Dreamhost's memory usage on another system, especially since we don't know Dreamhost's precise configuration.

Hey guys...

I noticed there are a couple issues regarding this, and rather than clutter up the issue queue I thought it might be better (and easier) to kind of "consolidate" everything into a forum thread instead, so I started one here.

I also just now posted a link there to an askapache.com article I stumbled upon that might be relevant if anyone wants to take a look at it...

In the interim, I'd rather not mark this issue as Won't fix or Closed because then it'll disappear out of everyone's (visible) queue -- Fixed is probably the best choice (even though I know it's not) (fixed, that is) so people have a chance to "relocate" but as far as I'm concerned, it's your call jcisio.

Hi,

So, anyone got any luck with this? I am getting this issue after installing the Category module, everythign was working fine before. I think I have tried almost all suggested fixes on all the 500 error threads that are around. Is there a workaround? Did someone fixed this?

I'm experiencing the exact same issues with the Drupal 7 core. The stie runs fine until I load an admin page, then no one can access it for 20 mins due to 500 errors with the same mod_fcgid timeouts and premature script ends. The PHP Memory limit had to be set to 160MB to fix it. This is way too high for a webpage. What's wrong here?

[Fri Jul 29 14:47:03 2011] [warn] [client 205.203.134.197] mod_fcgid: read data timeout in 40 seconds
[Fri Jul 29 14:46:54 2011] [error] [client 157.55.18.13] Premature end of script headers: index.php

Judging from the comments here, it seems this problem is not a Drupal core problem, but more related to specific server settings and contributed modules:

Drupal 7 core requires 32MB. Warning messages will be shown if the PHP configuration does not meet these requirements. However, while these values may be sufficient for a default Drupal installation, a production site with a number of commonly used modules enabled (CCK, Views etc.) could require 64 MB or more. Some installations may require much more, especially with media-rich implementations.

See more on System requirements

So I suggest moving this discussion to the forums, or marking it as bug and providing some clear steps to reproduce. Feature requests generally go to HEAD (Drupal 8), unless they have already been fixed there.

My VPS had 64 MB dedicated to it. We jumped it to 128MB dedicated to it before I posted my original issue. I now have 256MB dedicated and Drupal 7 runs smoothly. Finally.

I still get error 500's from the update script occasionally.

This is not a problem with reading directions. It is a problem with Drupal using an abnormally large amount of memory and processing power for a website, make no mistake.

@Routh: Does this only happen on your live server, or can you reproduce the same error locally or on another server with the same set up of modules?

I am sure performance and more efficient memory management will improve with Drupal 8. With Drupal 7 the focus was on usability.

However, Drupal's performance also depends on the modules you have installed and how well they are written.

It happens on the dev server with the same limits. On the dev server I had to mimic the same memory settings to get optimal performance. Now admittedly I run a community site, so in hindsight some of my modules may be leading to it. However when troubleshooting I trimmed my active/installed modules down to the core modules to determine the cause. The two modules I find cause the most memory drain are the update module and views. Saving changes in views can still make the server chug a bit.

Thanks for the information Routh. Now, I would consider this a bug report, not a feature request, because you say you get some errors. If we want anyone to dedicate time solving this problem, I believe the first step is tracking down precisely what conditions or steps cause those errors so that it is possible for everyone to reproduce (for more info on providing reproducible steps, see How to make an issue report).

As I understand, you experience this problem with Drupal 7.4. Can you reproduce on your local development server with a clean standard profile install of Drupal 7.x-dev without any content, but with Views and Ctools installed? If not, I would suggest as a next step generating content and users with devel module (which I can easier reproduce).
The Views module, together with devel module, also has a set of tools for measuring performance, and debugging which you can enable under settings (basic + advanced).

Ok, I will run through some installation scenarios in a couple weeks, currently have a lot on my plate with a job search and trying to iron out kinks with my live site, plus writing help docs for the users.

I also just want to mention that my DB size may be causing part of the problem. My site accepts novels and story submissions. A couple of these are close to 166,000 words in length. My db is currently 190MB (search index and caching included) according to MySQL.. so I suspect that this factor is playing a role in the system requirements of my site.

I will get back to this once I have more time to conduct some thorough testing on the dev server.