サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
dom.as
For years it was very easy to defend InnoDB’s advantage over competition – covering index reads were saving I/O operations and CPU everywhere, table space and I/O management allowed to focus on database and not on file systems or virtual memory behaviors, and for past few years InnoDB compression was the way to have highly efficient OLTP (or in our case – SGTP – Social Graph Transaction Processing
There is much more to write about all the work we do at Facebook with memory management efficiency on our systems, but there was this one detour investigation in the middle of 2012 that I had to revisit recently courtesy of Wikipedia. There are lots of factors that make machines page out memory segments into disk, thus slowing everything down and locking software up – from file system cache pressu
Warning: this is a mixture of historical content, biases, stupid marketing and unknown/proprietary/closed source technologies. Proceed with caution. NuoDB marketing was sending out this message, encouraging me to blog (they were looking for bloggers too): And while Facebook sharded MySQL 4000 times, even they call it a “fate worse than death.” We’ve seen this phrase before and it did not come from
I don’t like stupid benchmarks, as they waste my time. I don’t like stupid marketing, as it wastes my time too. Sometimes I succumb to those things, and now in return I want to waste your time a bit. So, this MemSQL thing, written by some smart guys has been making rounds in press and technical community. Centerpiece of all the communication was: “MemSQL, the database they have developed over the
MySQL is needlessly slow at accepting new connections. People usually work around that by having various sorts of connection pools, but there’s always a scale at which connection pools are not feasible. Sometimes connection avalanches come unexpected, and even if MySQL would have no trouble dealing with queries, it will have problems letting clients in. Something has to be done about it. Lots of t
For the impatient ones, or ones that prefer code to narrative, go here. This is long overdue anyway, and Yoshinori already beat me, hehe… Our database environment is quite busy – there’re millions of row changes a second, millions of I/O operations a second and impact of that can be felt at each shard. Especially, as we also have to replicate to other datacenters, single threaded replication on My
There are multiple metrics that are really useful for read workload analysis, that should all be tracked and looked at in performance-critical environments. The most commonly used is of course Questions (or ‘Queries’, ‘COM_Select’) – this is probably primary finger-pointing metric that can be used in communication with different departments (“why did your qps go up by 30%?”) – it doesn’t always re
More of information about how we handle database stuff can be found in some of my talks. Lately I hear people questioning database software choices we made at Wikipedia, and I’d like to point out, that… Wikipedia database infrastructure needs are remarkably boring. We have worked a lot on having majority of site workload handled by edge HTTP caches, and some of most database intensive code (our pa
For your convenience, a short phrase book, starting with explanation of process states where MySQL is mostly working to look up data from tables: “Sending data” – reading data from tables (or looking it up) “Copying to tmp table” – reading data from tables (or looking it up) “Copying to tmp table on disk” – query needs a rewrite “statistics” – looking up data from tables “Sorting result” – reading
My favorite Linux tool in DB work is ‘iostat -x’ (and I really really want to see whenever I’m doing any kind of performance analysis), yet I had to learn its limitations and properties. For example, I took 1s snapshot from a slightly overloaded 16-disk database box: avg-cpu: %user %nice %system %iowait %steal %idle 8.12 0.00 2.57 21.65 0.00 67.66 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s \ sda
このページを最初にブックマークしてみませんか?
『domas mituzas』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く