Slowdown even after disabling/uninstalling Trace?
jccc - October 6, 2009 - 17:52
| Project: | Trace |
| Version: | 6.x-1.0 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Arto |
| Status: | active |
Jump to:
Description
We've done this at least three times: We have a fresh, decently performing Drupal, enable Trace, use it (major, major slowdown), disable it, still see the same slowness.
Even after uninstalling, the performance drain remains. It is around 5 times slower, more than just noticeable, practically unusable. The only solution afterward is to create a fresh Drupal and start copying over our important tables.
What could be causing this? I can't think of any explanation other than that something here is altering the database in a way I can't seem to undo. I'd like to be helpful in tracking down specifics of our situation, but I don't know where to begin.
#1
The only database change this module makes on installation is setting its own module weight from 0 to -99, in order to ensure Trace is run before other modules. This is unlikely to be related to the problem you are describing.
There are no database changes that would persist beyond uninstallation. Performance issues with Drupal are usually related to caching, so the first thing I would suggest is trying to rebuild Drupal's caches using the "Clear cached data" button on the Administer >> Site configuration >> Performance screen (admin/settings/performance), to see whether that helps.
Another possibility is that you were using Drupal's aggressive caching mode, which is incompatible with a lot of modules including Trace. Drupal could thus possibly have automatically turned off aggressive caching when installing Trace. You can check the status of this setting from the same aforementioned performance settings screen.
#2
Clearing cached data under ~/admin/settings/performance (and/or flushing via ~/admin_menu/flush-cache) hasn't affected it.
Because of the nature of our application we don't have caching enabled, and no settings of ours there have changed from before using Trace.
There may be something peculiar about our custom installation and an interaction of some kind between it and Trace, although I can't imagine what it would be. After using, disabling, and uninstalling Trace on multiple separate occasions, one of our queries for example that had been running at maybe 5-6 seconds subsequently throws mysqld up to 100% CPU continuously for nearly 60 seconds.
If it helps, we're hosted at Rackspace, and this is the mysql version:
$ mysql --version
mysql Ver 14.7 Distrib 4.1.22, for redhat-linux-gnu (x86_64) using readline 4.3
Noted for posterity I suppose, in case someone else encounters this and can figure it out.