Have you ever had deja vu? I re-read books on occasion, because I like them, and every once in a while I’ll re-read a book that I think I’m reading for the first time. Then I’ll sit there with this twisted-up look on my face, wondering why all the words seem so familiar. Then I remember when and where I saw them last.

I’ve been reading the new Fedora™ 7 Unleashed book by Andrew and Paul Hudson, and I’ve had that feeling several times. So I’ve made my face and wracked my brain, trying to figure out how I’ve read this before. The answer? I read Fedora Core 6 Unleashed and Fedora Core 5 Unleashed before that.

Its unfortunate. I think these ‘distro tomes,’ so to speak, provide a valuable service to the Linux uninitiated, and can be useful to more seasoned sysadmins interested in the latest technology a new release of a given distribution has to offer. The unfortunate part is that both of these groups have to suffer through repetitive rehashing of methods, processes, and utilities that have been throughly documented in a multitude of locations and media.

To be fair, this book does some things quite well, but as I’ve looked at more and more works in its genre, I’ve come to realize that the good ones are characterized by a bias toward documenting whatever new technology is available, while the less useful ones focus more on maximizing the width of their spine with well-worn stock material. I’m sorry to say that this book leans more toward the latter.

But lets not dwell on the negative (or at least let’s not start there). Theres good in everyone, and there is good in this book. Some of you may remember that I wrote a review of Tammy Fox’s book, Red Hat® Enterprise Linux® 5 Administration Unleashed. This book, like that one, does many of the same things rather well. Specifically, it handles new technologies with aplomb.

Xen, while not new technology per se, is sufficiently in its infancy. The online documentation is still somewhat fragmented, and a concise summary of how xen virtualization operates is a perfect example of what this book excels at. SELinux also gets very fair treatment in this book, as does the Mono programming language. While not strictly bleeding edge, these topics are still sufficiently new that consolidated documentation is a benefit that books like this provide very well.

Most of the sections in this book have their usefulness. Everyone needs to know how the useradd or cp commands work. But I just can’t get past (and yes, I’m back to dwelling on the negative) how re-hashed so many of these chapters are. As part of my review of this book, I went and took a quick look at the table of contents for Fedora Core 6 Unleashed. Written by the same authors, its an amazing example of documentation re-use. Several of the chapters look sufficiently similar as to be identical.

I don’t want to insinuate that the information in these sections isn’t useful, it really is. It contains information everyone needs to know. You can’t administer a system without being able to change passwords, set up remote access, preform backups, so on and so forth. But good gosh! Lets just take one example: Chapter 17, Apache Web Server Administration. Its almost 40 pages of documentation about how to manage, configure, and tune the Apache web server to provide web pages to interested parties. Hmm, I wonder what would happen if I typed ‘Apache howto’ into Google. Dum de dum….hey, 2.550,000 hits! I wonder if Apache has a web site…..hey what do you know? They look like they might have some comprehensive documentation. And Amazon indicates there are 1,285 books on sale at their site exclusively on the subject of the Apache web server.

The same is true of the sections on FTP, database, SSH and network file access. Note to the authors: We’re covered. Your material is useful and factually accurate, but I just can’t get past the fact that it’s not really necessary. You could have written a book that was half as big, was consequently less expensive, and yet still provided all the same useful content.

I have a feeling it’s not the authors fault. You can pick up any number of comprehensive high-level OS documentation books, and see this. There is some material that is just covered again….and again….and again. My inner conspiracy theorist is convinced it’s more than coincidence. I firmly believe that (a) extraterrestrials are out there, and (b) publishers of these books will encourage their authors to add content in an effort to claim more shelf space. I think a better technical bookshelf could be constructed with a series of more targeted topics, but such an approach lowers the revenue generated by this type of books.

So that only leaves the final question: Should you buy this book or not? I’ve been pretty hard on it–in my view, with good reason. Despite that, I still think there is a demographic for whom this book would be fairly useful.

If you have any significant experience with a Linux distribution of any origin, I would expect that you have the skill (both technical and research-oriented) to find the information contained in this book on the web (or elsewhere). Likewise, if you’re a sysadmin, and you have experience (in a Linux or non-Linux environment) I would expect that your technical bookshelf has much greater depth, and much more targeted breadth, specific to your needs. So, clearly, this one’s not for those with experience.

However, if you are new to Linux and are interested in getting your feet wet, you probably don’t want to invest a fortune on reference material, or spend too many hours poking about on mailing lists or web sites putting together a reasonable set of information to get started. If this is you, then yes, this book is a good choice. It offers a comprehensive outline of what you need to know to work with Fedora 7, both as an end user and as an admin. And thats quite likely why these books tend to be a perennial favorite.

