After finding there’s a performance regression in sqlite I finally found some time to pinpoint what exactly regressed. While I’m not 100% certain that the query I used for this is exactly the one Quassel uses, it is very likely.
It turns out in newer versions of sqlite the query planner wasn’t using an index present in Quassel’s database for sorting but instead used manual sort. And this slowed it down noticeably. Since reporting this issue it’s been fixed and will be included in the next release versioned as 3.8.7. When it reaches Utopic I can unlock sqlite from upgrading on my machine :)
I recently upgraded from Kubuntu 13.10 to 14.04. It generally went smoothly. I only had an issue with Thunderbird crashing into bug 985986 and then Quassel starting up extremely slowly like 4-6 minutes until I can see and send messages.
I’ve been using Quassel for years and my database (sqlite) had grown to 750M. Since I was told on #quassel that sqlite doesn’t perform well with that big databases I assumed that was it. I made a copy of my database and deleted older messages (in backlog table) from one and newer ones from another. This way I have an archive if I want some information out of it but it isn’t available as scrollback all the time when I don’t need it. I then tried using Quassel again with a database less than 300M. It was still slow (around 30s) to startup.
Today I tried downgrading quassel from 0.10.0 to 0.9.1 that I used in 13.10. That did not help, Quassel remained slow. I then tried downgrading sqlite3 (libsqlite3-0 and sqlite3 packages) from 3.8.2 to 3.7.17. That sped up Quassel to normal few seconds it takes to fetch messages from ZNC. I then upgraded Quassel to 0.10 again and it remained fast. I also tried upgrading sqlite to Utopic packages with 3.8.5 but that was slow as well.
So it seems that for the queries Quassel executes on startup (of which I have no idea what they are) there’s been a regression in sqlite3 between versions 3.7.17 and 3.8.2. Using sqlite3 from Saucy works as a workaround.
My Kubuntu occasionally finds it hard to hibernate. First I thought that the swap partition was too small and this was reported in system log too sometimes. But this is not always the case. It was happening in Karmic and continues to happen in Lucid that I installed week ago. This is mostly annoying only though. I should really try to find out the real cause.
As it didn’t hibernate again last night I went for shutdown. All seemed fine. My first boot this morning was to Kubuntu, check email, hibernate, done. The second boot was into Windows 7 because TTCN-3 tool I need for class only works in Windows. Still all good, working, applying Windows updates, reboot, shutdown.
And then I booted to Kubuntu again. Whole networking system was down. Right-clicking network manager reveals “Networking disabled”. iwl3945 driver does some tricks at times, so I unload and reload that driver. Nothing. Iwconfig. No interface. Ifconfig. Nothing except lo. Ok, so I have a laptop that does no networking at all and I have no idea what’s wrong. Sure, this is a beta, but first reboot after last updates worked fine.
This time booting with live version on USB. Short search on Google suggests that /var/lib/NetworkManager/NetworkManager.state might have NetworkingEnabled set to false. To my surprse this is exactly the case. Set to true, restart network manager and it’s all working again.
What I don’t understand is how the heck did it get set to false first place?
Oh, and does anybody know where screwdrivers like to hide? I had one around and can’t find it any more. If you’re Kadri then no, it’s not the one I borrowed from you, it’s the other one.