MySQL AB today announced that Tellme Networks, Inc is benefiting from significantly reduced database-related costs by using the open source MySQL database. Tellme employs MySQL to power mission-critical enterprise and carrier applications on the world?s largest open platform for the phone.
9 years after X'97 I ended up at TUE again this time for T-Dose.org A whole different sight, last time there were a couple of hundreds geeks sitting around writing demos, compsing music etc this time almost 10 years later we just abused the auditoria and were sitting there quietly listening to people giving talks, one thing was sure.. this time I booked a hotel, no need to sleep under a table or try to sleep in my car on the parking lot :)
Altough I had no other plans this weekend I still was late for the keynote and most of the morning talks. The first talk I ran into was by "Martin WebHuis", he was talking about migrating away from Exchange to openXchange, somehow I didn't expect this kind of talk at this event, but then again I didn't expect a using Samba talk at last year's LinuxKongress in Hamburg. He mentionned openITIL which I should take a closer look at .. some day ..
What strikes me is that we in Belgium have the idea that …
[Read more]
With great pleasure I today noticed that we finally have daily
snapshot builds of all current versions of the MySQL server
source trees (4.0-5.1) available on http://snaps.mysql.com/ again. Unfortunately this
has not been the case for quite some time - a few issues that
caused the 5.0 and 5.1 snapshot builds/tests to fail have now
finally been resolved. I also made some changes to the build
script that performs the snapshot builds, e.g. to use the
Perl-based test suite where available instead of the Shell-based
one, which is going to phased out in 5.1 anyway. Let's hope that
from now on the snapshot builds will now be available more
frequently again, I'll keep a close eye on that.
Sorry for the long delay, I know that some of you depend on
receiving updated source tarball snapshots on a regular basis
instead of having to use the free BK client...
With great pleasure I today noticed that we finally have daily
snapshot builds of all current versions of the MySQL server
source trees (4.0-5.1) available on http://snaps.mysql.com/ again. Unfortunately this
has not been the case for quite some time - a few issues that
caused the 5.0 and 5.1 snapshot builds/tests to fail have now
finally been resolved. I also made some changes to the build
script that performs the snapshot builds, e.g. to use the
Perl-based test suite where available instead of the Shell-based
one, which is going to phased out in 5.1 anyway. Let's hope that
from now on the snapshot builds will now be available more
frequently again, I'll keep a close eye on that.
Sorry for the long delay, I know that some of you depend on
receiving updated source tarball snapshots on a regular basis
instead of having to use the free BK client...
Finally figured out what was causing the lack of performance on
the
partitions with the query. The use of FORCE INDEX was causing the
slowdown
with the partitioned table. Once I removed the clause, the query
ran in 1
minute 19 seconds, which is more in line with expectations. Sorry
for any
inconvenience!
Linux and Unixes have excellent metric of system load called "loadavg". In fact load average is is 3 numbers which correspond to "load average" calculated for one five and 15 minutes. It is computed as exponential moving average so most recent load have more weight in the value than old one.
What does Load Average corresponds to ? At least on Linux it is number of processes which are in "running" state or in "uninterruptable sleep" state which typically corresponds to disk IO. You can also map LoadAvg to VMSTAT output - it is something like moving average of sum of "r" and "b" columns from VMSTAT.
Obviously minimum value for LoadAvg is zero which corresponds to completely idle system, and there is no maximum
First thing to understand about LoadAvg it does not really tell you if it is CPU bound load or IO bound load. For example if you have LoadAvg of 10 it may mean there are 10 processes/threads actively consuming CPU or it …
[Read more]
In my previous post I started out by setting up MySQL 5.1.12 on a
box in order to test the performance of the new partitioning
option. During testing, I noted that I did not see any noticeable
performance improvements from using partitioning. So I spent some
time Saturday and Sunday (I guess I don't have anything else
better to do!) to build the testing environment and perform the
tests. So I was wrong, but only slightly. Partitioning does show
better performance than standard tables, but not by as much as
you would think. But, wait, there is light at the end of the
tunnel (as well as a WTF). The numbers...
| Table Type | Elapsed Time |
|---|---|
| Normal | 7 minutes, 41 seconds |
| Partitioned | 5 minutes, 51 seconds |
By partitioning, …
Been quite a while since I've posted on my blog... I've been really busy planning the 2007 MySQL Conference and Expo (yes, the planning starts way early). This past week, I've gone through hundreds of presentation proposals, some of which are fantastic. We will begin notifying external speakers — that is, non MySQLers — in the next day or two.
Edwin and the markeing team have put together a survey for the MySQL user community on a website called Zoomerang. One of the survey participants will win a free pass to the 2007 MySQL Conference (>$1,000 value!), so if you've got time, please consider filling out the survey and giving us your opinions and suggestions.
I was fighting four days now, with a threading problem, which are known to be hard to track. But I finally found it and learned that I actually had made a beginner’s mistake.
What happened?
From the front end I trigger via AJAX a view that again starts a
thread that does some import work, that might take quite a while.
This enables the user to keep going and have the import run
without interrupting him/her. Every once in a while an
asynchronous call checks on the state of the import.
And here lies the problem: while the thread is running and busy
like a bee adding data in the DB the asynchronous call to check
on the state also tries to run a query and that causes the
following exception:
...
File "/Users/cain/programming/django/trunk/django/db/backends/mysql/base.py",
line 42, in execute
return self.cursor.execute(sql, params)
File …[Read more]