The Linux community has a consistent influx of new users and curious onlookers who have the desire to know more. A consumer-oriented, one-stop shop might get them there faster than the community would, with its plethora of websites and arcane knowledge passed down though stories on cryptic mailing lists. So to keep current, these books keep coming. And if you’re new, it could be your first step into a bigger world.

Look at this post recently published on TechCrunch - It is ugly standard 404 error message, but what is interesting is the server line which shows nginx 0.5.32

I have checked and indeed images served from assets.hulu.com have nginx server in response header.

This would be the first site of this (planned) scale to run Nginx. So far even though Nginx was used by many major companies in Russia, the rest of the world preferred lighttpd often due to better documentation and more active development community.

Entry posted by peter | 2 comments

Add to: | | | |

Interviewing people for our Job Openings I like to ask them a basic question - if you have a server with 16GB of RAM which will be dedicated for MySQL with large Innodb database using typical Web workload what settings you would adjust and interestingly enough most people fail to come up with anything reasonable. So I decided to publish the answer I would like to hear extending it with basics of Hardware OS And Application optimization.
I call this Innodb Performance Optimization Basics so these are general guidelines which work well for wide range of applications, though the optimal settings of course depend on the workload.

Hardware
If you have large Innodb database size Memory is paramount. 16G-32G is the cost efficient value these days. From CPU standpoint 2*Dual Core CPUs seems to do very well, while with even just two Quad Core CPUs scalability issues can be observed on many workloads. Though this depends on the application a lot. The third is IO Subsystem - directly attached storage with plenty of spindles and RAID with battery backed up cache is a good bet. Typically you can get 6-8 hard drives in the standard case and often it is enough, while sometimes you may need more. Also note new 2.5″ SAS hard drives. They are tiny but often faster than bigger ones. RAID10 works well for data storage and for read-mostly cases when you still would like some redundancy RAID5 can work pretty well as well but beware of random writes to RAID5.

Operating System
First - run 64bit operating system. We still see people running 32bit Linux or 64bit capable boxes with plenty of memory. Do not do this. If using Linux setup LVM for database directory to get more efficient backup. EXT3 file system works OK in most cases, though if you’re running in particular roadblocks with it try XFS. You can use noatime and nodiratime options if you’re using innodb_file_per_table and a lot of tables though benefit of these is minor. Also make sure you wrestle OS so it would not swap out MySQL out of memory.

MySQL Innodb Settings
The most important ones are:
innodb_buffer_pool_size 70-80% of memory is a safe bet. I set it to 12G on 16GB box.
innodb_log_file_size - This depends on your recovery speed needs but 256M seems to be a good balance between reasonable recovery time and good performance
innodb_log_buffer_size=4M 4M is good for most cases unless you’re piping large blobs to Innodb in this case increase it a bit.
innodb_flush_logs_at_trx_commit=2 If you’re not concern about ACID and can loose transactions for last second or two in case of full OS crash than set this value. It can dramatic effect especially on a lot of short write transactions.
innodb_thread_concurrency=8 Even with current Innodb Scalability Fixes having limited concurrency helps. The actual number may be higher or lower depending on your application and default which is 8 is decent start
innodb_flush_method=O_DIRECT Avoid double buffering and reduce swap pressure, in most cases this setting improves performance. Though be careful if you do not have battery backed up RAID cache as when write IO may suffer.
innodb_file_per_table - If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim. This option was added in MySQL 4.1 and now stable enough to use.

Also check if your application can run in READ-COMMITED isolation mode - if it does - set it to be default as transaction-isolation=READ-COMITTED. This option has some performance benefits, especially in locking in 5.0 and even more to come with MySQL 5.1 and row level replication.

There are bunch of other options you may want to tune but lets focus only on Innodb ones today. You can check about tuning other options here or read one of our MySQL Presentations.

Application tuning for Innodb
Especially when coming from MyISAM background there would be some changes you would like to do with your application. First make sure you’re using transactions when doing updates, both for sake of consistency and to get better performance. Next if your application has any writes be prepared to handle deadlocks which may happen. Third you would like to review your table structure and see how you can get advantage of Innodb properties - clustering by primary key, having primary key in all indexes (so keep primary key short), fast lookups by primary keys (try to use it in joins), large unpacked indexes (try to be easy on indexes).

With these basic innodb performance tunings you will be better of when majority of Innodb users which take MySQL with defaults run it on hardware without battery backed up cache with no OS changes and have no changes done to application which was written keeping MyISAM tables in mind.

Entry posted by peter | 9 comments

Add to: | | | |