my.cnf can take the open_files_limit=N option in the [mysqld_safe] block. This doesn't do anything to mysqld directly, instead the mysqld_safe script calls ulimit -n <N>

These days, we might want to limit mysqld to use a maximum of 4 cores (using taskset on Linux) so InnoDB performance doesn't degrade. Of course this is only relevant on machines with more than 4 cores (like boxes with 2 quadcore CPUs), but still, it's nice to not have to hack mysqld_safe for such changes, as it makes upgrades less fussy and keeps config info in the one place (my.cnf).

Peter and I were discussing this, and I suggested two new options for mysqld_safe, one for pre-mysqld and one for post-mysqld commands that need to be run. Calling ulimit would be a pre-mysqld task, but taskset is post.
The one thing is that taskset needs to be passed the PID, so we must provide a way to pass that through the config …

Arrived okay - long travel, but in one piece. Staying at the doubletree.

I’m getting geared up for OSCON next week. It looks like there will be quite a few regular sessions, along with a number of Birds of a Feather sessions, focused on MySQL.

For those making it out, I thought I would mention a couple fun things to do around Portland. I’ve been living here about three years now, so I haven’t seen it all, but these are some must-sees.

• Powells Technical Books - I know they are a conference sponsor and will have a booth, but try to make it over to the real store (it’s just a short walk across the bridge from the convention center). Not only is it …

Interesting comment spotted on Jonathan Schwartz' blog:[...] I work for a major Fortune company, and we're in the process of putting Oracle on a "sunset" list of restricted vendors. No new applications are allowed on Oracle, the only approved vendors are Sun/MySQL and Microsoft/SQL Server. So I don't know how Sun did that, but if their objective was to provide competition for Oracle, it appears to have worked with my management...I know that MySQL and Oracle happily co-exist in many companies, I often train highly skilled Oracle developers and DBAs about MySQL specifics.

I was browsing the web on this lazy Sunday afternoon and ran across a good article on the Rarest Words blog. The author was trying to get Django installed and running with Postgres. From the author's own admissions, he is not a Postgres fanatic.

Well, this and last year I hear everywhere that PostgreSQL is the way to go and that usage of mySQL in 2008 makes people puke… But without any real arguments (besides "Postgres is the way to go").

After some not so compatible errors with these not so compatible databases, the author did get it working and ran some benchmarks. Postgres did not turn out faster than MySQL. If you ask anyone in the Postgres community which database is faster, they will say Postgres. Ask anyone in the MySQL community and there's no telling what …

You can generate simple bar charts directly from a MySQL prompt that look like this...

+-------+-----------------------+-----------------------------------------------+
| Month | Uptime                | Latency                                       |
+-------+-----------------------+-----------------------------------------------+
| Jan   | %%%%%%%%%%%%%%%%%%%%% | ####################                          |
| Feb   | %%%%%%%%%%%%%%%%%%%   | ##############################                |
| Mar   | %%%%%%%%%%%%%%%%%%%%  | #########################################     |
| Apr   | %%%%%%%%%%%%%%%%%%%%% | #####################                         |
| May   | %%%%%%%%%%%%%%%%%%%%% | ###############                               |
| Jun   | %%%%%%%%%%%%%%%%%%    | ############################################# |
| Jul   | %%%%%%%%%%%%%%%%%%%%% | ################################              |
| Aug   | %%%%%%%%%%%%%%%%%%%%% | …

As Baron writes it is not the number of rows returned by the query but number of rows accessed by the query will most likely be defining query performance. Of course not all row accessed are created equal (such as full table scan row accesses may be much faster than random index lookups row accesses in the same table) but this is very valuable data point to optimize query anyway.

The question of optimizing number of rows accessed is what would be the optimal number indicating query is typically well optimized ? Of course in the perfect world we would like to see rows returned = rows analyzed. though this is only possible to reach for small fraction of queries.

If you're joining multiple tables or if you have GROUP BY query the number of rows which need to be utilized to create the result set …

As Tom and I will be heading to Ottawa for OLS Tomorrow you can expect some active blogging here this week..

That is if we can manage to find quality Wifi and our batteries last long enough..
before we find power :)

Anyway .. I`ll be heading to the Virtualization Mini Summit on tuesday, and then of to the big conference.

I`ll be presenting twice, once on the miniconf about openQRM4 and Tom and I will be presenting our findings comparing different monitoring tools such as Nagios, Hyperic, Zabbix , Zenoss and others at OLS itselve.

But don't hesitate to talk to me about other interresting topics such as MySQL or Drupal :)

Now first we have to cross a couple of borders, and an ocean :)

Today I was doing some work on one of our database servers (each of them has 4 SAS disks in RAID10 on an Adaptec controller) and it required huge multi-thread I/O-bound read load. Basically it was a set of parallel full-scan reads from a 300Gb compressed innodb table (yes, we use innodb plugin). Looking at the iostat I saw pretty expected results: 90-100% disk utilization and lots of read operations per second. Then I decided to play around with linux I/O schedulers and try to increase disk subsystem throughput. Here are the results:

MySQL 5.1 was in RC stage for around 10 months now finally planned to be released as GA soon. As Monty Says MySQL 5.1.26 will be renamed as GA if no serious bugs are discovered.

Lets help MySQL to ensure GA release will be indeed GA quality and support Monty in his call to ensure this RC candidate works well for you.

If you know about any bugs in MySQL 5.1 or MySQL 5.0 (which are still unfixed in MySQL 5.1) make sure to report them on bugs.mysql.com. If there are some bugs already reported but still not fixed as of MySQL 5.1.26 make sure to post a comment to let MySQL know the bug is affecting you as well. The scream factor is important for bug fix prioritization so if you can make a story of your suffering because of the bug to slashdot you should be quite good.

If you're the customer - make sure you put …