Asher, This is awesome! Thank you for your hard, careful work and dedication in taking this huge first step in moving to MariaDB!
--peter On Tue, Dec 11, 2012 at 4:10 PM, Asher Feldman <[email protected]>wrote: > Hi, > > This afternoon, I migrated one of the main production English Wikipedia > slaves, db59, to MariaDB 5.5.28. We've previously been testing 5.5.27 on > the primary research slave, and I've been testing the current build for the > last few days on a slave in eqiad. All has looked good, and I spent the > last few days adapting our monitoring and metrics collection tools to the > new version, and building binary packages that meet our needs. > > A main gotcha in major version upgrades is performance regressions due to > changes in query plans. I've seen no sign of this, and my initial > assessment is that performance for our workload is on par with or slightly > improved over the 5.1 facebook patchset. > > Taking the times of 100% of all queries over regular sample windows, the > average query time across all enwiki slave queries is about 8% faster with > MariaDB vs. our production build of 5.1-fb. Some queries types are 10-15% > faster, some are 3% slower, and nothing looks aberrant beyond those > bounds. Overall throughput as measured by qps has generally been improved > by 2-10%. I wouldn't draw any conclusions from this data yet, more is > needed to filter out noise, but it's positive. > > MariaDB has some nice performance improvements that our workload doesn't > really hit (better query optimization and index usage during joins, much > better sub query support) but there are also some things, such as full > utilization of the primary key embedded on the right of every secondary > index that we can take advantage of (and improve our schema around) once > prod is fully upgraded, hopefully over the next 1-2 months. > > The main goal of migrating to MariaDB is not performance driven. More so, > I think it's in WMF's and the open source communities interest to coalesce > around the MariaDB Foundation as the best route to ensuring a truly open > and well supported future for mysql derived database technology. > Performance gains along the way are icing on the cake. > > -Asher > > > _______________________________________________ > Ops mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/ops > > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
