Last modified: 2013-06-18 14:42:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 21427 - Allowing and using large and complex #ask queries can freeze database
Allowing and using large and complex #ask queries can freeze database
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
All All
: Low minor with 1 vote (vote)
: ---
Assigned To: Markus Krötzsch
Depends on:
  Show dependency treegraph
Reported: 2009-11-07 11:24 UTC by tkrueger73
Modified: 2013-06-18 14:42 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description tkrueger73 2009-11-07 11:24:11 UTC
If the parameter $smwgQMaxSize is set to a value of 16 or more, the whole MW-page is not reacting anymore.

Best regards,

Comment 1 tkrueger73 2009-11-07 13:02:03 UTC
For infomation:
I found that, if a query with $smwgQMaxSize higher than 15 is done, the process "msqld" is staying at 100% cpu load all the time.
Checking msqlyd with mtop, I found that for each query I had a threat in an endlessloop for more than one hour. It was impossible to kill this "crashed treads".
Only solution was stopping and restarting the mysql server.

I have no deep knowledge about SMW and mysql, but maybe my comments are helpfull for somebody with more experience.

Best regards,

Comment 2 Markus Krötzsch 2009-11-09 11:09:50 UTC
Please provide further details on the problem. Especially we need an example URL where the problem can be seen, or a detailed description of the environment where the problem occurs (version numbers of all involved software, details about the query and about the contents of the wiki [esp. the data on Special:SemanticStatistics], "format=debug" output of the query).

In general, the very purpose of $smwgQMaxSize is to prevent such queries. There will always be a size of query that is not doable for a DBMS any more. Performance can always be improved, but it is not a bug if there exist large and complex queries that are out of scope for your DBMS. Nothing scales indefinitely.
Comment 3 Markus Krötzsch 2010-05-27 11:56:25 UTC
I decrease the importance of this bug since no further details have been provided, and since SMW already includes a number of features that are specifically there to prevent this problem.

In general, SMW cannot prevent administrators from explicitly removing the normal restrictions on query complexity (or force them to suitably sharpen these restrictions for very large or busy wikis). I do not know what else SMW could do, since there will always be limits to what is possible with today's DB technology. Changing SMW to always use the most conservative restrictions to prevent hitting these limits (thus taking the control from the administrator, preventing mis-configurations) does not seem to be a good solution. Maybe some documentation could be added to increase awareness, but for this it would be useful to know at least in which environments the problem occurs now.
Comment 4 MWJames 2012-11-07 05:01:50 UTC
This bug hasn't seen any update during the last two years and it is unknown if this bug still relates the current SMW 1.8/SQLStore3 therefore it is set to won't fix.

Please feel free to reopen this bug again if it applies to SMW 1.8.
Comment 5 Markus Krötzsch 2012-11-07 06:57:44 UTC
Agreed to the WONTFIX. However, it is quite possible that this bug is partly addressed by the recent changes in SQLStore3. At least we have much better  and table that should help MySQL to find good query plans in many more cases than before. There will always be practical limits, but I hope we have pushed them a bit.

Note You need to log in before you can comment on or make changes to this bug.