データベースパフォーマンスチューニングのための10の秘訣 - ハッカーになれなかった僕らへ
先日公開された以下の記事がデータベースのパフォーマンスチューニングについて非常に示唆に富む内容だったので、新型コロナで持て余した時間を使って、個人的な趣味でざっくり意訳してみました！ 誤訳や日本語として変なところが多々あるかと思いますので適宜修正していきますが、正しい内容は原文を参照してくださいねー。 基本的にOracleデータベースやExadataに関する内容となっていますが、データベースパフォーマンスチューニングのための10の秘訣（チップス）です。 1. パフォーマンス測定の主要なアプリケーションのメトリックを特定する パフォーマンスを測定するときは、アプリケーションの稼働状況を反映したりエンドユーザーの体感を代理するような主要なアプリケーションのメトリックを特定します。このメトリックはデータベース外部のものであるべきです。例えば、秒間のオーダー処理数やバッチジョブの経過時間などです。
TPCベンチマーク基礎講座
先週，私はMicrosoftが出した新しいTPC-Cベンチマークの世界記録を称賛した（該当記事）。しかし，多くの読者が「Transaction Processing Performance Council」（TPC）が何であるか，またそのベンチマークが何を意味するかを知らないようだ。 例えば，ある読者は「なぜTPCという組織は，商業的にライセンス設定されたOSとデータベースだけをテストするのか？見たところ，その非営利団体は，入手できるものは何でもベンチマークしているようだ。例えば，なぜ彼らはLinuxプラットホームのpostreqsqlやmysqlをテストしないのか？」。 その質問への単純な答えは，告訴される恐れがあるからだ。もう少し詳しく回答しよう。まず，TPCについて理解の助けになるように，その組織についてバックグラウンドをざっと説明したほうがいいだろう。 TPCの設立趣意書には「TP
「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋
「推測するな計測せよ」という格言がよく知られています。この格言は（ISUCONに優勝した）Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が
Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
MySQLのperformance_schemaをフルパワーにするとどんな情報が見られるのか
日々の覚書: MySQLのperformance_schemaでどれくらいの情報が見られるのか の続き。 * events_stages_summary_by_account_by_event_name * events_stages_summary_by_host_by_event_name * events_stages_summary_by_thread_by_event_name * events_stages_summary_by_user_by_event_name * events_stages_summary_global_by_event_name mysql> SELECT * FROM events_stages_summary_by_account_by_event_name WHERE count_star <> 0 ORDER BY sum_timer_wait
MySQLのperformance_schemaでどれくらいの情報が見られるのか
MySQL :: MySQL 5.6 Reference Manual :: 22 MySQL Performance Schema 5.6以降「よくなったよ！」「確かにね！ でもメモリー」「」みたいな感じで扱われて結局まだONにしているインスタンスの少ないPerformance Schemaなのでちょっと練習中。 tpcc-mysqlとかでやると割と綺麗なクエリーをしているので面白い情報が出ない(ibdata1のfsyncに時間がかかってることなんて知ってるよ！ って感じになる)ので、isucon2のアプリで試してみることにしますた。モリスさん++ livedoor Techブログ : 自家製 #isucon2 のつくりかた MySQLは5.6がいいのでMySQL :: Download MySQL Yum Repositoryで入れる。 $ sudo yum localinstall
EXISTSとSQLの高速化について - 猫好きモバイルアプリケーション開発者記録
SQL高速化についてはいろんなサイトで取り上げられているので 今更取り上げる必要はないかと思っていましたが、 ふと最近仕事をしている中でハマっている人が多いポイントであると感じたため 改めて書いてみることにしました。 EXISTSが速いという誤解 EXISTSについて書かれたサイトを見ると、 「速い」というような記述を見かけることが多いかと思います。 しかし、これはあくまでサブクエリを組んだ場合に、INやイコールを使って比較するときと比べて速い場合が多いというだけであり、 EXISTSが速いというわけでは決してありません。 ハッキリ言ってしまうと、EXISTSを使うクエリは基本的に遅いです。 これは正確に言うと、EXISTSを利用するケースにおいて相関サブクエリが使われていることが原因で遅くなっています。 相関サブクエリとはどういうものか、以下にメンバー情報を格納した MEMBER テーブ
雑なMySQLパフォーマンスチューニング
【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
ネットワーク機器の処理性能について
ネットワーク機器の処理性能について スイッチなどのLAN機器のカタログを見ると バックプレーン 8.8Gbps だとか スイッチング処理能力 3.6Mpps なんて書かれていたりします。 そもそもここで書かれている数字がどれほどの能力を示しているのかって分かりますか？ 普通にスイッチを使用しているのであれば特に気にしなくても使えてしまうので意外に気にしていない方もいるようなのですが、いざというときに重要だったりします。 今回はネットワーク機器の処理能力について説明していきます。 バックプレーン バックプレーン容量とはスイッチ全体での1秒間で処理できるデータ量を表しています。 メーカによっては「スイッチングファブリック」だとか「スイッチング容量」なんていう場合もあります。 bps(Bit Per Second)の単位で表されます。 バックプレーンとは、本来スイッチ内部のデータ用バスのことで、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kintoneの大量レコード取得を高速化 – cybozu developer network
「Oracle Database + Java + Linux」�環境における性能問題の調査手法 �～ミッションクリティカルシステムの現場から～ Part.1