Steve St.Laurent
Staff Alumni
Great news! The servers are working better than they ever have since I took over the webmaster job with the latest change. More on that later
We have outgrown the search capabilites of vBulletin's search software and that is what has been causing the crashes over the latest several days. I wrote a number of scripts to log data building up to the crashes so that I could figure out what was happening because once it would crash I had no way of pulling information out as to what had happened. Night before last I was finally able to nail down what was causing the crashes and was able to replicate the problem. During peak traffic periods I could start up 10 search windows and run those searches and lock up the server. During less than peak periods I would need some help from the other moderators, tdr staff, and users on the website (thanks to all of those that helped me crash it!
). I thought I had the problem nailed down last night but once the traffic started picking up in the morning and I was able to get enough people on to load it up we were able to crash it again.
At 11am this morning I went to bed to get a little rest and got 4 hours of sleep and then went back at it. I found a hack that throws out vBulletin's search engine and uses mysql directly for doing searches. There were several webmasters of large sites such as ours that were using it with success. The vB search engine works great for smaller sites that are resource bound (memory & cpu) but once the database gets to a certain size (we have close to a million posts) it becomes inefficient. It still should not have locked up mysql but that is what it was doing - even though it wasn't using anywhere close to the resources that I was allocating it. By getting rid of their search engine and using mysql direct it's now able to utilize all of the resources I'm throwing at it - which is an entire dual cpu system with 2gb of ram, a raid 5+1 disk array with a 128mb caching controller!
I had the site down for about an hour and a half today while I implemented the change. I last booted mysql up 8 1/2 hours ago after modifying the search engine. I got it done before our peak traffic period so I was able to adequately test it. I tried as hard as I could to up the load with the help of others as well and we could budge it! The best I was ever able to get the slow query rate to was . 006% and more recently it was in the . 040% range with 34 slow queries average per hour (out of 160,000 or so) - and that's an average including the slower times of the day. Tonight in the last 8 1/2 hours the server has processed 1. 4 million queries with ZERO NADA ZIP slow queries!!!! We hit a peak rate of 220,000 queries per hour. The database server load at it's very highest hit . 45 with 2. 0 being fully loaded - or less than 25%!
The web page server hit a load of 1. 57 for one 5 minute period (the log file writes every 5 minutes and it writes a 1 minute, 5 minute, and 10 minute average at that time) - outside of that it never went over 1. 0 (or 50% load). The server loads have really surprised me because I thought the database was putting a bigger load on the system than the web pages were but have found that isn't the case. Based on our current traffic growth we will need to add another web server in the not too distant future (bringing us up to a total of 3 servers running the site) and am making plans for that now.
Now for the only bad news in this whole thing - when we moved to vB3 I was able to turn on 2 word searches for some limited terms (vp, ve, lp, bd, etc, etc). With this change I don't believe it will be possible to have 2 word searches. Once I know this is all stable and running good I will look into it further but I doubt that is going to change. I do apologize for any inconvenience that will cause but I simply don't have any other choice at this point - there were no other options.
I'm really looking forward to things getting back to normal around here and being able to sleep like a normal person again. I'm 99. 9% sure that we're over the hump on this stuff. I feel 1000% better than I did 12 hours ago.
-Steve St. Laurent
Webmaster
We have outgrown the search capabilites of vBulletin's search software and that is what has been causing the crashes over the latest several days. I wrote a number of scripts to log data building up to the crashes so that I could figure out what was happening because once it would crash I had no way of pulling information out as to what had happened. Night before last I was finally able to nail down what was causing the crashes and was able to replicate the problem. During peak traffic periods I could start up 10 search windows and run those searches and lock up the server. During less than peak periods I would need some help from the other moderators, tdr staff, and users on the website (thanks to all of those that helped me crash it!

At 11am this morning I went to bed to get a little rest and got 4 hours of sleep and then went back at it. I found a hack that throws out vBulletin's search engine and uses mysql directly for doing searches. There were several webmasters of large sites such as ours that were using it with success. The vB search engine works great for smaller sites that are resource bound (memory & cpu) but once the database gets to a certain size (we have close to a million posts) it becomes inefficient. It still should not have locked up mysql but that is what it was doing - even though it wasn't using anywhere close to the resources that I was allocating it. By getting rid of their search engine and using mysql direct it's now able to utilize all of the resources I'm throwing at it - which is an entire dual cpu system with 2gb of ram, a raid 5+1 disk array with a 128mb caching controller!
I had the site down for about an hour and a half today while I implemented the change. I last booted mysql up 8 1/2 hours ago after modifying the search engine. I got it done before our peak traffic period so I was able to adequately test it. I tried as hard as I could to up the load with the help of others as well and we could budge it! The best I was ever able to get the slow query rate to was . 006% and more recently it was in the . 040% range with 34 slow queries average per hour (out of 160,000 or so) - and that's an average including the slower times of the day. Tonight in the last 8 1/2 hours the server has processed 1. 4 million queries with ZERO NADA ZIP slow queries!!!! We hit a peak rate of 220,000 queries per hour. The database server load at it's very highest hit . 45 with 2. 0 being fully loaded - or less than 25%!
The web page server hit a load of 1. 57 for one 5 minute period (the log file writes every 5 minutes and it writes a 1 minute, 5 minute, and 10 minute average at that time) - outside of that it never went over 1. 0 (or 50% load). The server loads have really surprised me because I thought the database was putting a bigger load on the system than the web pages were but have found that isn't the case. Based on our current traffic growth we will need to add another web server in the not too distant future (bringing us up to a total of 3 servers running the site) and am making plans for that now.
Now for the only bad news in this whole thing - when we moved to vB3 I was able to turn on 2 word searches for some limited terms (vp, ve, lp, bd, etc, etc). With this change I don't believe it will be possible to have 2 word searches. Once I know this is all stable and running good I will look into it further but I doubt that is going to change. I do apologize for any inconvenience that will cause but I simply don't have any other choice at this point - there were no other options.
I'm really looking forward to things getting back to normal around here and being able to sleep like a normal person again. I'm 99. 9% sure that we're over the hump on this stuff. I feel 1000% better than I did 12 hours ago.
-Steve St. Laurent
Webmaster