Load Spikes Causing Server Downtimes - Is It An XF Addon?

TheBigK

Well-known member
We've experienced about 4 short-time downtimes (mostly http going down) in the span of about 2-3 weeks. If my memory serves me right, the problem started occurring ever since we enabled the Widget Framework Add-On. But I'm not putting the blame on that add-on right away; because I'm yet to figure out what's causing the load to shoot up.

I discussed the issue with my hosting provider and the response I got from them is as follows -


I have adjusted the courier processes downward from 50 for max daemons (quite
high for a server no mass mailing) to 5 for now. As for the mysql processes,
it appears that the user is making mysql queries that are often hanging
in a waiting for INSERT status. This isn't actually something I can correct,
as it is a result of the queries themselves, and unfortunately we are not
actual database admins. You may wish to have your query structure reviewed in
relation to the site's database [name].

If you are familiar with ssh protocol, you can use the following command to
watch your mysql queries in near real-time (generally quick queries happen so
fast you wouldn't be able to see them well and this updates every half
second).

If not, you can use the Show MySql Processes option in WHM to get a snapshot
of those existing at that moment in time. This may help structure the queries
more efficiently to reduce server load.

Can someone help me how do go about identifying the error and fix it?
 
I don't recommend the use of widget in all pages it can consume a lot of queries. Especially thread_view!
 
I don't recommend the use of widget in all pages it can consume a lot of queries. Especially thread_view!
Oh well, thread_view is important for us. The add-on description says it just adds one query. I"m not sure if it's a big deal.
 
considering how many people are visting the thread_view page, its a big deal!
The thread view has at least 600 visitors at any point of time. Maybe more than that. Can someone explain whether we're talking about 'database' queries? Is there a way to get around this? Why are queries a big deal?
 
It sounds like your host is talking about delayed inserts which are not actually a problem, but "delayed" sounds bad so people assume.

Yes, an excess of queries can cause load problems. If your widgets are query-heavy then that may be the cause. I don't have much experience with the widget framework, though I do recall some people talking about overuse of some widgets causing load problems. If you enable debug mode then you can monitor the number of queries per page.
 
Thanks a lot, Jake. So 'delayed' isn't a problem and I shouldn't worry about it - it seems.

The question on my mind is: if the widget caused problems then the load should be 'high' all the times. In turns out that the system load is just fine but shoots up at times. Is that how it is?
 
The thread view has at least 600 visitors at any point of time. Maybe more than that. Can someone explain whether we're talking about 'database' queries? Is there a way to get around this? Why are queries a big deal?
it means each query send a code to the database to get a piece of information. I used widget in threads a long time ago it was a bad experience for me!
 
Thanks a lot, Jake. So 'delayed' isn't a problem and I shouldn't worry about it - it seems.

The question on my mind is: if the widget caused problems then the load should be 'high' all the times. In turns out that the system load is just fine but shoots up at times. Is that how it is?

Yeah I would expect a more sustained load, not a sudden spike. There must be some event that is triggering the spike. Perhaps a surge in traffic, or maybe a cron on the server.
 
Hi there,

The reason for spike is that [bd] Widget Framework serves cached version most of the time so it only queries database when the cache expires. If you happen to have multiple hit when the cache expires (and not yet rebuilt, updated), it will queries database again to rebuild the cache. A few people contacted me about this problem. It only happens with large board with lots of traffic. The remaining question is which renderer do you use in thread_view?
 
I use - Users Online, Staff Online, Threads, Birthday. Ours is not a 'large' board, but we do have lot of traffic - 600 - 900 users online at any point of time.
 
Yep. Also, I configured the widget system for each pages separately instead of using 'all'. Am I doing anything wrong?
Nothing's wrong but that's a lot of widgets for thread_view. Anyway, most of them should not a problem except Threads because the rest is light on database queries. There are a few options, but for now you can apply a file edit to make the threads render use the live cache instead of database cache. Live cache will hit the cache directly without going through database. I assume your site has memcached or similar, right?

File: xenforo/library/WidgetFramework/WidgetRenderer/Threads.php
Line: 15

PHP:
'useCache' => true,

Change it to

PHP:
'useCache' => true,
'useLiveCache' => true,

It's also good to check the box "Use guest permissions (instead of current user permissions)" for the widget.
 
Update: I've made the changes as suggested.



What does this do?
It will use the guest permission instead of the current visitor permission when queries for threads. So basically, only public threads will be shown. This will also reduce the number of caches + improve performance.
 
It will use the guest permission instead of the current visitor permission when queries for threads. So basically, only public threads will be shown. This will also reduce the number of caches + improve performance.
Is there any way of making the latest threads show only to logged in members? For the guests, it's totally useless.
 
I've a question: Why not make the latest threads (board-wide) display as RSS feed. That will make it lighter on the server, saving precious queries. :confused:
 
Back
Top Bottom