A

In the first article on IP to location I described the overall concept. In this edition we'll look at the implementation and how to scale the tracing to a reasonable speed.

With the examples from the last article you can also implement everything to build your own database. Before you jump into it take a minute to look at the implications.

Taking the example from the previous article 217.80.0.0/12 for the German Telekom we have to trace 1mio addresses and scanning them all will take a while:

# time traceroute -w 1 -m 8 -q 1 217.80.0.1
traceroute to 217.80.0.1 (217.80.0.1), 8 hops max, 40 byte packets
 2  217.0.72.230  36.974 ms   
 3  ke-eb1.ke.de.net.dtag.de (62.154.98.82)  54.454 ms
 4  217.0.74.213  54.610 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *

real    0m3.244s

If we can make the make …

Guess what ? I also will be speaking at MySQL Users Conference 2008, which is always excited.
According to session schedule I'll have one talk about Innodb Scalability Limits and another one together with Andrew Aksenoff about Sphinx.

Looking back at Proposals (+1) I'm surprised only one talk was chosen and also this particular one.

May be I should put more effort into detailing advance session description - I normally tend to provide good choice of topics to conference organizers without too many details, working these out only when we know which sessions are of potential interest. Well perhaps with …

News Summary - Jan 27th to Feb 3rd, 2008

A

Ran DBT2 with the following:

[root@localhost scripts]# ./run_workload.sh  -s100 -c 16 -w 20 -t 32 -d 1200 -n

Here are the results ( This beats a lot of other benchmarks I have seen with 8 core machines & regular disk ). This is an innodb test, with the ibdata file on 1 mtron drive and the log files on another. The test does not really show the mtrons ability  though., simply because the dataset is only 20 warehouses they all fit into memory. So far I have seen 18K TPM on a 300 warehouse run which stresses the disk more. Anyways here are the results:

Response Time (s)
Transaction      %    Average :    90th %        Total        Rollbacks      %
------------  -----  ---------------------  -----------  ---------------  -----
Delivery   3.81      0.656 :     0.741        50043                0   0.00
New Order  42.61      0.607 :     0.681       559699             5569   0.99
Order Status   3.79      0.592 :     0.665        49792 …

This week I have been doing a great deal of testing with SSD to determine the feasibility of using SSD in a MySQL production system. I will be working on a complete write up, but I thought I would tantalize you with some findings.

The system running the tests is built from NewEgg.com with the Drives supplied by Easy Computing Company. I am using a Q6600 Quad Core (2.4Ghz) with 6 GB of Ram, and 2 72GB 10K Rpm Raptor drives. These tests are done with 1 32GB mtron device. I tested with the onboard SATA controller and a generic super micro 8 port controller. I will be testing Easy’s Managed Flash Technology soon. The results shown here are not using Easy Computing’s MFT technology.

Random Read Test:

sysbench v0.4.8:  multi-threaded system evaluation benchmark

128 files, …

Hi!

You can now find the specifications, flow charts and implementation details for all (except one) parts of Maria at:

http://forge.mysql.com/worklog/search.php?k=Maria&t=tds

This makes Maria the best documented project in the history of MySQL AB. Yes, I know that this doesn't say much, but I think we have done a really decent job in this case.

The public worklog doesn't yet display the dependences between tasks, like our internal worklog does, which makes it a bit hard to navigate between tasks and to understand in which order tasks will be done. I hope this will be fixed soon.

So, you may ask, what is the one task that we have not published.? This is a new very cool way to index data to make some searches extremely fast. The reason for not releasing it is just that …

Well I am trying to use dbt2 to test some ssd drives.  This is my first time trying to use the tool, and I am not impressed.  Their seems to be a general lack of documentation out there, on top of the scripts being very buggy. I am trying 0.37 & 0.40.
The first thing is the scripts are somewhat of mess.  Things like setting user/socket  settings are not intuitive and in .37 required me to hack the run_workload script.  The run_workload script calls scripts that do not exist anymore.  Which is really annoying.

The lack of documentation hurts because all the references I have seen show a 20 warehouse run with x number of terminals/threads.  At the levels I have seen I get crap results like 500TPM, but when I look at the system my system is not even breaking a sweet.  I upped the # of warehouses to 50, and the threads to like 700 and I end up getting near 18K TPM.  And this puts my CPU @ 45% …