Baron Schwartz

I’ve submitted a Birds of a Feather session for Maatkit at the upcoming MySQL conference. It’s not on the public schedule yet, but it has been accepted and scheduled for 19:00 on 13 Apr 2010. See you there!

Related posts:

1. Presentation uploaded for Maatkit talk at MySQL Conference The slides
2. I’ll be speaking at the O’Reilly MySQL Conference 2010 I’m
3. Learn about Maatkit at the MySQL Conference I’m

Related posts brought to you by Yet Another Related Posts Plugin.

It seems that a lot of people equate non-SQL databases with non-relational-ness, or malign the word relational. This is pretty much pure ignorance. If you’ve ever uttered a sentence that includes the phrase “…non-relational database…” then I have two suggestions for you.

1. Study relational algebra. At a bare minimum, read the Wikipedia article on relational algebra. There is much more you could do — take a class on the topic, or read C.J. Date’s SQL and Relational Theory (my review). Ask yourself how similar SQL is to the relational algebra. How is relational algebra different from SELECT and GROUP BY? Is relational theory about relationships between data? What part do transactions play in relational algebra? Is MySQL a relational database? What about PostgreSQL, Oracle, or DB2?
2. Now that you understand relational theory more, choose a database that you think is non-relational and write a formal proof that it is not relationally complete. Please do post a link to the proof in the comments.

The truth is, a non-relational database would be of very little use. In layman’s terms, it would mean you have some data that represents true statements, and a piece of software designed to answer questions using those facts, and you can’t answer simple first-order logic questions with the software. How is this an improvement? How is this useful?

Related posts:

1. A review of SQL and Relational Theory by C. J. Date SQL and Re
2. InnoDB is a NoSQL database As long as
3. On the unhelpfulness of NoSQL My favorit

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve been noticing an undeniable trend in my consulting engagements in the last year or so, and when I vocalized this today, heads nodded all around me. Everyone sees a growth in the number of cases where otherwise well-optimized systems are artificially limited by InnoDB contention problems.

A year ago, I simply wasn’t seeing the need for analysis of GDB backtraces en masse. These days, I’m writing custom tools to gather and analyze backtraces. A year ago, I simply looked at the SEMAPHORE section of SHOW INNODB STATUS. These days I’m writing custom tools to aggregate and reformat that data so I can interpret it more easily. And I’m actually seeing cases of this type of problem multiple times every week. I remember the first time I ran into a server that was literally optimized to the limit, but struggling under the load. It was something new for me, not that long ago. Oh, I’d seen it before, plenty, but was always able to point out where something could be improved without changing InnoDB itself. Now it’s commonplace: schemas are fine — check. Queries are all well-indexed — check. Everything else — check. InnoDB is bottlenecked and absolutely nothing can be improved — check.

Part of the difference is the rapidly improving hardware. It’s getting hard to buy a server with fewer than 8 or even 16 cores, and 16GB of RAM feels like something I’d install in a wristwatch. But I also suspect that if I’d been characterizing the workload of servers over time in a way that was easy to compare, I’d see a clear trend towards bigger data and more queries per second. We’re just pushing MySQL + InnoDB harder today than we ever have before.

What can be done? Well, InnoDB needs to be improved, that’s all. Oracle, Percona, Google, Facebook and others are working on it, and in many cases these efforts have yielded dramatic results. But there is still much room for improvement.

Related posts:

1. Hindsight on a scalable replacement for InnoDB A while ag
2. What do you know about Oracle’s InnoDB+ storage engine? That
3. Xtrabackup is for InnoDB tables too, not just XtraDB Just thoug

Related posts brought to you by Yet Another Related Posts Plugin.

