タグ

チューニングに関するrephisのブックマーク (8)

  • オレ的EXPLAIN技を語っちゃうゾ - Qiita

    メリークリスマス 記事はPostgreSQL Advent Calendar 2021の25日目です。今年も面白い記事がたくさん揃いましたね!!! さて、みなさん今年のPostgreSQLライフはどんな感じでしたでしょうか? 私はというと、なんだかチューニングばっかりやってました。1案件でいろいろお手伝いすることはまあまああったのですが、複数から次々チューニングの相談をもらって、歴代継承者の個性を発現したデクくんのごとく駆け回ったのが今年のハイライトです。 (この綱渡り感、、、伝われ!!!) 俺たちは雰囲気でチューニングしている 今回上手くいったけど、あの時たまたまひらめいた1案をぶつけてみたら効果でたのであって、次善の策なんてなかったけど??って毎回思ってるから、雰囲気でやっていると思う、マジで。コミュニティのノリだと笑いが起きていいんですけど、少しでも勝率を上げるために、若手の前でド

    オレ的EXPLAIN技を語っちゃうゾ - Qiita
  • よくあるオンプレOracleからRDSに移行したDBAの反省文 - ASMのきもち

    この記事は JPOUG Advent Calendar 2021 - Adventar 17日目の記事です。 昨日はShinodaさんの「Oracle Database から PostgreSQL への接続を試す - Qiita」でしたね。 いやーOracle Database Gateway for ODBC全然使ったことがなかったので、これはぜひやってみよ…あれ、RDSでできるの?明日AWSサポートに早速連絡してみよう… 最近ブログを書く頻度がアドベントカレンダー以外書く頻度がない感じになってきております…コレハ、マズイ、ゾ!!笑 さて弱気な内容はおいておいて…ここ最近、ろくに活動もできなかったのはこれをやっていたからなのです。 そうよくある、(꜆꜄•ω•)꜆꜄꜆オンプレOracleからRDSに移行した話。 今更感あるのですが、私と同じミスを減らすきっかけになれば。と思い、書いてみます

    よくあるオンプレOracleからRDSに移行したDBAの反省文 - ASMのきもち
  • はてなダイアリーの高速化の裏側 - stanaka's blog

    先週、ダイアリーがリニューアルされました。今回のリニューアルはダイアリーの応答時間の改善が目玉の一つとなっており、そのために1週間リリースを延ばし、改善の時間を確保していました。今回は、この改善について記しておきます。 はてなでは「推測するな、計測せよ」の原則にしたがって、ダイアリーのユーザーページの全アクセスの応答時間を解析し、ヒストグラムを作っています。また、特定の閾値(1秒、2秒とか)以内に何%のリクエストを返却できている割合をグラフ化しています。 このグラフを見ると、応答時間時間は時間とともに劣化することが一目瞭然です。実際に今年初めの値と比較すると10%〜20%程度の悪化が確認されました。あとは、これをひたすら改善していくのみです。今回実施した主な対策は、以下の通りです。 ネットワーク パケットロスが発生しているようなトラフィック経路上のボトルネックの解消(L2スイッチの置換、物

    はてなダイアリーの高速化の裏側 - stanaka's blog
  • Rubyでフィボナッチ数列の演算が遅い問題についてのその後の考察。@解決編 - CanI's diary

    @Python編?何それおいしいの?(ぁ ついに解決! ずっと、ここ一連のエントリで、Rubyの多倍長演算の遅さについて嘆いてきたわけですが、何度かささださんからアドバイスをいただきつつも、ついにボトルネックを発見し、解消することができました。 ボトルネックの正体。 過去のエントリでは、Pythonとほとんど同じ処理だよ?おかしいね?とか言ってたわけですが、かなり煮詰まってきて、静的にコードを眺めてるだけじゃどうにもいかなくなったので、実行時のプロファイルをとってみることにしました。 使用したプロファイラはgprofです。 Ubuntu 9.04で、 make CFLAGS=-pg とかして、(cygwinでは-pgオプションつけるとmake通らなかった><) 適当に、スクリプトを実行、 ./ruby hoge.rb その後、 gprof ruby gmon.out とかしてあげると、Cレ

    Rubyでフィボナッチ数列の演算が遅い問題についてのその後の考察。@解決編 - CanI's diary
  • データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ

    データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 OracleSQLServer、MySQLと色々なDBのチューニングをしてきましたが、

    データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
  • 発表資料 RubyのGC改善による私のエコライフ - I am Cruby!

    rubykaigi2009RubyのGC改善による私のエコライフView more documents from authorNari.  動画TODO: ニコニコ?に載ったらココに貼りますね.  感想こんなにホームだったのは初めてです.というのも「GCに興味ある人」っていったら100人くらいいる人がみんな手を挙げたんだから(T-T) コミッタの方々が前にいらっしゃって,とても緊張した.たぶん今までのプレゼンで一番の緊張だった気がする.ドキドキ. GCの話.手を挙げて貰ったこれも80人くらい買うよと言って貰えた.ちょ!「これが全員なんじゃない?」というツッコミがあって笑ってしまった. なぜか,45分くらい時間があって,30分の資料しか作っていなかったので,やっぱり15分時間が余った.「質問タイムナウ」となって,いっぱい質問をいただく.ありがとうございます.この質問タイムが予想以上に盛り上

  • Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か

    GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは?(0.1秒未満ぐらいを目指したい?) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu

    Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
  • MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記

    ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?

    MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
  • 1