performance issues with external mysql database

[Matěj Laitl]

On 5. 6. 2012 Alan Ezust wrote:
> Hi Matěj,
> 
> Here are the rowcounts for the tables, bad and good
> 
> 		amarok2	amarok3
> 		(bad)	               (good)
> albums		2485	2629
> artists		2301	2335
> composers	199	199
> devices		12	0
> genres		194	195
> labels		0	0
> tracks		18702	18661
> urls		18699	18661
> statistics	38446	18661
> 
> I thought the culprit was the "statistics" table.
> There are quite a lot of entries in it that have a "deleted" = 1.
> So I did a "delete from statistics where deleted=1" to see if that got
> rid of the delays.
> It did not.

Hmm, nothing major wrong here.

> Then I followed the instructions above and ran mysql with logging of
> long transactions.
> I started up Amarok with the bad DB and let it play to the end of the
> first track.
> It had a long delay to figure out what to play next, and then repeated
> the same track.
> 
> Here is my mysql log.

Hmm, nothing interesting here, the slowest query is 0.2s if I understand it 
correctly, to 20-30 s delays. You say the Amarok event loop stops for that 
extended periods of time. Could you please:

1. Install debugging symbols for Amarok, kdelibs, qt, glibc, glib
2. Run Amarok grom gdb: `gdb --ex run --args amarok --debug --nofork`
3. Trigger the temporary freeze
4. Hit Ctrl+C in gdb,
    `(gdb) thread apply all bt 30` <- save entire backtrace
    `(gdb) cont` <- resumes normal Amarok operation

Please repeat Ctrl+C -> backtrace -> cont cycle several times and look if the 
backtrace of Thread 1 looks similar each time. If so, please file a bug about 
it, copy the full backtrace and CC me on the bug.

Thanks,
		Matěj