Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By catch on
We run a site with c.20-60 users on at any one time, usually about 15 will be authenticated users posting in the forums.
With page caching switched on, the cache table generates a lot of overhead, then crashes.
This can be fixed by either:
1. restarting mysql
2. restarting the server
3. uninstalling and reinstalling mysql due to unresolvable (for me at least) .sock errors.
Obviously this isn't ideal, and I'd like to work out a way to fix it properly. I've turned page caching off, but oddly my cache table after truncation is still growing to about 20mb in a 240mb or so database very quickly, and still generates overhead. I run repair on it every so often (also get quite a bit of overhead on sessions and watchdog as well), but at the moment am doing it manually since I'd rather not set up a cron to do it (have to learn how first anyway!) if I can fix it properly instead.
Using apache2/php5/mysql5 - vps hosting, 256mb ram, Drupal 4.7.3
Been reading through the following threads and the linked mailing list discussion and wondering if this is related: http://drupal.org/node/43336
The questions I want to ask are these:
1. Is this a bug or an issue with myisam tables?
2. Is there something in my my.cnf I ought to be tweaking?
I've seen posts elsewhere about duplicate key errors, we've had those as well but I don't think that's the issue here since I understand those are only generated by page caching?
One other issue - my cron runs have stopped completing, and search indexing stays at 0%. Not sure if/how cron.php affects caching.
I'm very new to server administration and mysql optimisation etc., but very willing to learn as well. Any help would be much appreciated.
Comments
There are no known bugs wrt
There are no known bugs wrt cache table and myisam mysql engine.
No idea about any my.cnf tweaks that are specific to your problem.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
can you look in the cache
can you look in the cache tables and see what the cache IDs are? Some things (such as sessions and menus) are cached even when the page cache is off.
I've seen other posts where people had the session cache growing out of control beacuse (I think) of incorrect PHP settings.
---
Work: BioRAFT
404 errors?
Hi,
Thanks for getting back on this, sorry it took me a while to respond.
I have nearly 17000 CIDs that look like this:
filter:1:7a03b40401a8158f6c0a9e3910a688a2
I checked php.ini - was using php.ini.recommended - changed the settings recommended in handbook just in case.
session.save_handler: user
session.cache_limiter: none
however I understand they're set by default in .htaccess so can't imagine that'd be the problem. I restarted apache then truncated the table and I'm building up a dozen entries or more like that every refresh in phpmyadmin.
I just found this though:
http://drupal.org/node/72290
And apparently that's normal to have so many filter entries.
One other issue could be 404 errors:
http://drupal.org/node/73604
http://drupal.org/node/74347
debtman's issues on this thread sound very much like ours, except we're not getting /node/event/node/event urls creating the 404s (using 4.7.3 and his seems to be a 4.6 issue).
We're in the middle of converting our entire website to drupal - which was 2,500 existing drupal nodes, 110,000 phpbb posts, a few hundred wordpress pages, 2,000 geeklog pages and maybe 1,500 static pages plus other odd bits. There's a decent number of external links, a load of broken internal links on our archive of the old site, and all those pages are indexed fairly well in google. So everything except for the drupal nodes is generating many thousand 404 errors per day.
Our traffic over the past few months has been 1.6million pages/month - although hacking (leading to our move to drupal) and now server downtime (due to these cache table crashes if I'm away from the pc, none of us are sysadmins, none do this full time) has dropped it a bit.
I assumed it was our incompetence at managing a VPS (only been doing it for a month).
Catch, Have you found a
Catch,
Have you found a solution to this problem? It seems to be caching is problematic for relatively higher traffic sites:
High resource despite caching:
http://drupal.org/node/93305
Possible implementation of memcache:
http://drupal.org/node/93314
My post - cache on/off issue
http://drupal.org/node/93312
**Tom-E posting problem of freezing when adding/editing nodes
http://drupal.org/node/81012
Look forward to hearing from you.
Best,
Ivan
Hi, no we've still not found
Hi, no we've still not found a solution. The server will run fine for upto two weeks, but then can crash upto 6-7 times per day. Server load averages will shoot up to between 25-40 very quickly and it swaps out. Restarting mysql and apache usually clears it. I'll look at the posts you linked to and put some more detailed information in a bit later on.
Catch, Thanks for following
Catch,
Thanks for following up. I look forward to any detailed information you can share. I will do the same if anything pops up.
Best,
Ivan
One thing which helps a bit
One thing which helps a bit to reduce queries is the blockcache module, very flexible:
http://drupal.org/project/blockcache
Also making sure you have a query_cache in mysql and "max requests per child" in Apache. It's hard to tell which of these is making any difference (if any) though since I'm no sysadmin.
Agressive Caching
On Drupal 5.x using aggressive caching, and switching off some modules (statistics.module comes to mind) may help a little. However, with a rise in traffic, we're also now experiencing this on one of our servers.
Having looked most alternatives, I'm going through them now one by one while monitoring the memory loan on the server. For a dedicated server, 1gig ram, dual cpu, the memory is always floating at 85% (average).
Although I've already read the majority of threads related to this problem, it'll be very useful to read more opinions by Drupal users who are facing similar problems with their high performance sites.
---
Dee
iScene Interactive :: iScene.eu
For what it's worth ours has
For what it's worth ours has stabilised quite a lot.
Here's a few things we did:
Moved to a quarter VPS/1gig ram.
Moved .htaccess rules into apache virtual host and set AllowOverride None (this apparently saves some cpu cycles on every request)
CSS aggregation
Aggressive caching
Blockcache module
We installed an opcode cache (apc) but I had to get rid of it again due to dozens of segmentation faults.
switched off statistics module a while ago, that's an important one I think, and afaik you don't get accurate stats with aggressive caching anyway.
Also lots of small tweaks to php.ini and my.cnf - playing with query cache, key buffer stuff like that. All trial and error though and I wish I could say what it was that worked.
Extra RAM
Following on from our post above, we've stabilised the issue for now. Had to throw 3 extra gigs of ram at the problem to bring the overall memory usage down to ~25% (from ~85% average). We also installed phpAccelerator and it's doing an incredible job at the moment - highly recommend it!
Other tweaks were carried out to query_cache, php.ini and apache's configs. Aggressive cache is still enabled with a lifetime of 10 mins. Block_cache was used and it was very effective but it conflicts with the way we're using blocks on the site so it had to be ditched.
Things that we are still looking into are upgrading to Apache 2.x (currently we're on Apache 1.3x) to make use of mod_cache. Also the use of memcache and/or moving the database to a separate server has not been ruled out.
---
Dee
iScene Interactive :: iScene.eu