Split: Brings Whole Site Down

Anonymous

#266265

Hey Ross,

Sorry I’ve been quiet for a few days! Have been letting the cache rebuild (just passed 90%) and wanted to see how the server stabilises.

Strangely, we havent had a crash since 11/11 17:10 (NYC time), which is after the rebuild was triggered, but in recollecting I may not have cleared the site cache too, which I guess may have recycled bad queries – in any case, I’m just going to monitor now before doing anything else.

I took backups of the cache and term results tables too before rebuilding the cache so their content might give us some direction if you’d still like to investigate – of course there’s a chance the crashing will come back, in which case I’ll be looking into the last ~1200 articles it indexes as its running fine right now without them!

Ross Moderator

#266281

Hi Kris

So I’m thinking the cache has now completed and everything looks stable?

The site cache could cause a few issues, so that might have helped.

Right now I’m just taking guesses in the dark haha. I guess we’ll see how this goes and if the probelem resurfaces we can resume? ( I will likely need access )

Thanks

Anonymous

#266285

Not quite finished unfortunately – shortly after my last post I decided to take a backup of the tables as they were (just incase it did fail on full cache so I’d have something to compare to) and I also ran a repair on a few tables that were showing errors from the last crash. Assuming something I did messed up the caching progress and I needed to restart so its about 60% done again (FYI – I moved it back to medium speed this morning and it has been consistent/OK).

Will keep you posted and will check the table differences too once complete, thank you for your assistance.

Ross Moderator

#266287

Ok great thanks.

I think that backup (as its about to fail) will provide most insight should we need it.

Yeah, repairing the tables during a cache in progress might cause issues / lockouts…

If you want to ensure you are doing a clean run, disable S&F, delete our two tables from your DB, then enable S&F – it will automatically recreate the tables.

Then you can run a cache again (your search forms won’t be lost, they are stored as post data / post meta).

Anyway, I’ll keep an eye on this to see what you come back with.

Best

Anonymous

#266440

OK so I might have both celebrated and assumed my fault too soon.
Caching struggled overnight despite building 80+% in 2hrs or so, it keeps crashing around the 90% mark (maybe 92-3%).

Any ideas as to what can crash it – bad data in the posts?

FYI I tried twice, then tried without background processing and it failed the same (although background paused a few times before failing).

Ross Moderator

#266518

Hi Kris

So my assumption is, either some bad data in a post that our plugin can’t handle (yet), or just the right combination of things (like a lot of data associated to a batch of posts), causing too much resources to be used.

You mentioned you had changed the caching speed back to “medium”? Canyou change that back to slow? (you can even let it go to 80% on fast, if that would work, then switch slow for that last part, after the cycle of posts it is caching, it will check the speed and adjust accordingly)

Next time it gets stuck, let me know, we have a hidden screen, that allows the caching process to be manually stopped / started – so we could potentially isolate a problematic post.

Thanks

Anonymous

#266522

It’s actually stuck (failed, not paused) right now somewhere above 90%. Unfortunately I’m about to turn in for the night and the primary load on the server is also overnight here/business hours in Europe.

I’ve deliberately left it as is while waiting for advice from you as it’s better to have a 90% cache operating than a <90% cache building, what is the next best thing I can do/check?

Ross Moderator

#266526

This reply has been marked as private.

Anonymous

#266530

This reply has been marked as private.

Anonymous

#266534

This reply has been marked as private.

[Author]

Posts