One of my colleagues, Ryan Lowe, has just heard that his session on PCI compliance with MySQL has been accepted at the upcoming MySQL conference. Ryan is highly qualified to present this topic, and not many people can say that; I certainly can’t claim that title myself. If you’re looking to learn how to make your MySQL installation PCI-compliant, there’s also not a lot of trustworthy information online. Personally — and really, no bias just because he’s my colleague — I think this is a great session for the MySQL conference, which I sometimes thought didn’t have enough diversity of topics in past years. We need more stuff like this to give people a reason to return after they’ve gone for 2 or 3 years in a row.

Related posts:

1. Learn about Maatkit at the MySQL Conference I’m
2. Learn about mk-query-digest at PgEast 2010 I’ll
3. There will be an O’Reilly MySQL Conference in April 2010 O’Re

Related posts brought to you by Yet Another Related Posts Plugin.

Which is better? I don’t know, because I’m a Vim user, so it’s a moot point for me. But I have not noticed any Emacs-style keyboard shortcuts on websites. To the contrary, it seems like everything is Vim-style — certainly most Google apps are Vim-ish, and even Firefox is Vim-ish (press the / key to start searching for text on the page). Based on this highly scientific criterion, I declare Vim the winner.

Related posts:

1. How to add paragraph spacing in Google Docs I’m
2. How to find per-process I/O statistics on Linux Newer Linu

Related posts brought to you by Yet Another Related Posts Plugin.

I’ll be helping Morgan Tocker deliver the second half of his training course for MySQL Developers/DBAs in New York City in a few days (more Percona training). It was a snap decision at the last minute, but I’m hoping I’ll still get to meet some folks there. If we’ve corresponded over email or blog comments and you would like to get together, ping me in the comments here!

If you’re in the New York City area and you use MySQL, you should consider attending this course, too. Morgan knows his stuff and has written a good curriculum. Attendees give his courses excellent feedback, and the price is very reasonable. Oh, and I’ll be there too, did I mention that? You can pick my brain, no extra charge. Bring organic free-trade chocolate to assist with extra-tough questions.

Related posts:

1. What data types does your innovative storage engine NOT support? I’ve
2. Recap of CPOSC 2009, plus slides Yesterday

Related posts brought to you by Yet Another Related Posts Plugin.

The headline is flame-bait, don’t take it. I just wanted to point something out about character sets and collations in MySQL.

To the uninitiated, it may seem overwhelming. Everything has a character set! Everything has a collation! And they act weirdly! The server has one. The database has one (oh, and it changes magically as I USE different databases.) Every table has one, and columns too. Is that all? NO! My connection has one! Kill me now!

Relax. In truth, only one kind of thing actually has a charset/collation. That is values. And values are stored in columns. The only thing that really has a charset/collation is a column.[1]

What about all the rest of those things — connection, database, server, table? Those are just defaults, which determine what charset/collation a value gets if it isn’t overridden. So if the table’s default charset is utf8, and you add a column without saying what it should be — why, it’ll be utf8. If the database’s default is latin1 and you add a table without saying what its default should be, it’ll be latin1.

[1] It’s not quite true. Literal values in SQL statements are values too, as are @user_variables. But if your connection’s charset is latin1 and you say SELECT "xaprb", without an explicit introducer, you’re really saying SELECT _latin1 "xaprb". Again, the only thing that really has a charset/collation is a value. Other things are just defaults.

Related posts:

1. What data types does your innovative storage engine NOT support? I’ve
2. The difference between a unique index and primary key in MySQL There
3. Sanity-check features in MySQL MySQL has

Related posts brought to you by Yet Another Related Posts Plugin.

Cary Millsap has a concise, readable paper on performance. Anyone involved in database performance optimization should read it. Cary’s writing has heavily influenced the mk-query-digest tool for analyzing MySQL/PostgreSQL/Memcached/HTTP query performance, and I think you’ll get a lot more from mk-query-digest if you read this paper — and you should also read his book, reviewed here. It’s one of the top books on my Essential Books List.

Related posts:

