タグ

performanceに関するnippondanjiのブックマーク (22)

  • MySQLトップレベルパフォーマンスチューニング講座開催

    Oracle, The World's Largest Enterprise Software Company Oracleは7月29日(米国時間)、「Tune MySQL for Top-Level Performance」において、4日間かけてMySQLサーバのパフォーマンスチューニングの方法を教えるトレーニングコースを開催することを伝えた。日では9月19日から東京にて開催される見通し。講師は日人によって日語で実施されるが、教材と実行環境は英語環境となる。対象バージョンはMySQL 5.5。 「MySQL Performance Tuning」では次の項目などについてトレーニングが実施される。 アーキテクチャの評価 ツールの意味や使い方 パフォーマンス目的でのデータベースのチューニング アプリケーションとSQL命令のチューニング サーバのチューニング ストレージエンジンの調査 ア

  • DSAS for Social での MySQL のボトルネックと今後の方針 : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の5日目です。 @methane による MySQL を骨までしゃぶるチューニングシリーズ (シリーズ名は今考えました)のまとめとして、現在の DSAS for Social の MySQL のリアルな性能値や直面しているボトルネックを赤裸々に公開 してしまいます。 innodb_io_capacity を増やそう 題に入る前に、まだ紹介してないけど1記事にするほどではなかった パラメータを紹介しておきます。 innodb_io_capacity は、 InnoDB に教えるヒントで、 Disk の IO/sec を指定します。 デフォルトでは、通常のHDDでも使えるように中途半端な値(バージョンによって100か200) になっているのですが、BBU付きバッファがあるRAIDカードを使うな

    DSAS for Social での MySQL のボトルネックと今後の方針 : DSAS開発者の部屋
  • SHOW FULL PROCESSLIST を使った MySQL のプロファイリング : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の3日目は、 引き続き MySQL 周りのチューニングノウハウとして、すぐに役立つ プロファイリング方法を紹介します。 DBサーバーの負荷が高い時、 slow_log を見て問題になっている重いクエリを 発見するのが一般的かもしれませんが、 slow_log に一切ログが残らないのに 負荷が高い状況や、むしろ負荷が高すぎてごく一般的でどう考えても遅いはずが ないクエリ ("SET NAMES utf8" や "BEGIN") すら slow_log に大量に乗ってしまう場合が あります。 slow_log 以外で問題になっているクエリを見つける方法として、 "SHOW FULL PROCESSLIST" コマンドがあります。これを数回〜数十回叩いてみて、 よく出ているクエリは、遅かったり量が

    SHOW FULL PROCESSLIST を使った MySQL のプロファイリング : DSAS開発者の部屋
  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • SAS SSD Festplatten für Server günstig kaufen | ServerShop24

    Seagate Nytro 3532 1.6TB 12G SAS Light Endurance (3DWPD) SSD 2.5" SFF Solid State Disk - XS1600LE70084

  • 2010年11月18日 "ミラクルパッチ"にLinusも大喜び!Linuxカーネルを高速化させた233行のコード | gihyo.jp

    Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び!Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判(というより非難)し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「⁠I'm also very happy」「⁠it is a _huge_ improvement」「⁠Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。

    2010年11月18日 "ミラクルパッチ"にLinusも大喜び!Linuxカーネルを高速化させた233行のコード | gihyo.jp
    nippondanji
    nippondanji 2010/11/19
    2.6.38待ちきれん・・・(;´Д`)ハァハァ
  • 知って得するInnoDBセカンダリインデックス活用術!

    InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が

    知って得するInnoDBセカンダリインデックス活用術!
    nippondanji
    nippondanji 2010/10/05
    セカンダリインデックスがCovering Indexになっている場合、主キーへアクセスしないので速いですよ。
  • 残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ!!

    なんて幸運なことなんだろう。 実は最近、個人的にサーバーマシンを借りるという機会があった。そのマシンに搭載されているCPUコア数は合計48である!大事なのでもう一度いう。日語でいう。48CPUコアだ!一昔前なら数千万円もしたスペックだろうが、最近は実にリーズナブルにお求めいただけるようである。(価格についてはふせておく。)このマシンには2.2GHzのOpteron 6174が4つ搭載されている。つまり、ひとつのパッケージに12個のコアが格納されているのだ。これはすごい。いや、むしろどうしてこうなった?!というべきか。そのようなマシンを目の前にすると時代はメニイコアに向かっているんだなあと実感せざるを得ない。 今後、CPUがどんどんメニイコアに向かう流れはさけれない。コアを増やさなければCPUの性能が(システム全体としての性能が)向上しないからだ。CPUの演算回路に対して半導体素子をたくさ

    残暑なんて吹き飛ばすぐらい熱いベンチマークをやろうぜ!!
    nippondanji
    nippondanji 2010/08/30
    昨夜更新しました。もっと計測したい!
  • Executing scripts on a remote machine - Marigan's Weblog

  • 【レポート】Rubyの実行環境、Linuxでベンチマークを取ったら… | エンタープライズ | マイコミジャーナル

    Ruby - A Programmer's Best Friend The Great Ruby Shootout (July 2010)にLinuxにおけるRuby実行環境のベンチマーク結果が掲載されている。ベンチマークが実施されたのはUbuntu 10.4 LTS x86_64版、Intel Core 2 Quad Q6600、8GBメモリの環境。Ruby Benchmark Suiteの提供しているベンチマークのうちいくつかを抜粋して実施したという。 公開されているデータはひとつの指針にすぎないが、それぞれのRuby実行環境の特徴がでており参考になる。比較に使われたRuby実行環境は次の8つ。 Ruby 1.8.7 p299 Ruby 1.9.1 p378 Ruby 1.9.2 RC2 IronRuby 1.0 (Mono 2.4.4) JRuby 1.5.1 (Java HotSp

    nippondanji
    nippondanji 2010/07/23
    LinuxとWindowsの違いが興味深いな。
  • MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)

    バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5

    MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
  • 貧乏だってプロファイリングは出来る!! - poor man's profiler

    従来より、プロファイリングのためのソフトウェアと言えば高価なものが中心であった。もっと安く、お金を掛けずに、簡単に、早くプログラムのボトルネックを探し出す方法はないのか?!ということで編み出されたプロファイリングテクノロジーがある。その名も、「poor man's profiler」だ。 poor man's profilerの全容は、次のページで知ることが出来る。 Poor Man's Profiler http://poormansprofiler.org/ poor man's profilerは、現Facebook(元MySQL ABのサポートエンジニア)のDomas Mituzasによって開発されたプロファイリングテクノロジーである。以下が、その全ソースコードである。 #!/bin/bash nsamples=1 sleeptime=0 pid=$(pidof mysqld) f

    貧乏だってプロファイリングは出来る!! - poor man's profiler
  • Oracle

    のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。

  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。

  • YappoLogs: トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか

    トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか 元ネタはMySQL のおまとめINSERTはどれくらい速いか - bonar noteです。 トランザクションでまとめてInsertしてからcommitしたほうが速くなるので、元ネタのベンチマークをベースにして試してみました。 環境は macports で入れた mysql 5.1.44 です。 まぁnormalからbulk(100)くらいの差は出てなくても、トランザクション使ってまとめてコミットしても多少速くなっとりますね。 normal と txn の差よりも bulk(100) と bulk(100)_txn の差が小さいのは、 bulk insert で最初から効率的になってるぶん差が少なくなってるという感じでしょうか。 コードは以下の通り。 Posted by Yappo at 2010年03月09日

  • 漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。

    InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い(テーブルの行数を保持してる)のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ

    漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
    nippondanji
    nippondanji 2010/03/09
    id:u1tnk テーブルモニタの出力を見て下さい。主キーのleaf pagesとセカンダリインデックスのleaf pagesは大幅な差があります。それが速度差に表れるのです。/id:aki77 全て5.1で動作確認していますが、たぶん5.0でも通用します。
  • 漢(オトコ)のコンピュータ道: D言語基礎文法最速マスター(DTraceのほう)

    そうそう、もう一つとっておきのネタがありました。ってことで、MySQL管理者最速マスターを書いたばかりだけど、さらに調子に乗ってお次はDTraceで使われているD言語について最速マスターネタを書いてみよう。こっちのD言語と紛らわしいが、英語にするとDTraceじゃない方は「D Programing Language」でDTraceの方は「D Language」なので、両者を区別出来る。このエントリでは「D言語」という記述が出てきたらDTraceの方を表すのであしからず。 DTraceの概念DTraceは、システムのあらゆる場所を対象にして動作を追跡するための仕組みで、トラブルシューティングやプロファイリングに利用出来る。元々はSolaris 10向けに開発された機能だが、その後FreeBSDやMac OS Xへと移植された。DTraceはメモリ上にロードされた実行プログラムの内容を直接「動

    漢(オトコ)のコンピュータ道: D言語基礎文法最速マスター(DTraceのほう)
  • SystemTapでMySQLのDisk I/Oを分析する - SH2の日記

    実験エントリです。 動機 OracleのStatspack/AWRで取れるファイル単位のDisk I/O情報を、MySQLでも採取したい。これは次に示すようなデータです。 File IO Stats DB/Inst: ORA112/ORA112 Snaps: 6-7 ->Mx Rd Bkt: Max bucket time for single block read ->ordered by Tablespace, File Tablespace Filename ------------------------ ---------------------------------------------------- Av Mx Av Av Rd Rd Av Av Buffer BufWt Reads Reads/s (ms) Bkt Blks/Rd Writes Writes/s Wai

    SystemTapでMySQLのDisk I/Oを分析する - SH2の日記
    nippondanji
    nippondanji 2010/01/20
    ナイスエントリです!! 一方ポスグレでは勉強会するみたいです。 http://bit.ly/5uBlOY
  • MySQL InnoDBだけで全文検索 - SH2の日記

    実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp:悟空、秘剣「転置インデックス」を手に入れる |Googleはなぜ的確に探せるのか? [を] 転置インデックスによる検索システムを作ってみよう! 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足?! うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy

    MySQL InnoDBだけで全文検索 - SH2の日記
  • シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場

    システム全体で必要な書き込みパフォーマンスが、RDBMSノード1基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ/マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが2倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ/マルチスレーブ構成では16台と、一気にコス

    シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
    nippondanji
    nippondanji 2009/08/10
    独り言を残して去る。