タグ

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

  • nginxのチューニング方法 パフォーマンスを最適化

    プロセス関連のチューニング worker_connectionsとworker_rlimit_nofile worker_connectionsはworkerプロセスで開ける同時接続最大数です。 高スペックマシンでは要上方調整。 worker_connections 2048;クライアントの最大接続数➗worker_processes数(≒ vCPU数)worker_limit_nofile 8192;最大オープンファイル数➗worker_processes数(≒ vCPU数) worker_connectionsはworker毎のclientの最大接続数を表しています。 defaultは512に設定されていると思います。 リバースプロキシを利用中は1アクセスでworker_connectionが2つ消費されるので通常の2倍に設定する。 クライアント – nginx(1接続分) 通常の場合

  • 【Nginx】ちょっと時間を掛けてチューニングしてみた。

    Webサーバやリバースプロキシとしてよく使われるNginx。今回は、チューニングに焦点をあて、解説しました。アプリの修正をしなくとも、パフォーマンスが改善できるので是非ご参考あれ。 (自分の備忘も兼ねてたりします。) ※ページはプロモーションが含まれています。 設定の紹介 チューニングした/etc/nginx/nginx.confがこちら。/etc/nginx/conf.d/default.confを別で読み込んで、デフォルトページを表示するようになっています。 user nginx; worker_processes auto; worker_rlimit_nofile 100000; events { worker_connections 2048; multi_accept on; use epoll; } error_log /var/log/nginx/error.log wa

    【Nginx】ちょっと時間を掛けてチューニングしてみた。
  • MySQLのインデックスの使い方 - Qiita

    SQLのパフォーマンスチューニングで考えるべきことの一つに、インデックスがある。インデックス無しで作業をしてみて、インデックスの重要性を理解しましょう。 ディスクからのデータの読み込み ディスク上ではファイルという概念はない。ブロックという概念がある。普段なら一つのファイルがいくつかのブロックを使用している。ブロックの順位が決まっていて、ファイルが分割された後に各部分がそれぞれのブロックに保存されます。 ファイルを読み込んでる時に、各ブロックのデータを取得して組み立てる。フラグメンテーションによってそのブロックがディスクの色んな位置に置いてある可能性があるので、それによって読み込みが遅くなりかねない。 ファイルの中で何かを探している時に、全てのブロックからデータを取得する必要が出てくる。ファイルが大きければ大きいほどブロックの数が増えて検索がすごく遅くなる。 MySQLでのデータ検索 My

    MySQLのインデックスの使い方 - Qiita
  • 「ざっくり分かる WordPress サイトのチューニング」を WordCamp 2016 で発表してきました。 - Shin x Blog

    2016/07/09、10 に大阪大学 豊中キャンパスで開催された WordCamp Kansai 2016 にて、WordPress サイトのチューニングについて発表しました。 https://twitter.com/digitalcube/status/751693759121731584 発表資料 今回は、PHPWordPressエンジニアでなくても何か役立ててもらえるようにチューニングの具体的な手法というよりは、実際に手を動かすエンジニアと意思疎通がスムーズになるように基的な考え方をメインにお話しました。 「推測するな、計測せよ」という格言があるとおり、チューニングにおいても、まず大事なのは「計測する」ということです。計測せずにやみくもにチューニングを行っているケースを見聞きするので、ここからはじめる内容にしました。 後半は、キャッシュを中心に紹介したのですが、最後の Var

    「ざっくり分かる WordPress サイトのチューニング」を WordCamp 2016 で発表してきました。 - Shin x Blog
  • パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

    MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日語に訳すと濃度とか訳されるが、要は値の種類(分散具合)のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

    パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
  • PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと

    先日別のチームから、 「PHPで作成したWebアプリの速度が遅いので助けてくれー」 という相談を受けた。 対応したものの、結構時間がかかって面倒だったので、 今後こういった問題が起こった時に使えるよう、チェックリストをまとめてやった。 基的な内容だけど、 このチェックリストの内容をやってみて、それでもダメなら相談しなさい、 と伝えておくことで相談を減らすフィルタとして働いてくれるはずだ。 PHPプロジェクトに限らず、バックエンドでデータベースを使用している Webアプリのプロジェクトなら試す価値のあるものが多いはず。 調査や対応方法の手軽さ順で並べるとこんな感じ: Webブラウザのデベロッパーツールでレスポンスを計測する Webサーバ(Apache)のリクエスト時間をログに出力する ログ解析ツールでURL毎の付随リクエスト数を確認する データベースのスロークエリログを出力する プロファイ

    PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと
  • MySQLのEXPLAINを徹底解説!!

    以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

    MySQLのEXPLAINを徹底解説!!
  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

  • カーソルのループでINSERT100万とSELECT INSERT100万の速度比較してみた - kagamihogeの日記

    やるまえから結果が見えてる試みではあるんですが。最近SQLを再勉強するにあたり、SQLてのは、手続き的にループ回すのに比べて集合to集合の演算の方が圧倒的に早い、というのを改めて認識した。なので、このエントリはそれを実感するのが目的です。 やったこと 環境はOracle 11g XEを使用。 FROM側とTO側のデータを入れるテーブルを作る。FROM側には100万件レコードを入れておく。 CREATE TABLE FROM_A_TBL (CLM VARCHAR2(16)); CREATE TABLE TO_A_TBL (CLM VARCHAR2(16)); FROMテーブルをカーソルでループしながらTOテーブルに1件ずつINSERTするPL/SQLを作る。 create or replace PROCEDURE TO_WITH_CURSOR IS CURSOR C1 IS SELECT C

    カーソルのループでINSERT100万とSELECT INSERT100万の速度比較してみた - kagamihogeの日記
  • ダイレクト・パス・インサート - オラクル・Oracleをマスターするための基本と仕組み

    ダイレクト・パス・インサート (ダイレクト・ロード・インサート) ダイレクト・パス・インサートとは、データベースバッファを経由せずデータファイルへ 直接データを落とし込むという点から、ある特定条件下で非常に優れた処理方法である。 データベースのバッファ処理を経由しないことで高速に処理でき、バッファから他のキャッシュを追い出すことによるキャッシュヒット率の低下を防ぐこともできる。 高速に大量データをインサートさせるための手法 ダイレクト・パス・インサートによる高速のインサート処理にはトレードオフがあるが脅威的な速さを誇る。 数百万件オーダのデータの投入するのに数分とかからない(レコードサイズ、スペックに左右はされる) 通常のパスのローディングに比べて 数分の1 程度の時間で投入できる。 NOLOGGING 状態の場合 REDO ログが出力されない。(高速にはなる一方でフルバックアップするまで

  • 更新/挿入/削除のSQLを高速化する3つの技とは?(2/3) ― @IT

    ダイレクトロードインサートを利用する 別表から大量データをINSERTする場合、APPENDヒントを利用することで、通常のINSERT処理ではなく、ダイレクトロードインサート処理を実行できます。このダイレクトロードインサート処理では、バッファ・キャッシュを経由せずにデータをINSERTすることができ、また最低限のREDO情報のみが生成されるため、通常のINSERT処理よりも大きくパフォーマンスを改善できる可能性があります。

    更新/挿入/削除のSQLを高速化する3つの技とは?(2/3) ― @IT
  • [ThinkIT] 第1回:チューニングの基準 (1/4)

    データベースのチューニングという言葉からどのようなことを想像しますか。表の設計の見直しやSQL記述を探ること、バッファプールの調整などと主にデータベース自体の調整であったりするかと思います。 しかしこうしたチューニング作業を行ったにもかかわらず、パフォーマンスがあまり変化しなかった、明確に問題が解決されなかったなどといったといった経験はないでしょうか。またより詳細な調査の結果、実はOSの設定やデバイスドライバのバージョンに原因があった、あるいはハードウェアの選択に問題点があったということも聞いたことがあるかと思います。 もちろんデータベース自体のチューニングは欠かせないものですが、なんらかの問題が起こっている場合、システム全体を考慮しなければならない状況に陥ることがあります。 一口にパフォーマンスをチューニングするといっても、ハードウェアを含めたシステム全体を考えると、考慮すべき項目は多い

  • なぜMySQLのサブクエリは遅いのか。

    よくMySQLはサブクエリが弱いと言われるが、これは当だろうか?半分は当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

    なぜMySQLのサブクエリは遅いのか。
  • Webプログラマーのメモ帳 - MySQL(管理者向け)/インストール/my.cnfサンプル

    MySQL(管理者向け)/インストール/my.cnfサンプル † MySQLをインストールすると、メモリー容量に対応したmy.cnfのサンプルが付属しています。それらの内容を提示します。(但し、説明コメントは削除しています。) ↑ my-small.cnf † メモリー64MB以下のサーバー向け。通常使用することはないでしょう。 [client] #password = your_password port = 3306 socket = /tmp/mysql.sock [mysqld] port = 3306 socket = /tmp/mysql.sock skip-locking key_buffer = 16K max_allowed_packet = 1M table_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K

  • facebookでのAPCの設定 - おぎろぐはてブロ

    php|tek 2007で発表された、facebookの中の人のAPCの設定についての話です。軽く中身を説明します。 apc@facebook (PDF) apc@facebook (PDF) 2007/09/21 追記 サイトの構成が変わって、スライドがデッドリンクになっていたため差し替えました。また、今月開催されたphp|works 2007での講演もアップされています。こちらのが読みやすくなっている部分があるので、こちらを参照したほうがいいかも。 apc@facebook (PDF) in phpworks2007 http://tekrat.com/talks 内容 LAMP構成で、そしてAPCを使ってます Facebookのprofile.phpの表示を例にあげると、ノーマルのPHPに比較して、FacebookのチューンしたAPC設定では秒間リクエスト数が12倍に! ちょ、、それ

    facebookでのAPCの設定 - おぎろぐはてブロ
  • 過負荷をかわす Apache の設定 : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ+ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基設定 まずは基的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp

    過負荷をかわす Apache の設定 : DSAS開発者の部屋
  • PHPプログラムを解析して何処が重いか?がブラウザ上で簡単に分かる「XHProf」:phpspot開発日誌

    PHPプログラムを解析して何処が重いか?がブラウザ上で簡単に分かる「XHProf」 2009年03月25日- XHProf Documentation (Draft) PHPプログラムを解析して何処が重いか?がブラウザ上で簡単に分かる「XHProf」。 通常、PHPでのプロファイリングというと、Xdebugでファイルを吐き出して、WinCacheGrindやKCacheGrindで読み込むというのが定番です。 ですが、この方法だと、ファイルを吐き出したファイルをGETして、ソフトに読み込ませる、というちょっと面倒な手順が必要でした。 XHProf を使えば、ブラウザ上で、プロファイリングが出来るみたいです。 XHProfの特徴 まず、セグメントごとの実行時間やメモリ利用の状況なんかがブラウザで見れます。 プログラムの構造を把握するのにも使えます。 プロファイリングの階層表示 2つのプロファ

  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • MySQLのメモリ設定を追求してみよう – OpenGroove

    (2015年1月追記:これは現時点で約5年前に書いた記事です。各種パラメータは名称や仕様が変更されている可能性があるため、最新の情報を参考にしてください) MySQLのメモリの話を考えていたら何が何だか分からなくなってきたので、my.cnfでの設定に絡めてまとめてみようと思う。そもそも、MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。 max_connections x [スレッド領域用メモリ合計値] に、以下をプラス。 [グローバル領域用メモリ合計値] DB専用サーバの場合だとこの値をマシン搭載メモリの8〜9割くらいにする、と想定するのがひとつの指針となるようだ。しかし32bitLinux OSの場合は2〜3GBまでの制限があるため、搭載メモリがそれ以上あったとし

  • MySQLやPHPのパフォーマンスを向上させる方法のメモ。 » とりあえず9JP

    MySQLPHPのパフォーマンスを向上させる方法のメモ。 色々な設定があるとは思いますが、ここでは個人的に効果を顕著に感じたMySQLのクエリキャッシュとAPCについて書いています。 当はPHPやらMySQLそれぞれでベンチ取った方が良いとは思うのですが、この記事では、WordPressを設置して、そのインデックスページに対するApacheBenchのRequests per second(一秒間に処理されたリクエスト数)のみを見て、その結果で比較しています。 ※ApacheBenchはローカルではなく外部のサーバからという微妙な環境で、リクエスト数100、同時リクエスト数10、試行回数はそれぞれ1回という微妙な値でやってます。 まずは、全く未設定な状態での、Requests per second。 実行したコマンドは以下。 ab -n 100 -c 10 テストしたいURI Requ