1. A review of Optimizing Oracle Performance by Cary Millsap Optimizing
2. Sessions of interest at the Percona Performance Conference Having wri
3. An ongoing thread of blogs on MySQL performance In the las

Related posts brought to you by Yet Another Related Posts Plugin.

I’m speaking at the O’Reilly MySQL Conference 2010. I hope I don’t lose my voice, because I have four sessions!

• Diagnosing and Fixing MySQL Performance Problems
• EXPLAIN Demystified
• Read-Write Splitting: Techniques, Challenges, and Solutions
• MySQL Graphing and Trending with Cacti

You can click through on the links above to learn more about each session. I’m also looking forward to the other sessions. Here’s a sample of a few that I have my eye on:

• Linux performance tuning and stabilization tips by Yoshinori Matsunobu
• MySQL Proxy meets: Memcache by Jan Kneschke
• PHP Object-Relational Mapping Libraries In Action by Fernando Ipar

The schedule is far from complete, because the conference committee is still working on it, but the proposals to choose from are impressive. Stay tuned as more talks are approved and the schedule fills out, and don’t wait too long to register and book your flight! This is going to be a banner year.

Related posts:

1. Submit your proposals for MySQL conference 2010 The MySQL
2. There will be an O’Reilly MySQL Conference in April 2010 O’Re
3. Speaking at EdUI Conference 2009 I’m

Related posts brought to you by Yet Another Related Posts Plugin.

I’ll be attending PgEast this year, as I’ve done for the last couple of years, and this year I’ll also be speaking. The topic is query analysis with mk-query-digest. The official description of my talk is as follows:

mk-query-digest is a powerful open-source tool for capturing, filtering, transforming, and aggregating queries, with the ability to do all sorts of other advanced tasks too. By default, it aggregates similar queries together and presents a designed-for-DBAs report with statistics about the most important queries, so you can see where to focus your optimization efforts. This talk shows you how to use mk-query-digest to analyze your Postgres server’s workload.

PgEast 2010 has an impressive lineup of talks, which isn’t even complete yet. I’ve thoroughly enjoyed this conference in the past, and it looks like this year will be better than ever.

Related posts:

1. mk-query-digest now supports Postgres logs Maatkit do
2. mk-query-digest now understands HTTP You used t
3. Learn about Maatkit at the MySQL Conference I’m

Related posts brought to you by Yet Another Related Posts Plugin.

Maatkit does more than just MySQL. I’ve just committed a new version of mk-query-digest, a powerful log analysis tool, with support for Posgtres logs, in both syslog and stderr format. I’m hoping that people will give this a spin in the real world. I have lots of test cases, but that’s never enough; I’m looking for people to crunch their logs and let me know if anything breaks.

A brief tutorial:

# Get it $ wget http://www.maatkit.org/trunk/mk-query-digest # Run it $ perl mk-query-digest --type pglog /path/to/log/file # Learn about it (search for the string "pglog") $ perldoc mk-query-digest

I’m going to close comments on this blog post so I don’t get bug reports in the comments. If you have feedback, please post it to the Maatkit mailing list, or the Maatkit issue tracker. Or reply to the thread I just started on the Postgres mailing list.

Related posts:

1. Learn about mk-query-digest at PgEast 2010 I’ll
2. mk-query-digest now understands HTTP You used t
3. I’m a Postgres user, as it turns out Someone re

Related posts brought to you by Yet Another Related Posts Plugin.

Understanding MySQL Internals

Understanding MySQL Internals. By Sasha Pachev, O’Reilly 2007. Page count: about 227 pages. (Here’s a link to the publisher’s site).

I should have read this book a long time ago, and it’s my loss that I didn’t. Although the title makes it sound like it should only benefit those who’ll be changing the MySQL server’s own code, that’s not true. To the contrary, at least parts of this book should be required reading for DBAs and developers who use MySQL, after they gain a moderate level of familiarity with how to use the server.

