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
what modules are in use
what modules are in use ?
have you installed the devel.module to see if the amount of usage is as your host claims ?
this can't be good. I
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.
devel does use quite a bit
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 ?
As soon as I applied the
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.
There is a known bug with devel and PHP 5
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????
I'm using
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
Several
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
Hmm...
My first thought is:
Why doesn't your host do this? Mine does.
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
NancyDru
no teh host means users.
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.
That's correct, and it
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?
okay
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
NancyDru
theplanet.com? thanks to all
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?
BTW
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
NancyDru
Okay, I am able to solve and
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:"";
PHP5 is involved
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.
=-=
increase the amount of memory_limit in php.ini to avoid exhausting resources.
Question about that
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
NancyDru
=-=
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.