View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004345 | mantisbt | performance | public | 2004-08-18 06:50 | 2008-08-12 09:35 |
| Reporter | Assigned To | grangeway | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Any | OS | Any | OS Version | Any |
| Product Version | git trunk | ||||
| Summary | 0004345: Full-text search is extremely slow and produce long slowdown the whole system | ||||
| Description | If something (even one word) searched in mantis base (0002953:0004000 issues total, 0000527:0000800 open) it require approx 30-40 seconds per request. Side effect is expensive CPU usage of mysqld process (99%) during approx 10-15 mins | ||||
| Steps To Reproduce | Well, I'm not sure but - collect base of comparable size, start top on consose and use search | ||||
| Additional Information | After moving from 2-processors host with FreeBSD 4.8 to 4-processors host with FreeBSD 4.10 (1G RAM and SCSI in both cases) "post-effect" is less visible, but still present. | ||||
| Tags | No tags attached. | ||||
|
What version of mysql are you using? We started to notice a slow down with about 2000 total issues and version 3.23.46 of mysql. edited on: 08-18-04 07:33 |
|
|
We have the same pb. We use version 4.0.16 of mySQL. Now we cannot even get an answer. MySQL takes 100% of one (of 2) processor, and at the end, the returned page is absolutly empty (no html at all). It may come from Apache or from the browser, we don't know yet. I know this is not a "good" description of the problem, but my 2 cents... edited on: 08-25-04 09:36 |
|
|
4.0.18, 4.0.20 (nothing changed in good direction with 4.1). |
|
|
Try adding this to your config_inc.php $g_show_queries_list = ON; Note: you may want to do this on a replica of the database and pages, since it could give information that other users probably shouldn't see. There is also a patch that gives a slightly more sophisticated way of tracking which query is dogging down your system... see http://bugs.mantisbt.org/bug_view_page.php?bug_id=0004348 I'm not sure if it is in the CVS head yet, but you can drop the patch in yourself if it is not. |
|
|
Alex, are you able to apply the patch i added to 0004348 and attach a copy of your query list here ? |
|
|
I've added a related issue to 0002921 which may be quite similar to this. A query list with the timings for the Query should show whether this is the case |
|
|
I hate idea apply patch to production installation, but will do do it on demo-site (with tiny base). Will it be useful for anybody? |
|
|
You could also try to call the SQL function OPTIMIZE TABLE to optimize the database tables. |
|
|
Thank you for taking the time to report a problem with mantis. A number of optimisations have been applied to the filter code in 1.0, 1.1 and even the upcoming 1.2. Could you let us know with a new bug report if there are issues unaddressed by these changes. Since this problem report was originally made, a number of releases have occurred. Unfortunately you are not using the latest version and the problem might already be fixed. Please download the latest release from http://www.mantisbt.org/download.php [^] If you are able to reproduce this bug in the current release, or have some more information on how this feature could be improved in the current release. Please either change the mantis version on this bug report Again, thank you for your continued support and report. |
|