The book does indeed start off with a few chapters on the source code, how to work with it, and the core structures that make up the MySQL server at the source code level. However, even these topics hold value for users such as DBAs. If you don’t know how the server really works, you are lost when you are faced with a problem or asked to understand some behavior. Peter Zaitsev refers to this as “X-Ray Vision,” something a good DBA or consultant needs. I think the first few chapters of this book are a great way to develop that X-Ray Vision into MySQL.

The next couple of chapters are on the client/server API, configuration variables, and thread-based architecture. Although the first is probably not a core competency for DBAs, the others are. I sure wish I’d had the client/server protocol chapter handy when I was working with the protocol, though. It is variously more useful than, and a good supplement to, the internals document on the MySQL wiki.

The following chapters cover the storage engine interface, the server-level lock manager and how it interacts with the storage-engine locking, and the parser and optimizer. These are absolutely core knowledge for DBAs and developers in my opinion. The server/storage-engine division is one of the things that makes MySQL different from other databases, and is mandatory to understand deeply. This applies equally well to the rest of the chapters, which cover the parser, optimizer, various storage engines (as opposed to just the server’s interface to them), transactions, and replication. Mandatory, every one.

What’s missing? I found that the book is kind of funny in one major way. It doesn’t talk much about MySQL 5.0. Instead, it delves into 4.x and 5.1. Most of the new features in 5.0 are not mentioned at all. Stored procedures, the INFORMATION_SCHEMA, triggers, and so on are absent, as are most discussions of changes to the optimizer and so forth. Some 5.0 topics are covered: index merge, for example. But by and large, there’s not a lot of coverage here. The 5.1-specific topics are those such as the new storage engine API and row-based binary logging. Events are not covered, nor are changes to other types of logging. Honestly, I feel this is appropriate in a book this size; the stuff that hasn’t changed since 4.x days is more important to understand.

There’s little discussion of exactly how certain features work, such as the different sorting algorithms. But that’s OK. These are covered pretty well by the MySQL manual, and even by my own book High Performance MySQL 2nd Edition. I think some other major topics might be missing, but I can’t quite think of them now.

The book is really well written. I expected it to be dry but it’s not at all. It’s actually engaging and interesting. I also found a curious thing happening as I read: I became more aware of how much legacy cruft there is inside MySQL, and how much that has contributed to various shortcomings. This made me actually feel sad, and made me yearn for the bright pure clean exciting vision that Drizzle strives towards. But at the same time I kind of felt nostalgic, kind of fell a little more in love with MySQL, for its strengths and for the countless hours of work and the really monumental genius that it embodies, warts and all. It was quite a cognitive dissonance experience, to tell the truth!

For those who have any inclination to reading it, I’d say: do it. It’ll benefit you a lot more than you think. And if possible, do it with a copy of the MySQL source code available and actually take the time to look through it and explore the things Sasha suggests. I read this book on an airplane, far from a computer, and I need to read it again and look at source code as I do so. I am positive I’ll get more than twice as much benefit from this second reading than I did from the first. I say that because I have a shin-deep exposure to the MySQL source code myself, so I knew just enough about it to recognize that I really would get a lot more from going and looking at the code Sasha cross-referenced. It was a bit like speaking Spanish without a dictionary, but having had a few weeks of intensive instruction ten years ago. I remembered some things well, other things just hazily.

Overall, this book is easily a high 4 stars on a scale of 5, and again, anyone seriously using MySQL should have it.

Related posts:

1. A review of MySQL Administrator’s Bible MySQL Admi
2. A review of Get it Done with MySQL 5&6 by Peter Brawley and Arthur Fuller Get it Don
3. A review of Pentaho Solutions by Roland Bouman and Jos van Dongen Pentaho So

Related posts brought to you by Yet Another Related Posts Plugin.

I explored two interesting topics today while learning more about Postgres.

Partial page writes

PostgreSQL’s partial page write protection is configured by the following setting, which defaults to “on”:

