Thursday, April 26, 2007

Why Cb is slow: SQL query trouble

Yesterday and today I am back at the CUBIC to meet up with my former colleagues, which gives me the opportunity to proper debugging of the Cb server instabilities. Earlier I turned on this useful: MySQL option:

log_slow_queries = /var/log/mysql/mysql-slow.log
which pointed out a serious problem:
# Time: 070427  8:30:04
# User@Host: pg[pg] @ []
# Query_time: 426 Lock_time: 0 Rows_sent: 50 Rows_examined: 4096407
SELECT t1.tag AS tag, COUNT(DISTINCT posts.blog_id) AS count FROM tags AS
t1, tags AS t2, posts WHERE t1.post_id = t2.post_id AND t1.tag != t2.tag
AND t2.tag='Visualization' AND posts.post_id = t1.post_id GROUP BY t1.tag
HAVING count >= 1 ORDER BY count DESC LIMIT 50;

The time consumed in this example, 426 seconds, is already stupidly long, but it can be even worse. Now the problem really seems to be in the number of rows examined which is slightly over 4 milion, while the tags table really only has about 35 thousand entries. The reason why it actually is slow, is that during this query it massively reads and write from the harddisk. That is, 20-30 MB a second for about the time it takes to do the query. It is obvious that that leads to server instabilities.

Next step is to understand what this query is supposed to do, and why the hell it is actually making so many entries. Euan, if you are tuned in, the blog_id and post_id columns only contains NULL, which might cause the row explosion?

Update: I tracked this query down to the functionality get_similar_tags and disabled that for now, until I get it fixed.

Monday, April 9, 2007

Broken Cb PipeLine...

Last week, someone reported me that his blog items were not showing up. He was right. There was an invalid XML file created at some point, which broke processing of the blog items using a Perl XML module. This is fixed now, and resulted in a big blog of new items today.

Tuesday, April 3, 2007

Database server instabilities...

The machine that is running the database behind the Chemical blogspace is having trouble keeping alive. This is happening since the (scheduled) power outage of this weekend. Now, since the CUBIC has shut down as organization, my postdoc contract has ended too. As a consequence, I will not have frequent access to the machine, and remote SSH access is having hickups too. So far, a (former) collegue (Miguel) is helping me out, by rebooting every now and then, but I will work on a more permanent solution.

The best solution would be to get some permanent hosting somewhere, but without a university position where the machine could run, that is not cheap. Not too expansive either, but for a hobby... In the short term, I am considering moving the database to frontend machine, which has somewhat higher load, but is more stable too.

To be continued...