Recently, I had to futz with an Ubuntu server that was to run mail, web, and database services.

You slowly learn that Ubuntu as a desktop is easy to use, but as a server, its “different”, if you come from a Red Hat based background (especially if you’ve been using Red Hat-based distributions for the last thirteen years or so).

From example, while service httpd start works (well, the equivalent is service apache start), enabling things on boot using chkconfig (I wrote about it a while back) is replaced with update-rc.d.

In fact, if you’re an rpm aficionado, dpkg is a little different. I applaud the Ubuntu folk for creating an article such as …

A customer has recently experienced a possible memory leak in its NDB-API application. What he did was something like:

# ps aux | grep <pid>

over time and then he saw the RSS increasing. When he would have had a look a little longer he would have seen that the RSS consumption would increase up to a certain level and then becomes stable. Which is the expected behavior.

But how to explain to the customer that his application, which was in fact not doing anything, consumes more RSS?
With a diff over time on /proc/<pid>/smaps we found that this area was the reason:

b67b7000-b6fca000 rw-p b67b7000 00:00 0 (8 Mbyte)
Size:               8268 kB
Rss:                 148 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       148 kB
Referenced:          148 kB

But what is this meaning? To find the answer we did a strace on the program and got the …

A customer has recently experienced a possible memory leak in its NDB-API application. What he did was something like

# ps aux | grep <pid>

over time and then he saw the RSS increasing. When he would have had a look a little longer he would have seen that the RSS consumption would increase up to a certain level and then becomes stable. Which is the expected behaviour.


But how to explain to the customer that his application, which was in fact not doing anything, consumes more RSS?
With a diff over time on /proc/<pid>/smaps we found that this area was the reason:

b67b7000-b6fca000 rw-p b67b7000 00:00 0 (8 Mbyte)
Size:               8268 kB
Rss:                 148 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB …

The problem of MySQL Replication unable to catch up is quite common in MySQL world and in fact I already wrote about it. There are many aspects of managing mysql replication lag such as using proper hardware and configuring it properly. In this post I will just look at couple of query design mistakes which result in low hanging fruit troubleshooting MySQL Replication Lag

First fact you absolutely need to remember is MySQL Replication is single threaded, which means if you have any long running write query it clogs replication stream and small and fast updates which go after it in MySQL binary log can't proceed. It is either more than than just about queries - if you're using explicit transactions all updates from the transactions are buffered together and when dumped to binary log as one big chunk which can't be interleaved …

Drizzle TalkView SlideShare presentation


Drizzle talk for MySQL Developer's Meeting.


SlideShare Link

MySQL Lists are available via NNTP, so you can use your newsreader! If only all lists were like this.

Now for the real motivations…

After all acquisitions, things tend to change. We’ve been mostly nudged to migrate to using Sun’s email systems, and you can imagine its fun moving about three years worth of mail from one server to another. Especially, while you’re at the developer’s meeting, with lots of people sucking bandwidth.

The recommended method is to Ctrl+drag (OK, Command+Drag for me on the Mac) folders. This is called pain. My Sieve filters are also not importing without pain.

As a consequence, I’ve unsubscribed from all MySQL Lists. But that’s the point of this post - you can read all MySQL Lists using NNTP (with a newsreader of course - Thunderbird is …

After joining SUN I have seen and heard more and more people/customers that are wanting or planning to deploy MySQL Cluster on SUN's CMT technology.

For a bit more information on CMT, please read what Allan Packer, SUN, has written more on CMT hardware on his blog.

Looking at MySQL Cluster, and in particular the data nodes, they like:

1. Fast CPUs (two cores per data node), 2+GHz CPU.
   
2. RAM, as fast as possible.
   
3. Fast disks (SSD would be great fun to try in combo with Cluster). Fast disks are important especially for write-heavy applications.
   

CMT does not offer 1). CMT technology is currently quite slow (slightly above the 1GHz line). So running data nodes on CMT is not a good idea, which is also indicated by customer benchmarks. But what the data nodes are …

Dear Kaj, Giuseppe, Jay, Lenz, Colin,
MySQL™ Community Team,

This is my Report for the MySQL™ 5.1 Use Case Competition.

Before start reporting on my use of the new 5.1 Features, just a note.

I was quite sure on early August 2008 that including similar posts in my Report would be allowed. But during an email conversation, Giuseppe told me that similar Reports won’t qualify for the competition because the …

Peter Mularien takes a look at the developers for Spring and comes up with an unsurprising conclusion: "the vast majority of development on Spring Core is performed by SpringSource employees."

Though Peter suggests he's not trying to make a judgment on this fact, he implies that this somehow impugns the "open source-ness" of Spring. Indeed, in a comment on Rod Johnson's blog, Mularien suggests that the employment of Spring's developers by SpringSource "begs the question of how open the APL-licensed projects really are to outside involvement and contributions."

I think Mularien may be conflating "open source" with "open employment." The two are not the same.

…

Peter Mularien takes a look at the developers for Spring and comes up with an unsurprising conclusion: "the vast majority of development on Spring Core is performed by SpringSource employees."

Though Peter suggests he's not trying to make a judgment on this fact, he implies that this somehow impugns the "open source-ness" of Spring. Indeed, in a comment on Rod Johnson's blog, Mularien suggests that the employment of Spring's developers by SpringSource "begs the question of how open the APL-licensed projects really are to outside involvement and contributions."

I think Mularien may be conflating "open source" with "open employment." The two are not the same.

…