full_page_writes (boolean)

When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint… Storing the full page image guarantees that the page can be correctly restored, but at a price in increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.)

Trying to reduce the cost of full-page writes by increasing the checkpoint interval highlights a compromise. If you decrease the interval, then you’ll be writing full pages to the WAL quite often. This should in theory lead to surges in the number of bytes written to the WAL, immediately following each checkpoint. As pages are revisited over time for further changes, the number of bytes written should taper off gradually until the next checkpoint. Hopefully someone who knows more can confirm this. Does anyone graph the number of bytes written to their WAL? That would be a nice illustration to see how dramatic this surging is.

Decreasing the checkpoint interval seems a bit scary, and is bound to have its own costs, for all the usual reasons. A massive checkpoint once in a while should be really expensive, and would lead to a bad worst-case time for recovery. Does the new bgwriter implementation in 8.3 fix any of this? In theory it could, but I don’t know enough yet to say. I have heard conflicting opinions on this point. I have a lot more to read about it before I form my own opinion.

Storing full pages might not really be that expensive. It could bloat the WAL, but is the cost (in terms of time) really that high? InnoDB (in MySQL) protects against partial page writes with a double-write strategy: a region in the tablespace is called the doublewrite buffer. Page writes are first sent to the doublewrite buffer, then to their actual location in the data file. I don’t remember where, but I’ve seen benchmarks showing that this doesn’t hurt performance, even though it seems counter-intuitive. Modern disks can do a lot of sequential writes, and the way InnoDB writes its data makes a lot of things sequential. I doubt that putting full pages into the PostgreSQL WAL is forced to cost a lot, unless there is an implementation-specific aspect that makes it expensive.

The TODO has some items on the WAL, which look interesting — “Eliminate need to write full pages to WAL before page modification” and a couple more items. I need to understand PostgreSQL’s recovery process better before I know what these really mean.

Detecting data corruption

I was able to verify that the WAL entries have a checksum. It is a CRC32. This is in xlog.c.

However, as far as I can understand, the answer for detecting data corruption in normal data pages is “Postgres doesn’t do that.” I was told on the IRC channel that normal data pages don’t have checksums. I am not sure how to verify that, but if it’s true it seems like a weakness. I’ve seen hardware-induced corruption on InnoDB data many times, and it could sometimes only be detected by page checksums.

What happens when a page is corrupt? It probably depends on where the corruption is. If a few bytes of the user’s data is changed, then I assume you could just get different data out of the database than you inserted into it. But if non-user data is corrupted then do you get bizarre behavior, or do you get a crash or error? I need to learn more about PostgreSQL’s data file layout to understand this. Imagining (I haven’t verified this) that a page has a pointer to the next page, what happens if that pointer is flipped to refer to some other page, say, a page from a different table? If TABLE1 and TABLE2 have identical structures but different data, could SELECT * FROM TABLE1 suddenly start showing rows from TABLE2 partway through the results? Again I need to learn more about this.

Related posts:

1. What data types does your innovative storage engine NOT support? I’ve
2. PostgreSQL Conference East 2009, Day Three As I said
3. PostgreSQL Conference East 2009, Day Two I missed F

Related posts brought to you by Yet Another Related Posts Plugin.

Many times I’ve heard people advise on “best practices” for a MySQL database. This often includes routine maintenance, such as “you should run OPTIMIZE TABLE on all of your InnoDB tables once a week to defragment them for better performance.”

But this advice is unsubstantiated and could even be detrimental. Here are some of the obvious problems that I can think of:

• The optimized table compacts the primary key (clustered index) to its default 15/16ths fill factor per page. But other indexes will be built in pseudo-random order and are likely to end up just as fragmented afterwards as before. Which indexes are more important for performance? Maybe the primary key is just a dummy value that’s not even used, and the secondary indexes are the ones that would benefit from compacting.
• Suppose the primary key is the important one, and SELECT queries will perform more quickly if it’s defragmented. Why does it get fragmented? Because of changes to the table. Now these changes could suddenly slow down dramatically as they are forced to split pages at a much higher rate due to the more compact data layout.

