Bug Suddenly unable to fetch cache

[Webbstre]

I recently upgrades my site from 4.0.7 to 4.0.8 (I know, I'm a bit behind, but testing everything first takes time). Almost with a few other minor modification updates, I installed vbSEO. Afterward I found my server usage was a bit high, with a fair amount of server spikes. I contacted vbSEO to see about it, but they said there were no known server spike bugs in the latest version. The person there suggested that I check my cache settings (they were fine) and try disabling vbOptimise and vbSupercharged to see if that helped.

I left those two off for a few days, and it appeared that things settled down, with only one minor (150% CPU Usage) spike in several days. Today I went to turn vbOptimise back on. I had it set to disabled before, rather than uninstalling it completely. After Enabling it again I ran the System Test a few times, but each time I get this message: "Your Opcache Operator extension is functioning, however it is unable to store data. Please check your extension configuration."

I'm hoping someone can help me figure out why this is happening all of a sudden? I begin to suspect that perhaps vbseo isn't playing nicely, and it conflicting with vbo was the reason for the spikes.

Thanks as always!

 

[Fillip H.]

Hmm... Is the caching enabled in vBSEO? If so, please try turning that off. If that doesn't help, please try temporarily disabling vBSEO.

If neither of these things helped, then tell me what Opcache you are using (XCache, Memcached, APC, Filecache) and I'll find you a test script entirely separate from vBulletin / vBO / vBSEO that will let you know if this is a server config issue or a mod issue

 

[Webbstre]

I got it to not fail the test a single time, but every other time it has given me the big red X. I think I may need your test script to find the source of the problem.

 

[Webbstre]

Oh boy, I think I figured it out: vbseo's htaccess file did not have the custom lines in it to make sure it was loading my custom php.ini file instead of the server default. Thus, none of the caching is working correctly. I've contacted vbseo and hopefully someone will know what to do.

 

[Fillip H.]

Alright, I'll keep this open until you hear back from them

 

[Webbstre]

To Copy Paste what I said in the vbseo forum:

Ok, I talked to a guy at my server hosting and this is what he did. The lines went at the top of the .htaccess file, and then he changed this:

RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron|vbseo_sitemap)
RewriteRule ^((archive/)?(.*\.php(/.*)?))$ vbseo.php [L,QSA]

to:

RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron|vbseo_sitemap|cgi-bin)
RewriteRule ^((archive/)?(.*\.php(/.*)?))$ vbseo.php [L,QSA]

The caching all appears to be working now, which appears to be the main problem from the start. With caching on vbseo and vboptimize the site load appears to be a few second shorter, which is good. Anyways, if anyone else runs into similar problems this post might help them.

So yeah, custom php.ini scripts called from the htaccess file that are necessary for your server to cache... if that doesn't load then it turns out you may need to edit the vbseo provided .htaccess file to make all caching work correctly.

 

[Fillip H.]

Thanks for the detailed explanation

 

[Webbstre]

So on the plus side, you were right about the load going back down after the initial load.

...on the non-plus side, I still get crazy CPU spikes at least once a day, sometimes over 100%, sometimes much higher, and I can't figure out what it causing it. What I wouldn't give for a tool that could track down this kind of thing. Any suggestions? I have vbO and Supercharged on and xcache is working and everything is using different xcache prefixes.

 

[Fillip H.]

Sorry, I can't say I know of any diagnostic tool for CPU spikes. If you can run your site with only vBO enabled for 36 hours (and nothing else running on the server) we'd be able to ascertain whether it was vBO causing it.

We can't think of anything off the top of our heads that would cause this that's exclusively related to vBO; if the opcode cacher was having some form of problem and either dumping its cache and rebuilding it, or something, then that might be a cause. However, that wouldn't be directly related to vBO.

Also, do the spikes happen at the same time each day, or on random times of the day?

 

[Webbstre]

Unfortunately, disabling everything else is kind of not an option. These problems only appear on the live site, which is why we never catch them during testing. I honestly don't think it is vbo causing the spikes either, since they were happening before when the cache wasn't working at all. The frequency, level and timing of the spikes all appear random, and my access/error logs don't really display anything too revealing.

What a headache X_X

Oh, if you want to see my live performance graphs, feel free to look here: http://dev2.runicgamesfansite.com/mrtg/

 

[Fillip H.]

I'm out of opshuns then I'm afraid

 

[Cosmic]

Unfortunately, disabling everything else is kind of not an option. These problems only appear on the live site, which is why we never catch them during testing. I honestly don't think it is vbo causing the spikes either, since they were happening before when the cache wasn't working at all. The frequency, level and timing of the spikes all appear random, and my access/error logs don't really display anything too revealing.

What a headache X_X

Oh, if you want to see my live performance graphs, feel free to look here: http://dev2.runicgamesfansite.com/mrtg/

Interesting timing from the graph i am looking at now there does *appear* to be a slight pattern -6am, 5pm and 8pm have spikes both days which to be honest are odd times. The 5pm one makes sense - thats usually when sites with a younger demographic have the most traffic, but the 6am and 8pm ones are just odd.

Is your site on shared/vps/dedicated hosting?

Also some hosts snapshot processes when load goes above a certain figure and tend to be quite good at finding the culprit - have you asked anyone at the hosting co to give that a try (The exact method they use is something i'm unfamiliar with unfortunately )

Cosmic

 

[craiglathrop218]

Check to see if your spikes correspond with any of VBulletin's scheduled tasks. I had a spike happening once an hour because of a scheduled task. I had to up my max connections and max packets in mysql. It still spikes with the task, but not to 100%.