DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
GPU Accelerated Compositing in Chrome
Tom Wiltzius, Vangelis Kokkevis & the Chrome Graphics team updated May 2014 This code is changing due to Slimming Paint and thus there may be large changes in the future. Note also that some class names may have changed (e.g. RenderObject to LayoutObject, RenderLayer to PaintLayer). Summary This document provides background and details on the implementation of hardware-accelerated compositing in C
High-Performance, Garbage-Collector-Friendly Code - Build New Games
16 milliseconds is not a lot of time. Try eating a hotdog that fast – though I swear I’ve seen our dog go through a beef sausage in under 100 milliseconds. If you want your game to run at 60 frames per second, 16 milliseconds is all you have to get everything done: moving bullets around, creating new entities, drawing sprites, checking collisions, tracking and changing states, handling input and p
Optimizing JavaScript code - Make the Web Faster — Google Developers
OverviewPageSpeedInsightsBrowser ExtensionsChromeFirefoxRulesAvoid Bad RequestsAvoid CSS @importAvoid CSS ExpressionsMinimize document.writeCombine External CSSCombine External JavaScriptCombine Image Using CSS SpriteDefer Loading of JavaScriptDefer Parsing of JavaScriptEnable CompressionLeverage Browser CachingLeverage Proxy CachingMake Landing Page Redirects CacheableMinify CSSMinify HTMLMinigy
HTML5 Canvasパフォーマンスチューニング
以前、HTML5 Canvasで表現する打ち上げ花火として、Canvasを使った作品をご紹介しましたが、 PC版Webkitを除く全てのブラウザ（スマホブラウザは勿論、IE9など）で重いという課題がありました。 PCブラウザに限定すれば、ブラウザやハードウェアの進化ととも改善される問題ではありますが、 スマホ（に限らず携帯端末）は2年縛りで購入するユーザーが圧倒的に多く、1・2年前の機種（環境）を使用する状況が続くことが容易に想像できます。 スマホサイトやアプリ制作を手掛けたことのある方はご存知の通り、Android2.xは色々と不都合があるだけでなく パフォーマンス面でも十分に配慮して制作する必要があります。 （Android4.xではGPUアクセラレーションがサポートされ、期待出来るのですが世代交代は先の話） そこで、本エントリーではロジックを工夫することで得られたパフォーマンス改善の
2008-06-29
mysqlを利用していて、indexをちゃんと張っているのにパフォーマンスが出ない。 explain でも type = ref / key = INDEX 等が表示されているのにすごくクエリーが遅かったりする。 思い切って index を消したら逆にパフォーマンスが改善した! why? データ件数が数万件を越えたあたりからパフォーマンスが劇的に下がった。 と、悩んでいたりしませんか? そんな悩みのひとつの解決策になってくれるかもしれません。 テストは vmplayer 上の debian etch で行います。 ホスト環境 intel Q6600 メモリ2Gの WindowsXPです。 クエリーをキャッシュされないように、クエリキャッシュを 0 にします。 /etc/mysql/my.cnf query_cache_size = 0 #no cahce debug swapで遅くなると困
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://linux.mini13i.com/?MySQL%2F%BA%C7%C5%AC%B2%BD%2F%A5%B5%A1%BC%A5%D0%A5%D1%A5%E9%A5%E1%A5%BF
MySQL InnoDBストレージエンジンのチューニング（前編）