Why do people make a blanket “you should defragment” statement without supporting it with hard facts? It sounds like something you’d hear from a naive Windows user who buys a $99 piece of software to make his PC “boot faster” or “fix his registry” or something. Maybe it ain’t broke and should not be fixed.

I believe we hear advice like this because there isn’t easy-to-get data that can tell us the truth. To make decisions about defragmenting tables responsibly, we need either performance data on that table (hard to get in most cases), or failing that, information about cost and frequency of page splits in general (not available from InnoDB at present). It would help to have these metrics, and I think it might not be very hard to add page-split instrumentation to InnoDB.

Related posts:

1. Analyze and optimize memcached usage with Maatkit Ryan poste
2. Extended covering indexes As you can
3. How PostgreSQL protects against partial page writes and data corruption I explored

Related posts brought to you by Yet Another Related Posts Plugin.

InfiniDB has a sensible Enterprise/Community release process, which seems similar to what I suggested for MySQL. Its simplicity also stands in stark contrast to MySQL’s new release policy, which is hard to understand and has been confusing people.

Related posts:

1. Thank you for the MySQL 5.4 Community Release MySQL 5.4
2. How to find per-process I/O statistics on Linux Newer Linu
3. MySQL Enterprise/Community split could be renewed under Oracle One of MyS

Related posts brought to you by Yet Another Related Posts Plugin.

Yes, Maatkit’s name was inspired by Ma’at, which has an apostrophe. But there is NO apostrophe in the name of the popular toolkit for MySQL users.

I’m just sayin’.

Related posts:

1. Learn about Maatkit at the MySQL Conference I’m
2. Speaking about Maatkit at CPOSC I’m
3. Making Maatkit more Open Source one step at a time If you

Related posts brought to you by Yet Another Related Posts Plugin.

I’m on the voting committee of the MySQL Conference this year. I was on the same committee in 2008. This year’s submissions are awesome. Much different from previous years, for whatever reason.

Some of the proposals are sales pitches, infomercials, or just generally BS, but there’s a gang of sharp-eyed people on the committee who are digging into who submits the proposals, what their company does, etc. Those sessions are getting shot down with bluntly honest reviews and low votes. I have a pretty good reason to believe those votes will carry a lot of weight. But even if they don’t, there simply aren’t many bad proposals! The overwhelming majority of them are very useful technical proposals from people who really know what they are talking about.

This year I truly agree that this is going to be a “deeply technical” event, as it has been marketed to be for years. You should be there — seriously. This will probably be the MySQL educational event of the year. Managers, send your DBA and developer teams.

If you’re looking at the sessions on the website, you should know that we’re still accepting proposals and there are many proposals coming in. I think there were more than 30 new ones today. (Good grief, another one just arrived in the last few minutes!) The few sessions that have been accepted are just early-in, early-accepted. There’s a lot more to come.

Related posts:

1. How to write a good MySQL conference proposal I’m
2. Looking back at the MySQL news from last year I think it
3. Submit your proposals for MySQL conference 2010 The MySQL

Related posts brought to you by Yet Another Related Posts Plugin.

I’d like an UNTIL clause, please. I’d use it sort of like LIMIT in MySQL and PostgreSQL, except that it would define when to stop returning looking for rows, instead of defining how many to return. Example:

SELECT * FROM users ORDER BY user_id UNTIL user_id >= 100;

That would select users up to and including user 99. Ideally the clause could accept any boolean predicate, including subqueries. I’ll hold my breath and wait for this wish to come true now.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Get it Done with MySQL 5&6

