Before I leave Grazr to work at Lycos, I've been tasked with
documenting several things-- MySQL setup, including replication,
nagios, UDFs we use, etc. I was describing on our wiki what using
InnoDB means, and some basic things about settings. Here's a
tidbit of it that I think is useful information.
Some important InnoDB Characteristics
InnoDB stores data and files in the same place whereas MyISAM has
separate index and data files. InnoDB stores it's data in either
a single tablespace file (ibdataN -- n being number) which
containins all tables, or a single auto-extending tablespace file
set by innodb_file_per_table (tablename.ibd), which is what we
use for grazr because file-per-table allows OPTIMIZE TABLE to
reclaim space from deletions, would could gives better
performance with better optimized tables. Also allows you to
restore backups of single tables without interrupting the use of
the remaining InnoDB tables (per …
I've mentioned Infobright before as an interesting solution to getting more performance to BI analytics solutions. Today's news are interesting: Sun invests in the company, and the baseline product is open sourced. Too busy to write more about it today, but I'm certainly watching this one closely.
This Monday, September 8th, the Boston MySQL User Group broke our 2-month summer hiatus with a presentation on MySQL Views.
The slides can be downloaded from http://www.technocation.org/files/doc/2008_09_Views.pdf -- 89 kB, .pdf format.
The 199 Mb .flv file can be downloaded at http://technocation.org/node/621/download or played directly in your browser at http://technocation.org/node/621/play.
The presentation covers:
Description:
The drupal_lookup_path function unnecessarily counts all rows of
the url_alias table to determine if any aliases are defined. This
can be expensive on a transactional database such as MySQL with
the InnoDB Storage Engine or PostgreSQL when a website has a lot
of aliases. This patch modifies the query to always only return
one row, possible because any existing pid will be greater than
0. If no aliases are defined, it will return 0.
Status:
This patch has not been merged into any release of Drupal.
Patch
Properties:
| Applicable To | InnoDB |
| Server Startup Option |
--innodb_log_file_size=<value>
|
| Scope | Global |
| Dynamic | Yes |
| Possible Values |
Integer: Range: 1M - 4G <1M will be adjusted to 1M |
| Default Value | 5M |
| Category | Performance, Maintenance |
Description:
This variable defines the size of each log file in a log group.
While setting this variable it should be noted that combined size
of all log files should be less than …
In a lot of environments.
Peter gives a nice overview why you don't always need to invest in big fat redundant hardware.
We've tackled the topic last year already ..
Now I often get weird looks when I dare to mention that Raid is obsolete ..people fail to hear the "in a lot of environments"
Obviously the catch is in the second part, you won't be doing this for your small shop around the corner with just one machine. You'll only be doing this in an environment where you can work with a redundant array of inexpensive disks. Not with a server that has to sit in a remote and isolated location.
Next to that there are situations where you will be using raid, but not for redundancy, but for disk throughput.
I attended several events in June of this year including Graphing Social Patterns East, Velocity and Structure
08. At each of these events, I tried to take some notes and
posted them to my personal blog. I received a few pings from readers
of this blog to point them to a list of these posts. It took some
time but here is the list of my notes. In some cases, I have
linked directly to the presentation files.
High-performance Ajax Applications: Julien
Lecomte (Yahoo!) talked about how to …
One of the approaches we are using to look at MySQL scalability is to identify and if possible eliminate hot locks inside MySQL. For locks that cannot be eliminated, we are looking at ways to reduce the mutex hold times, or replace the critical sections with lock-free algorithms. It won't happen overnight, but it needs to be done if we are to make MySQL more scalable.
Along the way we're planning to blog about how we identified and eliminated performance bottlenecks and provide you with all the gory details about the process and technique. This will hopefully entice you all to contribute to fixing performance issues We can reach our goal of a highly scalable MySQL much faster!. If you any other ideas about how we can scale the MySQL scalability effort (pun intended), or you would like to bust some locks, please feel free to let us know.
Fixing locks is sometimes very tricky as sometimes eliminating a really hot lock can only …
[Read more]One of the approaches we are using to look at MySQL scalability is to identify and if possible eliminate hot locks inside MySQL. For locks that cannot be eliminated, we are looking at ways to reduce the mutex hold times, or replace the critical sections with lock-free algorithms. It won't happen overnight, but it needs to be done if we are to make MySQL more scalable.
Along the way we're planning to blog about how we identified and eliminated performance bottlenecks and provide you with all the gory details about the process and technique. This will hopefully entice you all to contribute to fixing performance issues We can reach our goal of a highly scalable MySQL much faster!. If you any other ideas about how we can scale the MySQL scalability effort (pun intended), or you would like to bust some locks, please feel free to let us know.
Fixing locks is sometimes very tricky as sometimes eliminating a really hot lock can only …
[Read more]One of the approaches we are using to look at MySQL scalability is to identify and if possible eliminate hot locks inside MySQL. For locks that cannot be eliminated, we are looking at ways to reduce the mutex hold times, or replace the critical sections with lock-free algorithms. It won't happen overnight, but it needs to be done if we are to make MySQL more scalable.
Along the way we're planning to blog about how we identified and eliminated performance bottlenecks and provide you with all the gory details about the process and technique. This will hopefully entice you all to contribute to fixing performance issues We can reach our goal of a highly scalable MySQL much faster!. If you any other ideas about how we can scale the MySQL scalability effort (pun intended), or you would like to bust some locks, please feel free to let us know.
Fixing locks is sometimes very tricky as sometimes eliminating a really hot lock can only …
[Read more]