Paid affiliate hosting advertisement
Site5 - weird things happen with Drupal 6.6?
I have one Site5 account that drives me crazy.
I have Drupal 6.6 installed and 100 web sites using the core Drupal. All work fine until this week.
Upgraded to Drupal 6.6 this week and now things are weird.
I'm doing a simple test - click "Administer" then "Modules".
I have about 100 drupal modules installed that all work fine.
However, some of the sites will load the Modules page in 2 seconds and many time out after 60 seconds. Some of these sites are exactly the same - one loads in 2 seconds the other is stuck in some kind of loop.
I've worked with the Site5 folks and they have no idea what the problem is. They had me run WinMTR and there is NO communication problem at all.
I have no idea what the problem is.
I've ground to a halt and if I can't figure this out must abandon Drupal and go back to TikiWiki.
Anyone have any ideas?
=-=
on the problem sites can you run the status update?
I am experiencing similar behavior on a new install of Drupal 6.6 and Drupal 6.x-dev
The site is extremly slow and will not fetch update status information.
yet, Drupal 5.x sites seems to work fine.
Nope
Nope not this second. When I click "Administer" Drupal times out after 60 seconds. WinMTR reports no communication problem at the same time.
Sometimes I can get thru Administer and the next time I will try the status update.
Thanks,
Site 5, Drupal 6.6
On Site 5 one of my site is still with 6.4. I may delay the upgrade, then.
However, I have an install of Drupal 6.6 on an intranet Red Hat computer on which I installed XAMPP, and I did notice a lot of slowdowns, specially loading the module page! But I've got no timeout yet, although the slowdown are noticeable. This is an upgraded intranet site, it was very fast when using D5.
As soon as I get some free time, I'll install a brand new D6.6 on Site 5 to investigate the issue and I'll benchmark the same installation on my dev computer in localhost.
Some of these sites are
Are they doing this consistently, or do they take turns at being fast or slow?
Does "the same" mean same database, same database tables?
Or separate databases, same modules enabled?
Same theme?
Are they both full domains or both regular subdomains?
Any differences may help figure it out.
=-=
mine is a single install on site5 which is using PHP 5.2.5 MySQL 4.1 and Apache 2.2
no contrib modules only default core modules enabled.
I may have to install 6.5 to see if I can help better understand what is going on.
Yes it is consistent - if
Yes it is consistent - if the site loads fast it always loads fast.
If it loads slow and near the 60 second time-out then sometimes it makes it and sometimes it doesn't.
I am loading 6.5 back on the same server right now and let you guys know - a few hours.
I had Drupal 6.5 on site 5
I had Drupal 6.5 on site 5 but that is just the core site I uploaded for test purpose.
It seems to be ok.
What hosting package are you using with site 5 ?
Can you ask BT & T in their forums for some tips on this ?
=-=
That may point to something specific that changed in the Drupal 6.6 release.
Off to checkout 6.5 and install to see if things do improve.
Not sure B&T can help until we can narrow things down a bit. If we can narrow it down to 6.6 I can show B&T the changes that occured in 6.6 as well as file an issue against core.
=-=
happening to me with 6.5 as well.
This may remove drupal from the equation altogether.
It only seems to happen in the admin screens. Everything else seems to work as expected.
what happens if you disable
what happens if you disable the update status module?
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
=-=
One would think I'd remember to have checked that as I've mentioned it many times to other users on the forums who have slowness issues in the admin area.
with status update = disabled were back to normal operations.
wonder what changed @ site5 that would have caused this as this wasn't happening over the life of 6.x
Thanks Joann
I have d6.5 on juventus @
I have d6.5 on juventus @ site5 (which i don't believe has been upgraded to the planet yet) and Ive noticed no change. I'm going to update to 6.6 and see if I notice a difference. I don't understand why update_status should check any time besides when it's told to. Do you have update status advanced settings? I have it and have it set to only check for updates daily. maybe that would help. I'll try disabling and see if I notice a change. Report back in a few.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
=-=
I am on the planets servers, on base to be exact. The update status settings were whatever is set at default by a drupal install.
Per my testing I'm having no
Per my testing I'm having no problems with d6.5 or d6.6 with and without update status advanced settings module installed. I wonder if it has something to do with the planet servers.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
=-=
I think it has to be something on site 5's end. Maybe base has too many drupal sites on it requesting data from d.o. : )
I can live without the update status module. Later today I will throw the update status module on my D5.12 install to see if the same symptoms occur.
Last night I threw a few modules at my D6 install that was having this issue and all is well with the update status module disabled.
Installed Drupal 6.5 over 6.6 - same results
I installed Drupal 6.5 from last week and deleted 6.6 - same timeout error.
This has nothing to do with Drupal but some weird thing at Site5.
I guess I'll try a little more with Site5 but I may have to find another hosting site.
What hosting provider has Drupal running fast and that I can backup my 1.5 GB drupal site (100 web sites) each night from a Control Panel? (Site5 times out after 60 seconds of zipping files).
Thanks everyone.
Try something like this in
Try something like this in php.in to see if it makes any difference:
max_execution_time = 60mysql.connect_timeout = 120
(these are twice the default values)
Are you getting any strange huge files from server crashes, named "core-something" in your web directory?
---------
By the way, about Site5, I do get similar timeouts and need to hit "reload", and I also consider some of their practices to be "behind the competition", so I've be thinking moving to hostgator (because I am as cheap as they are).
But that's not my day job, so I don't give it much thought.
Thanks but no change
Made the changes to php.ini but still times out in 60 seconds - Site5 never seems to pay attention to this file.
Probably those settings were
Probably those settings were not a good idea anyway. If a response is to come after 2 minutes we don't want it.
How are you handling your
How are you handling your cache? I've had timeouts, out of memory errors, plus packet to big, all caused by the module page in 6.6, plus in 6.5
My work around in my situation was a couple things. I moved my site to a VPS where I could use more memory, but that didn't solve the issue, it just allowed the query to finish, so I could see the whole thing without getting the out of memory error.
So I went and disabled cache_menu as it was returning a query several pages long and 100's of MB in size.
Loading the module page could take 3min.
It still takes along time but does not time out and gives no errors. If you search the forums there's info on how to disable it.
also do a search for menu router: and see what you find, I think they are all related to the same things.
It is also advised that any large sites, utlize some sort of php caching method like apc, eaccelerator, etc. Don't know about Site5, but they may not have these available.
Don't use cache at all.
Don't use cache at all.
=-=
for me it's definetly the update status module that is a variable in the issue here. Though I don't believe it to be the fault of update status as I've never had to disable it in the past for the site to function as expected.
I can make the page load if...
I remove:
Wordfilter
Videofilter
Shoppinggads
Pathauto
Can't live without Pathauto.
But like I said, other web sites, using the above modules have no problem at all.
This goes for brand new installs too; some work fine some die.
Weird
just because caching is
just because caching is turned off, DOES NOT mean it's not caching. That is for page caching only and has NOTHING to do with menu_cache or other caching mechanisms....
Like I said, I disabled menu_cache which was returning absolutely MASSIVE queries. killing the 64mb limit on the shared host, and still when moved to the vps, used 170MB of ram, and drove my CPU usage to over 100%.
You may want to look into it, before disregarding it.
Note: My cache is ALSO turned off... but that doesn't effect ALL site cache.
It seems that people on
It seems that people on shared hosting are experiencing more and more issues with Drupal. It may be advisable to switch to a VPS (they can be had for as little as $10/mo... mine is $20).
I get 288MB of ram, vs 64mb.
After all my necessary services are loaded, I still have about 210MB of available ram for drupal. This simply will NOT happen on a shared host.
If you are limited to 64MB or less, using D6 with 60+ modules, EXPECT to run into issues.
in #drupal this has been expressed to me multiple times, although I think it's a critical flaw to force that type of cache rebuilding all at once, they insist it's by design, so I wouldn't expect a fix anytime soon, and would suggest work arounds as I described.
Yes, this one was worth
Yes, this one was worth trying: http://drupal.org/node/321154#comment-1059946
No luck
I made the modifications in the post but the same Drupal sites lock up - no luck here.
I'm at Hostgator on LAMP
I'm at Hostgator on LAMP (CentOS, Dpl6.6) and getting same issue when trying to go to the modules page. I did what was written on the provided link and it had no effect (that I can tell).
The system was getting slow, then I loaded Ubercart and worked with it for a while. This is a demo system (no live users, no users beside myself).
I consistently get this error trying to go to admin/modules
Fatal error: Out of memory (allocated 38010880) (tried to allocate 120290 bytes) in /home/kbrooks/public_html/demo/includes/database.mysql.inc on line 301I also went through and removed almost everything from the left side bar (the link talked about menu cache)... still no change.
-- are there instruction on how to down-grade back to 6.5 anywhere?
The error says that
The error says that available php memory was 37M, but more was needed in that page (it depends on your installed modules). You must either disable some modules or increase your php memory_limit (see http://drupal.org/node/207036)
An "out of memory" error could also have caused the update.php program to fail before completion when you ran it, leaving your database update to 6.6 half-done and unstable (usually, a failed menu rebuilding). Probably that is the problem, and not any particular Drupal version.
The only practical standard way to downgrade to a previous version is to load a backup of the old database taken before the update. However, if you don't have a backup and if it is a minor update, you may be able to reverse it by putting back Drupal's files and then comparing the modules/system/system.install files of the two version, near the end, to see what changes to the database the new version has added, and trying to reverse them using SQL. For 6.5->6.6, for example, there are no changes to the database, so you can probably just put back the old Drupal files and run update.php.
Design fault?
I'm no programmer but the problem I'm having sounds like a design fault in Drupal and needs to be fixed.
But I really have no idea what's going on.
I guess I'm at the worst of all decisions - all the hard work in the past 3 months down the drain and go back to Joomla or TikiWiki or spend a week trying to find another hosting site and hope this problems doesn't come up again.
This is hard but my gut tells me to drop Drupal and go back to something that I've really had no problems with - TikiWiki.
The reason I left TikiWiki was that I wanted 100+ web sites using one instance of the modules and maintenance would be a snap. TikiWiki does have a way I've learned and I guess I must investigate this.
Guys, this is a killer of a problem that I hope someone at Drupal addresses at some point.
So for now Drupal has a catastrophic error that I am reluctant to find a temporary fix that might come back and still get me as my web sites grow.
This is really a humongous problem....
Thanks for all the help - I'm going to restart TikiWiki I guess and spend the next month moving everything over to it from Drupal - that sucks to say the least.
=-=
Something for you to look into.
The above quoted from the site5 - resource usuage policy = http://www.site5.com/support/rup
The ones I've bolded would be problematic for multisites running on a single database, especially if those sites are fairly active. with over 100 sites running on a single DB you would have to divide the limits by 100 to give you limit for each single site running on that DB.
The above would hold true for any script using one database to host many sites.
True, you must check the RUP
True, you must check the RUP before choosing hosting. And unfortunately, you must also check it regularly afterwards, because it changes without notice. They reserve the right to do that, and actually in this case they have.
One other point which strikes me as funny is a host's explanations about overselling. Overselling does make perfect sense in some cases from a web business perspective, and the explanations would be great in a business seminar. However, what the customer needs to hear is: "That is no concern of yours, we shall deliver what we promised you any time you need it." If you have terabytes of disk space it is not cool to get an "out of disk space" when you try to upload a Drupal module.
But that's just how I see it. Any host has done their planning and can run their business in whatever way they see fit.
By the way, in my case the delayed access problem appears in empty testing sites with almost no content and zero access, and the update status module didn't make any difference.
=-=
I'll have to watch for more trouble ahead. If necessary I'll find a new host. This isn't the only oddity I've found with site5 lately. It seems to me that shared hosting services are being a little wishy washy. Offering a ridiculous amount of bandwidth that most sites won't reach while limiting the other resources that database driven sites require to work effectively. Shared hosts are starting to = static hosts, I think. Static sites aren't the way of the future though.
I think it's time for me to start looking at VPS and dedicated boxes again.
None of this would explain what I'm getting
Site5 insists that nothing they have or are doing would cause my 60 second time outs - they have monitored my site while I've been testing.
I have 3 accounts with them and even the smallest account has just 3 Drupal sites - one has no problem and 2 have problems. All 3 are brand new installations with no modules activated. 2 of them timeout so I can't get to admin
On this one I have to agree with Site5 - this is a Drupal issue which I have no expertise in fixing.
That is a possibility
That is a possibility. I can neither agree nor disagree.
If you wanted to be sure, you would need to find one Drupal difference between those sites, and test for it. That difference could be a theme, a hundred disabled modules visible to only one site, the way they point to their document root directory, anything.
Did they tell you what they monitored, what they were looking at, and what they found? What was the server doing during the 60 seconds?
New install
Before dumping Drupal I'm going to totally clear on of my sites and do a fresh Drupal 6.6 install and add 5 web sites to it - without ever logging in and touching a single thing (I hope)
Then I'll have positive proof - who knows.
My main Drupal site, the one I spent 3 months day and night working on, has no problem at all - It is really big. But if one day I see the 60 second timeout when entering Admin - l then would be out of business and lose customers while finding an alternative.
So I will do this in a day or so.
Site5 never said what they did but looked at the ONE and only mySQL and saw nothing out of the ordinary - no other heavy activity going on a 1 AM in the morning when I was doing this.
I'll get back in a few days.
=-=
I'm already experiencing it on a fresh install. I'm surprised site5 didn't describe a script problem if it was drupal.I believe they would have been able to narrow it down to a file or a process which was causing the issue. For now I'm still ok with the update status module disabled.
I can attest to it being random. My acquia drupal test install is working fine with update status on, so long as I don't request an update of status. When I do so I don't time out but I get an unable to fetch update information message after an unusally long time of waiting on a page load. This part is consistent with all D6 sites I've installed regardless of version.
This is not an attempt at finger pointing at the update status module. Merely an observation after playing with this most of the day today.
Site 5/The Planet?
Are you both on Site 5 using server located at The Planet (Apache 2 + MySQL 5)?
I'm asking because I've just upgraded a very low traffic web site to version Drupal 6.6 on Site 5 and I do not see any problem. However, I am on a hold server, over there, which is running Apache 1.3.37 and MySQL 4.1.22. I've also configured .htaccess to load PHP 5.2.0.
If you are both on The Planet, the issue might lie with MySQL version, Apache version, or even any server configuration which should most probably be different from legacy servers at Site 5 from the newer batch of server located at The Planet.
It'd be interesting to know if problems are only for those located at The Planet, since all legacy servers will be migrated to The Planet, of which mine still haven't moved yet.
=-=
I'm on the planet servers w/ problem (without MySQL5 as that isn't an offering at least for me if anyone on site5 has MySQL5 its the resellers and I'm not one of them)
Worldfallz is on legacy servers w/o problem
I don't believe anyone else mentioned what severs they are on.
I am on a server with Apache
I am on a server with Apache 1.3.37 and MySQL 4.1.21, and with PHP 5.2.1 enabled through .htaccess, I don't know what The Planet is, and I often get timeouts and need to refresh on some rather idle sites.
=-=
http://www.google.com/search?hl=en&q=site5+planet&aq=f&oq=
Summary:
The planet datacenter is where the site5 servers were being migrated to before the migration seemed to come to a screetching halt. It was some kind of partnership that was formed or some such.
that's the first I've heard
that's the first I've heard about it coming to a halt-- any idea why?
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
Migration is still ongoing
The migration to The Planet is still ongoing, although on a slow pace, specially for older legacy servers:
http://forums.site5.com/showpost.php?p=138922&postcount=45
Also note that Site 5 have new owners:
http://forums.site5.com/showthread.php?t=25045
The new CEO wants to hear about all issues, comments and all. He published is email address: "bwb@site5.com". Why not send him a message?
Here’s what I did to a
Here’s what I did to a site that locks up:
1) Changed the …/sites/all/modules to /sites/all/modulesX
2) Got into my locked up site and deactivated Update Status in Admin/Modules
3) Returned /modulesX to /modules
4) Refreshed the browser
Got the following error:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 512449 bytes) in /home/m4inform/public_html/drupal/includes/database.mysql.inc on line 301
I can only get 32MB no matter what I do to php.ini on Site5
Does this tell us something?
If it doesn't go past 32M
If it doesn't go past 32M maybe it is a limitation on that server? I am on an old server which doesn't have such a limitation but I don't know about the new servers. Was the php.ini a local one inside that Drupal installation directory? Try with an ini_set('memory_limit', '48M'); in settings.php to be sure, or check if you already have a lower setting there (normally such a run-time setting would override php.ini).
If you manage to increase the memory, then run update.php once to rebuild the menu cache and see that it completes, because many Drupal problems have been reported after a menu rebuild interrupted by lack of memory or by a timeout.
Back in business boys and girls... :)
I changed php.ini to 64MB, changed ...sites/all/modules to sites/all/modulesX unchecked Update status, renamed modulesX back to modules and Drupal is back to normal!!!
Thank you so much guys....
Obviously the Update Status module has a bug.
I could have sworn, on a stack of bibles, that I've changed the memory size in php.ini in the past and it never really went past 32MB - it does now.
P.S.
This still doesn't explain why some web sites, in a mulit-website Drupal worked and some didn't if the Update Status module was checked...
Not a bug
I am happy to find out you resolved your issues by allocationg more memory to PHP.
This is not a Drupal bug. Drupal takes more and more memory to run. More modules installed, more memory is needed to run.
Drupal 7 will properly check if enough memory has been allowed for it at install time, though. Other memory checks may need to be implemented to warrant problems like this.
It still is a bug
Wait a minute here - Drupal 6.6 has a humongous bug in the Update module that has NOT gone away.
This bug caused me the loss of about 50 hours of work - this is not a trivial bug.
I am up and running with 64MB of memory ONLY if Update is disconnected. If it is connected the 64MB of memory is no help - I get caught in the same timeout error.
On the one Drupal 6.6 installation some web sites load Admin in 2 seconds and some timeout after 60 seconds - that bug has not gone away. (If Update module active)
Who ever is in charge of Update needs to track down this bug and fix it or ALL Drupal users will have some kind of problem - that's a WAG on my part.
But I'm happy for now and only pay $2.50 a month to Site5 for unlimited web sites, data transfer, and storage - I have 3 sites there 1) Production, 2) place to install new Drupals and 3) a place to experiment with anything I want. All that for $7.50 a month - a bargain.
Site5 was right there to help me when I called for help.
=-=
as stated, it isn't limited to 6.6 and as cog.rusty points out the update status module is dependant on the drupal.org server/s to return the information status update is wanting. Therefore there may also infrastructure variables here outside of site5's control.
You are running out of apache resources or mysql resources
Hi, just now seeing this and there is a lot to parse. Let me offer you two possible diagnoses.
You say you hit a 60 second time out. If this is returning to the browser as an apache error then it is an apache issue. If you are on shared hosting you share your apache config with everyone. When apache spawns the maximum number of threads it queues the next request.
When you are the front of the line, you load quickly, when you are at the back of the line you wait in line. If you wait longer than 60 seconds, you timeout /with apache/. The key here is if you are getting a network timeout from apache.
The second possibility is that the update status module generates a large number of queries (probably multiples for each module enabled) thus if update status is using more than the 15 concurrent mysql connections.... you are queued and wait in line again.
Either scenario would be difficult to adjust on shared hosting, but I hope this sheds some light on your problem. Cheers.
-------------------------------------------
Sam Tresler
http://www.advomatic.com/
=-=
Thank you for the education Sam. That would certainly explain the issues at hand.
One possibility is that the
One possibility is that the random delay problem is due to temporary lapses of the drupal.org server which the update status module queries for updates or for returning module usage statistics.
If that is the case, I think that a good bug fix would be to make the update status module give up quickly if it can't establish a connection immediately.
=-=
which makes sense considering I've been running 64M confirmed by phpinfo() on my account without any contrib modules.
No time outs, only an unable to fetch message.
With that, this wasn't happening a week or so ago.
I got a similar problem too
I got a similar problem too yesterday. All pages under admin time out and return blank on *some* sites, until I disable the update module in the database. So, hopefully I'll be able to try things to figure out what is wrong.
----- Edit:
Damn. They all work again now with the update module enabled, so I am left with the initial assumptions.
This is a big issue.
I am using Drupal on 1 site on GoDaddy. Brand new Install. No external modules uploaded. Only Core Modules uploaded. Only system modules activated. Customized Theme (only modifications are to CSS and Images: NO PHP Customization).
And I am getting this same problem.
Drupal needs to be tweaked for the masses. I hear it from alot of developers that they would love to have more people involved and creating and developing for Drupal. However, with Drupal in constant expansion, further development and modification, how is anyone that is not a DrupalHead going to join up?
I think we need to fix Drupal 6 and sit on it for a few years perfecting it. Fixing every issue making it slimmer and faster and efficient tweaking it to insanity. Once that is perfected we can move on to Drupal 7.
Just what I think.
Also this is just one Drupal site I have. I do have others on other hosts but they are still sitting on Drupal 5. The above site was my first install of Drupal 6 and I am afraid, very very afraid...
Tone
No offense, but we don't
No offense, but we don't need to fix a cms, simply because it doesn't work very well on the internets WORST recommended hosts like godaddy.
Plus don't you expect newer versions of software to require more resources? I know that EVERY other program on earth pretty much does. But here on Drupal, 6 uses more resources then 5 and it's concidered broken.
And we ask for developers to help out, because it's needed, but if those dev's are not smart enough to work in a local environment or host on a vps/dedicated server then they are not serious programmers anyways.
I don't see any people in this thread not on cheap shared hosting, complaining. I also don't see any complaints from the most active dev's when in #drupal-support or #drupal on irc.
My best guess is it works fine (that's why it wins awards, that's why it's the most popular, that's why it has such a HUGE following).
Sitting on a version for a couple years will leave us behind as new technologies come about all the time.
I would suggest that all the people in here complaining maybe take a look at the "problem" and try to patch it, instead of insisting the developers who are NOT experiencing the problem to fix it. I'm guessing those developers are not experiencing the problems because they are running it on a server with enough resources.
There are many limitations set by hosts.
Max Packet Size
Max PHP Memory
MySQL max simultaneous connections
Max Upload Size
Time Outs
Most of which will effect a sites performance and in some cases seriously hinder it.
With hosts moving to PHP 5.2 the memory monitoring is much more strict, and errors appear earlier then earlier versions, this is true for MANY MANY MANY scripts if you googled it. This goes to show that Drupal is fine, as the main dev's have insisted on in these threads multiple times but no one listens.
"Drupal doesn't run on my $3.99 host! It's broken and flawed"
Do you complain the most complex and latest games don't run on your budget computer?
What's the difference. Your installing one of the largest and most robust open source cms's on the cheapest system you can find.
15sec CPU Cycles, 2mb Upload limit, 32MB PHP Limit, and yet people expect it to work.
I suggest reach in those pockets for an extra $10+ and these problems will go away.
Typical open source issues. "Software was free, I want it to run my way on my almost free server, and if it doesn't I'll bitch and not submit patches, because it's flawed".
It's been said multiple times that you NEED more memory resources then many places allow.
Example: Image Cache, says it recommends atleast 96MB of ram. Bet that's a flaw too, and it should work on shared hosts without problems?
If you want to run it on the cheapest gear on the net, I suggest disabling the menu_cache which is the bulk of the resource hog and be on your merry way. Or set up file based caching.
Last comment is have you noticed in all these threads the people that say "I raised my memory limit and everything works great now!"
Point AND Case, get more memory do the recommended changes. Or patch it and be every shared host users savior. Don't expect D7 to blaze on shared hosts either.
Danger Will Robinson.....
Now this attitude will lead to a black eye on Drupal’s reputation – it works only on expensive vps providers?
I’ve found countless problems with Drupal 6.x – most I can use bubble-gum and bailing wire to find a patch.
However, there is no doubt in my mind that Drupal is going at least 3 different ways all at the same time 5.x, 6.x and 7.x. 6.x has lots of hiccups and as someone who is trying to use it I can attest that it seems to have enough problems all by itself – multiply that by 2 or 3 and I can’t imagine how Drupal doesn’t start to get black eyes.
But, I’m just a user and have not contributed anything here but my reporting of bugs and weird things going on.
If Drupal wants to plaster all kinds of warning stickers (Warning: Drupal 6.x doesn’t run on cheap hosting sites) that’s something you guys will have to consider.
I thank Drupal for allowing me to host 100 web sites on something that does work most of the time. The alternatives are much worse. But each day I wonder just what new Drupal thrills I'll stumble upon today...
I pay $20/mo for my vps,
I pay $20/mo for my vps, which allows almost 300MB of ram, I think that is far from expensive. And it doesn't need warning stickers and will not get a black eye, and I speak mostly for myself, only letting people know this is well discussed and the way it functions "is by design" in 6.x, things may change in later versions such as 7.x I do NOT know. However major structure changes are generally not made mid version as it would cause a landslide of problems with contrib modules. The thing is that if you want to use it, there's a montage of options that can be done.
Route some of your cache to file (possible with drupal modules like cache router)
Eliminate caching on things like menu_cache (directions in the forum)
Increase Memory limit to atleast 64MB (many shared hosts like hostgator allow that much)
Move to a budget vps
Use less modules
All of those things and different combinations will allow you to solve your problem if your gear is not quite up to par.
Remember many of the people complaining are using over 60 contrib modules, with heavy weighters like cck, views, etc.
Can't have all the bells and whistles on the cheapest server space known to man.
Here's a question, if you can run a massive 120 Module drupal instalation with tons of views, with all the bells and whistles, then expect it to run on a cheap shared host because they offer HUGE bandwidth and space, why would any business use a vps? If we could all run the cats ass websites on shitty as servers, we'd all do it, but enterprise level cms's all have minimum requirements.
Like I said everyone of these threads has someone saying "I raised my memory limit and the problem went away!" I suggest scrolling up and seeing the happy people that say it.
Bottom line is, if it's a huge problem it will be looked at and if it's major structure changing will probably go into 7.x
There are MULTIPLE options to make it work, sorry it's not out of the box for every server set up cheap to expensive.
And anyone running multi sites from 1 shared host is asking for trouble because they all share that measily amount of space.
64MB/6 makes for very little play room. It may work for awhile, but I'd say the clock is just ticking.
What would it take...
As a non-programmer I'm always amazed how much computer expertise is expected of me.
Why not have any memory hog module just check memory and stop short of running out of memory and locking up and say:
"Hey, you need more memory - about 32 MB more would be nice".
Locking up and having users waste vast amounts of time I guess is ok for a free-bee program like Drupal but I'd suggest programmers take a little pride and just issue the warning message.
But, I'm in no position to complain about a free program.
P.S.
Can you guys recommend a $20/mo hosting site - the ones I looked up were much more expensive.
Also raising my memory limit in this case didn't do a thing - I've had to disconnect the module in order to run. Maybe more memory will do the trick - this I will investigate.
Thanks
Efficient use of Resources - ain't managing my own server
I want to defend some us dummies that use managed hosting...
I've been pretty successful building websites, and I can program enough to do a pretty good job with them.
I'm not a systems guy. Unless there is managed VPS then it's not something I want to tackle.
My experience when checking out VPS... I need to learn, Linux for sure, more php and apache. Afterall, I'd be managing my own server.
So, when the friggin' thing crashes I'm out there in the desert with no water. Thanks, but no thanks.
--------------------------------
I don't know where you can get VPS for $20, and I'm sure it can't be a managed VPS. In fact, I'll bet it doesn't have zip on it as far as tools.
Now... I can build my sites fast enough to be passable, and they look pretty good, and with managed hosting....work good most of the time.
--------------------------------
I can do a lot of things, better than the products available professionally, but do I have time to re-invent the wheel everytime.
I make efficient use of my time as well as I can. I don't mind if a web host makes alittle money, as long as the wheel keeps rolling.
When the webhost pays his techs for support, that cost is spread over a wide base of customers. That is more efficient use of resources.
Not ragging on you here, but there are just other things to consider.
If you have to do everything yourself, after a while you are just "flat out NOT productive".
Everything comes down to
Everything comes down to research. I tried Eapps, which is semi managed, and you don't NEED to know linux or php or anything else. I had my site migrated to a vps in justa couple hours. Which included waiting for them to call and verify the order then activating it. At Eapps, and I'm sure many others you can choose the software you want installed.
I found it just as easy as using something like fantastico, but instead of just drupal, joomla, phpbb or other such software, the menu gives you options like: Apache, Webmail, PHP 5, Mysql etc. Simply look at the requirements for Drupal, and select the appropriate ones when you sign-up. They are automatically installed and configured. There is 24/7 support as well.
So yes, not only are you unwilling to learn the systems, but it seems your unwilling to investigate if you need to learn them at all.
Plus, the other option I guess I could of mentioned, is move to a better host that allocates more resources and don't pick the cheapest sources. Proper investigation will land you a shared host or vps that will do the job.
Here's the problem. Rebuilding the cache tables takes alot of data and often the mysql configuration is set with a low packet limit (default 1MB), it is also set with a low time-out limit, which is also bad news.
Also pointing fingers at drupal simply isn't fair.
Google wordpress, joomla, etc and check for "PHP Memory limit"
THEY ALL have numerous threads with people on shared hosting complaining and saying they need to raise memory limits to atleast 64MB sometimes just to get them to run.
Now drupal is more robust then most other cms's, yet people expect it to not suffer the same problems that all large php scripts have.
Again like I said, those that think negative or are too lazy to investigate the actual work needed to get things running on a vps.
Like I said on my $20.00 VPS I have 288MB of ram, I use about 70 or so for my system resources (php, mysql, webmail, whatever else I chose). Leaving over 200MB for drupal. That's 3x what your shared hosts offer.
1 more point, my 288MB is GUARANTEED, and I have additional available burst memory if the site happens to need it to complete a task, but they do not guarantee this burst memory, because it is shared.
Again I repeat like before, moving to a vps isn't the only solution, you may need to evestigate other options within drupal itself.
Back on 5.x I had 130 modules installed, then one day Out of memory. Stayed on the phone with my host, got my memory upto 64MB (on shared host). I installed Cache Router module. Took some of my larger caches "Cache, Page Cache, Block Cache, Views Cache, etc and had them cache to file (Suggested BY most hosting provider) This cured my problem. It may work just as well in 6.x
Again for those thinking I'm in here simply to defend, or to belittle, that is simply not the case. Again.
We know there's an issue with the caching methods, mainly related to menu_router (not to be confused with the module), and with menu_cache.
I figure this is because the menu system in 6.x went through so many changes.
It has been noted, some minor NON structural changes went into 6.3 to avoid issues, but they persisted for some people and worked for others. The most effective patches were commited to D7 and will be backported to 6.x if possible when possible.
As for what to fix. Again I recommend.
1. switch to vps or raise memory limits on shared hosts as high as necessary maybe switch shared hosts if you are scared of vps's (I was, then once I jumped in realized (atleast with the service I use) it was no harder then setting up on shared server. (they even allow you to install drupal from the control panel)
2. Learn about cache management and put it into effect. File caching is a good option on shared hosts. (due to mysql limits)
3. Disable caching on the problem areas. Like menu_cache.
Unfortunately most of what I see in this thread is people not wanting to learn, not wanting to try other things, and not wanting to pay more then the cheapest they can find. I hope drupal is the only thing you put that attitude towards.
I could sum up most of the resonses with "I'm cheap, I'm lazy, and Drupal should work for me out of the box"
Now I'm not pointing fingers because I thought the same thing when I ran into the dreaded errors moving to 6.x But I put asside my ignorance and tried cache management as suggested in the forum (it worked), then I tried the menu_cache disabling option, it worked by itself for awhile but best with cache management (this was on a shared host...hostgator). It was image cache recommending 96MB of memory minimum that made me switch.
After the switch I haven't yet needed to set up cache management, nor have I had to disable any caching. But before launch I will definately be putting cache management into effect. Also remember that on vps's they have options like memcache and eaccelerator that sharedhosts don't offer that really enhance php execution times.
Again please excuse me if I offended anyone, I just don't see the point of half page posts saying "I don't wanna learn", "I shouldn't have to pay more", "It should work for me, without any modifications, no matter where I am".
You can see posts above and in all similar threads that can be summed into those quotes. If you're smart enough to be in here and complain, it means your plenty smart enough to start on a managed or semi managed vps.
Best way to think of a managed vps is like shared hosting with more system resources and root access. I haven't even needed ssh or root access on my vps yet, and my 6.x is up and running with hundreds of modules, including views, cck, and ubercart. My current module directory has 133 folders in it.
I'm hoping that atleast one person will research one of the MANY options of getting it to work before rebutting with more "I might have to learn and don't wanna" posts. Trust me, your all probably FAR from stupid and not giving yourselves enough credit.
I don't know linux
I don't know php
I don't know mysql
I have never used ssh
I don't even understand what apache really does.
and I DID IT! so you can to.
My site runs on a vps I set up with ease. And if it goes down I will seek their support to get me running again.
The other great thing is I don't have 100 icons in a control panel that I don't and will never use. I have what I need to run drupal + mail + stats.
Thanks...
Thanks, and the $20 hosting company is.....
In business there is a thing called "Barrier to entry" - this is the hurtles one must face to do what a competitor does. All these "Free" CMS have huge, did I say huge, barrier to entries that will keep my competition from doing what I'm doing. So on the one hand the barrier is fine after I go thru the learning curve.
Most sophisticated programs, like MS Word, all have the barrier to entry. Granted many folks are lazy and just have the 20% of us pull them in the wagon with us. So I'm all for a program being hard to use, impossible to understand, and a little whacky helps too.
There is no such thing as a "Free" program out here on the Internet. The money we would normally spend for a slick, clean, bug free program is, sadly, squandered hunting down feisty bugs and wacky things that consume huge amounts of time. Drupal is better than most in actually working and allowing for future improvements.
The hurtles I've jumped getting this far make me all the stronger. I do appreciate all the feedback on this Drupal site - many/most CMS have no feedback and thus must abandon them to my competition who I smile at and wonder how much time they will burn up on that Free CMS.
But if Drupal, or any CMS, ever want's go actually make a buck or two, they will have to work with us dumb end users and not assume we are Geeks who love to spend countless hours learning all the finer points of things that have just 3 initials, like php, vps, SQL,....
I would gladly pay $500 for a license to Drupal that had me spending my time being productive with my customers. Instead I spend thousands of dollars in learning how the Geek squad works with a free Drupal. It's more efficient for me to let others figure out this stuff and make Drupal more idiot proof.
But, like I said, I have no complaints with Drupal - it's head and shoulders above the other "Free" CMS out there.
P.S.
My big fear is, of course, an actual $500 CMS package that actually works and allows for unlimited usage and web sites and the hosting site just costs $2.50 per month like my Site5. Ooooo, I hope that never happens.
Drupal isn't in the business
Drupal isn't in the business of making money from licensing, it's open source and it's community would die. The $20.00 hosting I use is eapps.com I'm sure there's others. I'm glad someone seems to understand that not everything is plug and play, otherwise there'd be no developers and just theme designers.
Anyways, check out eapps if you want to avoid the learning curve of vps management. I picked them for simplicity as I too, do not have the time to configure a complex system.
Thanks!
Thanks!
I am willing to learn! This
I am willing to learn!
This has been a very helpful thread.
I will search on file caching and disabling menu cache, but if, in hand, can any one can just post quick links to these ?
Can there be a checklist, particularly for shared hosts, to ask whether they provide those resources
for example
max_allowed_packet = 4M
max_connections=100
max_user_connections=10
connect_timeout=15
max_connect_errors = 10 ---> are these OK?
Are there any Drupal specific VPS services ?
A few questions on Eapps : if not out of topic : could you please say
Why it is semi managed?
Can it be fully managed like shared hosts are ? Does one have to install OS, reboot etc ?
Can it be as easy as shared hosting or any extra things to be done?
As for the checklist,
As for the checklist, there's more to concider then just those as thoseare mysql related only and other important things are php memory limit, upload limit etc. And even cpu cycles depending on what you plan on doing.
example Image Cache suggests 96MB of ram for php. Almost no shared host works with that, so imagecache + shared host is pretty much a no-no. Not saying it won't work, but someday... it'll go down.
Eapps is very drupal friendly and it can be installed from the control panel if you want.
VPS's come fully managed (most expensive, highest service level, support like a sharedhost, they can setup, and help with things)
Semi-Managed (Mid-Expensive, high service level, but mainly for support. They rather you set it up, they'll help if you have problems, or can lead you to the fix)
Un-managed (Least Expensive, your pretty much on your own)
Now keep in mind that almost all of them come with control panels (like Cpanel). That allow you easy setup of your site.
Example on Eapps when signing up you choose the software you want. For Drupal I picked.
PHP (obviously)
MySql (obviously)
Eaccelerator
Apache (another fairly obvious choise)
Awstats (traffic and bandwidth stats)
Webmail (Need mail)
Squirrelmail (Webmail client)
ProFTPD (Ftp Server, so you can connect via ftp)
PHPMyadmin (Mysql management)
Now those just require checkmarks beside each one when signing up (more can be added later if needed, you're not limited to those you choose at signup)
If you chose those options then after they call you to confirm your order, you will be able to login, and all those items will be installed and configured ready to go.
You make a new user under ftp management, upload your site and there ya go.
As you can see all the software I chose above, is standard on shared hosts. Using them will be the same as you are used to.
If you make changes to files that require a server restart, you simply log in, click restart server, and it's done.
Sorry to go off topic with the server stuff, but it's important for people to know it's really not that hard.
Instead of signing up for a free host that offers 40 pieces of software you don't need (2 sql managers, 3 webmail clients, etc)
You get a streamlined interface with only the things you need and use.
Hi! Thanks a lot. I will do
Hi! Thanks a lot. I will do a bit of thread hijacking if that is permissible, since this is a really important thing.
If you do not mind and have a moment or two , can you please say whether
semi-managed or unmanaged means that I have to do just click and select stuffs I need ?
Does GD lib, clean url etc get automatically installed ?
Do I ever need to restart server ? What can be such an example, keeping in mind such situation never arose in my shared host experience ? Can the server be just silently down (with no email notice etc) and need a restart by me ?
One of the shared hosts suggest that php values can be easily altered by altering those in php.ini. Certain things does obey changes made in php.ini - I have found in past. How far this is feasible w.r.t drupal ?
Can the $10 eapps package be a good start to test the waters ?
I think that eapps would be
I think that eapps would be a good start, but PLEASE do not take this as a promotional thread, I'm not affiliated, and as mentioned earlier in the thread, am a new client of theirs, however was referrered by atleast 3 other drupal users in #drupal-support
For unmanaged I was referred to slicehost but chose against, as unmanaged means your on your own.
of course, It would be nice if you told them I referred you if you decide to sign-up.
Well the point and click install of things depends on if the service has a control panel installed (much like the one you use on your shared host... shared hosts often use CPanel).
I believe the $10.00 package would be suitable for a small drupal site, as it has 160MB of ram. With everything I have installed and running I use about 70MB Consistantly (running php, mysql etc). That leaves you about 90MB (50% more then most shared hosts). I think it would be more then suitable to start.
Semi-managed or unmanaged has a little bit more to do with the service level from my understanding. I'm still new to the vps world.
Think of semi-managed as monitoring with some tech support I guess. They will make sure your core services are running (apache, php, mysql) so that your site doesn't go down, if it does they'll get it back up (Unmanaged, this is up to you)
You may want to give them a call they are very informative and just let them know your concerns and see what they say.
Restarting the server takes about 30seconds and is needed when you make changes to different configuration files. Such as mysql and such. You can allow overrides from php.ini or from .htaccess (that's where I do most of mine).
I would say just jump right in, and ask questions if you have any, you'll be surprised at it's ease once done.
Remember though that no matter the host as your site grows you will have to dig into cache management of some sorts. (Much easier on a vps)
Only thing I can say I slightly regret about the service, is it was so easy, I really don't know anything more about how to run a vps.
Still don't know linux, or php, or how they all work together... But I'm very happy it JUST WORKS.
Also feel free to e-mail me with further questions as to not clutter this thread any further.
I can help if you get stuck anywhere.
OP says OK
I'm the OP of this thread and I don't mind all the valuable learning at all.
Ask away, I'm going to get a $10 account and try Drupal over at eApps.
I guess I need to rebuild my Drupal 6.6 from Site5 on eApps. I'll let folks know how it goes.
I guess I can copy over my Drupal files - that's no problem.
The mySQL - any idea how to move that over? I can backup the mySQL with DumpTimer or SiteVault and then restore them somehow?
Also, the mySQL will probably have a different name and so will the Admin of the mySQL.
Thanks,
I've migrated 2 different
I've migrated 2 different ways now.
First clear your cache tables (reduce unecessary mysql bulk).
Use Backup And Migrate to make backup of current install
Install Fresh 6.6 on new server, upload appropriate modules (best to pull from your current modules directory, I'd say, they don't need to be activated).
Activate backup and migrate, go to import, choose your file and bam, there's your site. Shouldn't even need to change database settings in settings.php if I remember correctly.
The other way (how I go from wamp to online currently)
Using phpmyadmin export the database tables
Copy all files from site to site
Open phpmyadmin on new site, create database, import tables.
Might need to change access info in the settings.php I believe an error page pops up letting you know.
Not sure if either of those ways are the best methods, but they work for me.
One thing to note, is when I'm going from my online server to wamp, and sometimes vice versa I ran into time out issues most likely due the size. How I got around this was dump about 1/4 of the tables at a time, so I'd get 4 zips, then import one at a time. Works fine, and avoids any issues. Keep in mind I could probably fix this by raising my time out limits on either the vps or my wamp, but haven't bothered to do so.
Method 2 has worked for me
Method 2 has worked for me most of the times when I shifted things from localhost (xampp) to actual server OR from one shared host to another. This is not to say method 1 is not better, only that I have not tried it. Somehow I have not tried it so far.
@kryptik - how do you clean the cache - by running cron or just empty the table via phpmyadmin ?
I personally truncate the
I personally truncate the cache_tables, but I'm sure clearing with the devel module would do a good job. There's often a lot of bulk in there, and you don't need it serving up data cached from another server. (IMO)
devel ?
Clearing by clicking "Cleared Cached Data" in the Performance module?
there is a devel module
there is a devel module (development tools). Very useful, and has a clear cache button that clears all the caches I believe. May want to clear views cache if using it (Under views-> Tools).
It's not necessary as you can rebuild the cache after transfering but it does reduce bulk.
6.6 might have another bug...Front page not advancing...
I'm not sure if its just my site, but I just noticed that the page tags at the bottom of the front page when you click on page 2 at the bottom(or any other page number) it repeatedly stays at the front page, it doesn't advance to the next page. This is also the case under the forums listings, to click 'next' only reloads the first forum page.
At first I thought it was a theme issue, so I loaded a core drupal theme and the same thing happens.
Anyone seen this before?
Thanks.
****UPDATE!!
Monstrous apologies, folks... I found the cause and it is unrelated to Drupal 6.6