アカウント名:
パスワード:
最近ぶったまげたのは google-perftools [google.com] の google malloc です。
Linux で MySQL を動かすとクライアントが増えたら性能が低下する(FreeBSD のトピック) [srad.jp]という話がありましたが、実は足を引っ張っているのは glibc の malloc で、google malloc を使うと性能が低下しない [ozlabs.org]のだそうです。
Google
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
Googleのサーバーシェア (スコア:5, 参考になる)
Yahoo!はFreeBSDにaccept_filterなどの形で還元していますけれど、Googleも何かそういう活動をしていたのかしらん。ちなみに、accept_filterというのは特定のメッセージ列がカーネル内でバッファリングされるまでacceptシステムコールの返事をするのを遅らせることで、コンテキストスイッチを何回もすることによるオーバーヘッドを削減するという機構です。メッセージ全てがバッファリングされていると、read一発で読めますからね。
google malloc (スコア:5, 興味深い)
最近ぶったまげたのは google-perftools [google.com] の google malloc です。
Linux で MySQL を動かすとクライアントが増えたら性能が低下する(FreeBSD のトピック) [srad.jp]という話がありましたが、実は足を引っ張っているのは glibc の malloc で、google malloc を使うと性能が低下しない [ozlabs.org]のだそうです。
Google
jemalloc (スコア:5, 参考になる)
このjemallocはマルチスレッドを考慮した実装になっており、マルチスレッド下での性能が大幅に向上したらしいです。BSDCanのスライドをざっと読んだ感じだと、jemallocはメモリー割り当てのためのプール(arena)を複数持っており、そのプール毎にロックをするみたいですね。それで、各スレッドはスレッドローカルなストレージ(TLS)を参照することでどのプールを使うのかを知るようです。プールにはメモリーの塊(chunk)があって、要求されたメモリーのサイズによってはそれそのものを使ったりrunsという小さいまとまりに分割したりします。ここら辺はファイルシステムにおけるblockとfragmentの関係に似てますね。
参考までに:
http://journal.mycom.co.jp/articles/2006/05/15/bsd4/ [mycom.co.jp]
http://www.bsdcan.org/2006/papers/jemalloc.pdf [bsdcan.org]
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf [freebsd.org]