The forum's search function has been identified as potentially being a significant contributor to the uptime issues over the last 24 hours. Searches for common search terms with large result sets are causing serious issues with server load.
Search will be disabled for the next 24 hours while we monitor the situation.
In the meantime please use Google for your searches using the search format:
site:diyaudio.com beer
Search will be disabled for the next 24 hours while we monitor the situation.
In the meantime please use Google for your searches using the search format:
site:diyaudio.com beer
Last edited:
It does look like Search is the cause of the recent server disruptions.
This is a problem common to all large vBulletin forums, usually hitting them hard at the 2M post mark. We've done well to make it to 6.3M posts without running into serious problems.
Search will remain disabled for the time being, until we find a solution.
This is a problem common to all large vBulletin forums, usually hitting them hard at the 2M post mark. We've done well to make it to 6.3M posts without running into serious problems.
Search will remain disabled for the time being, until we find a solution.
Search has been restored. The root cause of search issues was identified and rectified.
Additionally, search has been disabled for non-logged in members, a maximum of 500 results will be returned and there is now a minimum of a 30 second wait between searches.
For those interested in the details, a single thread search for a common search term which returned a large number of results was locking up the whole forum for over 60 seconds, some post searches for up to 3 minutes. Less common searches with smaller result sets were also causing forum-wide lock ups in the 3, 5, 10 second range. This was due to a combination of poor SQL / logic in vBulletin and our core plugins, and the use of the vBulletin-3-default MyISAM database table for our thread data. MyISAM uses table-level locks rather than row-level locks. By switching to using InnoDB database tables for our thread table, the search function now happily operates without causing locks that prevent the rest of the forum from functioning.
Some more upgrades will be done later today to migrate our post table to InnoDB, this will require around 90 minutes of downtime. The result should be that the infrequent but annoying minute-long locks and double posts people have been experiencing after making a post during busy periods should be eliminated.
By eliminating locks we can run our web and database server much leaner and allocate more resources to speed and power rather than buffers in case of traffic jams, improving overall performance.
Apologies for the interruption of service.
Additionally, search has been disabled for non-logged in members, a maximum of 500 results will be returned and there is now a minimum of a 30 second wait between searches.
For those interested in the details, a single thread search for a common search term which returned a large number of results was locking up the whole forum for over 60 seconds, some post searches for up to 3 minutes. Less common searches with smaller result sets were also causing forum-wide lock ups in the 3, 5, 10 second range. This was due to a combination of poor SQL / logic in vBulletin and our core plugins, and the use of the vBulletin-3-default MyISAM database table for our thread data. MyISAM uses table-level locks rather than row-level locks. By switching to using InnoDB database tables for our thread table, the search function now happily operates without causing locks that prevent the rest of the forum from functioning.
Some more upgrades will be done later today to migrate our post table to InnoDB, this will require around 90 minutes of downtime. The result should be that the infrequent but annoying minute-long locks and double posts people have been experiencing after making a post during busy periods should be eliminated.
By eliminating locks we can run our web and database server much leaner and allocate more resources to speed and power rather than buffers in case of traffic jams, improving overall performance.
Apologies for the interruption of service.
Last edited:
- Status
- Not open for further replies.