Posted by Baron Schwartz |
We’re hiring. We are looking for the following qualifications:
- Expert knowledge of MySQL. Not just “certified” — years of production experience with it. You need to know server internals, for example. You need to be able to do anything from optimizing difficult queries to moving high-volume services between data centers without interruption.
- Expert knowledge of InnoDB. You should understand its inner workings well enough to answer questions about its internals from memory, such as “how does the insert buffer work?” or “how does MVCC work on secondary indexes?” You should also know why it has trouble on some workloads and how to solve that.
- Expert knowledge of Linux systems administration. You need to know how to solve issues with filesystems, hardware, and networking. You need to be able to use tools such as gdb, strace, tcpdump, etc to solve weird problems.
- Expert with Apache, memcached, and other technologies you’d typically find in a LAMP application. You need to be able to administer and troubleshoot a variety of popular open-source server software.
- Proficient with Maatkit and MMM.
- Proven success working in a distributed environment where e-mail, IRC and voice calls are your only interaction with clients, colleagues and managers on a daily basis. You must be a self-starter.
We need all of the above, but if you’re a little weaker in some areas that might be OK. Highly desirable skills include:
- Non-core MySQL technologies: XtraDB, Xtrabackup, NDB Cluster, third-party storage engines and appliances, etc.
- Technologies such as LVS, Nginx, Sphinx, and load balancers.
- Other operating systems such FreeBSD and OpenSolaris.
- Amazon’s cloud offerings.
- Programming languages and platforms, especially frameworks such as Ruby On Rails and Django.
If you think you’re a good candidate, please fill out the contact form on our website. Thanks!
Posted by peter |
When we’re looking at mk-query-digest report we typically look at the Queries causing the most impact (sum of the query execution times) as well as queries having some longest samples. Why are we looking at these ?
Queries with highest Impact are important because looking at these queries and optimizing them typically helps to improve system capacity, which in the end often improves response time of the system for variety of queries. Also queries causing highest impact often correspond to either frequent or slowest transactions in the system which makes these queries important to look at.
[read more...]
Posted by
peter @ 7:43 pm ::
mysql ::
Posted by peter |
As the deadline for EC to decide if Oracle can acquire Sun and hence MySQL is coming up the tensions seems to heat up. Monty posts his open letter calling for help lobbying EC to stop Oracle from buying MySQL .
Posted by
peter @ 11:49 am ::
mysql ::
Posted by Baron Schwartz |
Now that O’Reilly has announced they’re going to have a MySQL conference independently of Sun/MySQL, we have decided not to proceed with plans for our own Performance Conference. We are participating in the O’Reilly conference, and we will do everything possible to make that a great success for everyone. See you there!
Posted by Ryan Lowe |
Peter took a look at Redis some time ago; and now, with the impending 1.2 release and a slew of new features, I thought it time to look again.
[read more...]
Posted by Aleksandr Kuzminsky |
Dear Community,
As of today release 1.0 is available.
In this release there are following changes:
Changelog:
- XtraBackup is ported to Windows. The .MSI package as well as .tar.gz is available for 32 bit platform
- Be more verbose on reporting scp errors
Fixed bugs:
The binary packages for RHEL4,5, Debian, FreeBSD, Windows as well as source code of the XtraBackup is available on http://www.percona.com/mysql/xtrabackup/1.0/. MacOS packages will come later.
Debian and RPM are available in Percona repository
The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki.
For general questions use our Pecona-discussions group, and for development question Percona-dev group.
For support, commercial and sponsorship inquiries contact Percona.
Posted by
Aleksandr Kuzminsky @ 11:26 pm ::
mysql ::
Posted by Baron Schwartz |
I can think of at least two major reasons why systems delay flushing changes to durable storage:
1. So they can do the work when it’s more convenient.
2. So they can do less work in total.
Let’s look at how the second property can be true.
[read more...]
Posted by
Baron Schwartz @ 10:44 pm ::
Innodb,
mysql ::
Posted by Vadim |
I posted about FusionIO couple times RAID vs SSD vs FusionIO and Testing FusionIO: strict_sync is too strict…. The problem was that FusionIO did not provide durability or results were too bad in strict mode, so I lost interest FusionIO for couple month. But I should express respect to FusionIO team, they did not ignore problem, and recently I was told that in last drivers FusionIO provides durability even without strict_mode (see http://www.mysqlperformanceblog.com/2009/06/15/testing-fusionio-strict_sync-is-too-strict/#comment-676717). While I do not fully understand how it works internally (FusionIO does not have RAM on board and takes memory from host, so there is always cache kept in OS memory), I also do not have reason to doubt ( but I will test that someone day …). So I decided to see what IO performance we can expect from FusionIO
in different modes.
[read more...]
Posted by peter |
I had an interesting case recently. The customer dealing with large MySQL data warehouse had the table which was had data merged into it with INSERT ON DUPLICATE KEY UPDATE statements. The performance was extremely slow. I turned out it is caused by hundreds of daily partitions created for this table. What is the most interesting (and surprising) not every statement is affected equally as you can see from the benchmarks above:
[read more...]
Posted by Devananda |
I recently had the chance to witness the effects of innodb_adaptive_flushing on the performance of InnoDB Plugin 1.0.5 in the wild, which Yasufumi wrote about previously here and here.
The server in question was Solaris 10 with 8 disk RAID10 and 2 32GB SSDs used for ZIL and L2ARC, 72G RAM and 40G buffer pool. We started it up with innodb_adaptive_flushing=OFF and innodb_doublewrite=OFF, then ramped up traffic and everything looked stable … but I noticed one troubling thing: ~2GB of uncheckpointed data.
mysql> SHOW INNODB STATUS\G
....
Database pages 2318457
Old database pages 855816
Modified db pages 457902
Log flushed up to 10026890404067
Last checkpoint at 10024612103454
....
We enabled innodb_adaptive_flushing just before 10am, which resulted in a few changes which were recorded by the Cacti MySQL Templates. The most important change for the client here is the recovery time — by enabling adaptive flushing, InnoDB purged modified data much more aggressively, resulting in very little unflushed changes, which translates to much faster crash recovery.
[read more...]
29-30 Jul
del.icio.us
digg