Get it Done with MySQL 5&6. By Peter Brawley and Arthur Fuller. Self-published, 2009. Page count: about 615 pages. I asked the authors for a print edition to review, but it is also available as an e-book.

The right word to describe this book falls somewhere between “tome” and “lunker.” You could beat back an unwelcome salesperson with it. You could also beat back any number of stubborn database problems. It’s kind of like a MySQL Manual plus a ton of practical how-to-use-MySQL information.

This is an unusual book in that it is useful for a very broad audience. I’d say you can get a lot out of it if you are a) new to databases b) new to MySQL c) in need of reference material d) looking for practical examples of installing or using MySQL e) trying to figure out how to design and optimize queries for MySQL f) trying to hook MySQL up to a popular programming language including PHP, Perl, Java, .NET, or C g) administering MySQL h) working with complex queries such as graphs or date and time queries i) using MySQL together with Microsoft Visual Studio 2005. Wow.

The material is generally timely, relevant, and correct. It’s also well organized and quite complete. There are cases where an extra-deep level of detail is lacking, but there’s certainly enough for a moderate to advanced user in most topics, and lots of topics go extra-deep.

On the minus side, the book is a bit hard to read at times due to a crowded layout. The table of contents is hard to scan because it doesn’t use the traditional outline format. The margins are small and the headings are bulky and intrusive. There aren’t many illustrations, and those aren’t great quality. Tables are inconsistently formatted. The index is not very comprehensive. The binding and printing, however, looks great. (Not at all like the MySQL Cluster certification guide, which looked like it’d been printed on recycled newsprint.)

So in general, I’m complimenting the content and criticizing the typesetting. Overall, it’s a great one-stop-shop for MySQL knowledge. I think this is a very good value in comparison to books from traditional publishers targeted at the same types of users, especially since you can buy the e-book and get free updates, which are frequently released.

Related posts:

1. A review of MySQL Administrator’s Bible MySQL
2. A review of Pentaho Solutions by Roland Bouman and Jos van Dongen Pentaho
3. A review of The Art of Capacity Planning by John Allspaw The Ar

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve released version 1.1.6 of the Better Cacti Templates project. This release includes a bunch of bug fixes (but not all of them!) and two new sets of graphs. One set is for disk I/O on GNU/Linux, and the other is a new set of templates for OpenVZ. I’m looking for feedback on both of those. This release also has a bunch of code-level features: much better test coverage (hooray!), and a refactored ss_get_by_ssh.php that makes it much easier to create new graphs and templates. The SSH-based templates also take advantage of the same caching as the MySQL templates, which makes them a lot more efficient.

There are upgrade instructions on the project wiki for this and all releases. There is also a comprehensive tutorial on how to create your own graphs and templates with this project. Use the project issue tracker to view and report issues, and use the project mailing list to discuss the templates and scripts.

The full changelog follows.

2010-01-10: version 1.1.6 * Added OpenVZ graphs (--type openvz) (issue 95). * Added IO usage graphs (--type diskstats) (issue 97). * Added extra error-reporting (issue 110). * The $debug $debug_log options couldn't be set in the .cnf file (issue 110). * Added a --use-ssh option to ss_get_by_ssh.php (issue 66). * Added a debugging log to ss_get_by_ssh.php (issue 54). * Enabled caching of results in ss_get_by_ssh.php (issue 46). * Added a test suite for ss_get_by_ssh.php (issue 110). * The 'free' stats suffered from PHP's issues with big numbers (issue 102). * There was ambiguity (but no error) in SHOW STATUS overrides (issue 106). * It was hard to debug failures caused by missing ext/mysql (issue 105). * Code to make ss_get_mysql_stats.php testable was broken (issue 108).

Related posts:

1. Version 1.1.4 of improved Cacti templates released I’ve
2. Version 1.1.5 of improved Cacti templates released I’ve
3. Version 1.1.2 of improved Cacti templates released I’ve

Related posts brought to you by Yet Another Related Posts Plugin.