I have a few sites hosted at dreamhost, none of them open to the public, all slow as all heck. I'm assuming it's the drupal 5.1 site, since the rest are completely blank. I assumed MySQL was the problem, but dreamhost support suggests PHP. Does anyone have any suggestions or want to take a look at it? Thanks much.

Here's their response.

It looks like the problem is that your user's PHP processes are
continually being killed off and reniced by our process watcher for
bypassing the memory and CPU restrictions we have in effect. We have
these precautions in place to prevent users from crashing the web server
and adversely affecting other users.

Please try to keep your memory usage under 50MB to prevent this from
happening. You may want to check into implementing some type of PHP
caching mechanism or accelerator. Also, moving your domains to separate
web users will help isolate any issues.

Comments

vm’s picture

what modules are in use ?
have you installed the devel.module to see if the amount of usage is as your host claims ?

leobaby’s picture

this can't be good.
I enabled the devel module and turned on some of the reporting features and now I'm getting "500 Internal Server Error". I check forums and go to check .htaccess file and there's a 14mb file named core appeared in the site root folder. core dump? the /wiki folder still works for my site though.

vm’s picture

devel does use quite a bit of memory, though not sure it should be creating 500 errors.

was that 14MB file there before ? or are you suggesting that devel created it ?

leobaby’s picture

As soon as I applied the changes to the devel module I started getting 500's. If I delete the core file, it will reappear when I try to access the drupal site. I get that sinking feeling a reinstall is in my future.

zoon_unit’s picture

Avoid that combination! In fact Drupal admins need to place a warning message at the top of the Devel page to stop this once and for all. (search issues for more info)

Even worse, whatever causes this problem seems to embed itself permanently in Drupal, so that even if you delete the Devel module, the problem will resurface when you move a site to PHP 5.

The solution right now on Dreamhost is to switch to PHP 4, then delete devel, and all references to it in the variables and system tables. Then switch back to PHP 5 and pray.

As for Dreamhost, I'm finding that the bottleneck lies in mysql calls. (using the devel module under PHP 4, uh oh) But I'm also running into instances where websites will go down completely for about 10-15 minutes intermittently,

I've considered moving to Site 5, which has considerably faster mysql access, but I've seen some recent complaints about their service lately.

Isn't there a good, cheap, reliable Drupal service out there????

nancydru’s picture

247-host and I got a reseller package so I could host multiple domains. It's cheap and fast enough.

And I am using Devel and PHP 5 with no problem that I know of.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

nancydru’s picture

There are a bunch of good services, but that's another long thread elsewhere.

This is not the first time I've heard of DH suggesting an accelerator, yet most of the services I've looked at have one already installed. It's not even up to the user. I wonder why DH continues to avoid this easy solution.

And even more amazing is they know they are getting bad press about their MySql performance and do nothing about it.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

nancydru’s picture

My first thought is:

You may want to check into implementing some type of PHP caching mechanism or accelerator.

Why doesn't your host do this? Mine does.

...moving your domains to separate web users will help isolate any issues.

I assume they actually mean servers. But again, why doesn't your host do this? It's their server; they can move you with little disruption.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

vm’s picture

no teh host means users. evidentally this admin has more then one site registered to himself in the same space under the same username. so the load is compressed into one account. the host is explaining that it would be better for this user to have more than one actual account and spread out the load i think. at which point the user would have to purchase another account.

leobaby’s picture

That's correct, and it doesn't appear that any plans offer more memory or cpu usage, other than dedicated. I'm betting it was one of the views, but I wont find out until I get back up again. Can I re-import just my nodes?

nancydru’s picture

I understand. I'm doing the same thing with 7 domains on one account and not getting complaints from my host. But I have to admit that 3 of them are not getting much usage. And they have Zend as a standard.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

leobaby’s picture

thanks to all for your help. I'm gonna try to rebuild this with devel enabled early and see what happens.

You're using theplanet.com?

nancydru’s picture

I'm also interested in whether you can import just your nodes because I'm helping someone who got really messed up by trying out several access control modules.

Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database

leobaby’s picture

Okay, I am able to solve and reproduce the 500's. If I delete all of the rows that start with devel in the variable table , then delete all of the rows in cache, site goes back to normal. As soon as I enable "Collect query info" in the devel module, 500's come back. Not sure why they come back but they do.

here are the rows I deleted from variable...

dev_query i:1;
devel_query_display i:1;
devel_query_sort s:1:"0";
devel_execution s:1:"5";
devel_store_queries i:0;
devel_store_random s:1:"1";
dev_timer i:1;
dev_mem i:1;
devel_redirect_page i:1;
devel_form_weights i:1;
devel_error_handler s:1:"1";
smtp_library s:0:"";

Yann’s picture

Just wanted to concur that it has something to do with PHP5. But it's not that simple... I'm very new to Drupal abd I have to create a new theme so I installed an already built site locally on my Mac. I worked fine *with* PHP5 and zend optimizer turned on using MAMP (http://www.mamp.info/en/index.php). Then I decided to update to the latest MAMP install (don't ask me why...) and all hell broke loose...

The only thing I could get was:

"Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 23 bytes) in /path/to/site/drupal/modules/imagefield/imagefield.module on line 125"

Using MAMP to switch back and forth bt. PHP5 and PHP4 fixes/recreates the issue... with zend optimizer one or off.

Not very useful to know that if you're developing on a remote server from a hosting company, but a quick fix to get back to work if you're developing locally and have the flexibility to switch between the two.

I'm not sure if the older version of MAMP allocated more memory to PHP out of the box and that's why it worked, but this still shows that it PHP4 doesn't have that problem.

vm’s picture

increase the amount of memory_limit in php.ini to avoid exhausting resources.

nancydru’s picture

I find the php.net documentation to be less than fully helpful. If php wasn't compiled with the "memory" type options, can one even increase the setting? On my sites, I can find absolutely no indication that it has been accepted. And, yes, I have used Devel and phpinfo() both. Neither shows the memory setting.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

vm’s picture

If php wasn't compiled with the "memory" type options, can one even increase the setting?

your host can disallow overridding php.ini settings forcing you to abide by the settings they have set.

to insure your host doesn't allow overriding.

create a blank text file.
name it php.ini
add to it: memory_limit = XM
where X=some number insure no space between X and M notice M not MB

add that php.ini to your PUBLIC root not your drupal root.

doa phpinfo() check changes. If that alters the default values, then move the php.ini to your DRUPAL root and do a phpinfo() if values snap back, you are limited to using one php.ini file that must be in your PUBLIC ROOT. in a multisite install, this may method may pose problem as you may not want the same php.ini settings for every site.