タグ

パフォーマンスに関するobiwanのブックマーク (11)

  • MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita

    ※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「

    MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
  • Apache の MaxClients の適正値 - Qiita

    MaxClients / MaxRequestWorkers に関する言及 Apache の MaxClients / MaxRequestWorkers の適正値に関する言及を時系列にまとめた。敬称略。 他に重要な言及をしているWebページがあればお知らせください。 2002/07/23 一志達也(TIS株式会社) ApacheによるWebサーバ構築(16):Apacheパフォーマンス・チューニングの実践 (2/2) - @IT プロセス数を制限するためのディレクティブが「MaxClients」である。このディレクティブには、同時に接続できるクライアント(厳密にはセッション)の数を指定する。 ...略... abで同時接続数を上げながら、CPUやメモリの状態、abが示すパフォーマンスの推移を調査する。それに伴ってMaxClientsの値も上げながら、飽和点を探る作業を行うのだ。 リファレ

    Apache の MaxClients の適正値 - Qiita
  • Apacheチューニングのためのメモリ使用量計算 - 仙台の山奥で自転車に乗ったり転んだり

    「/proc/(pid)/status」のメモリサイズからメモリ消費量をリストアップするスクリプトを準備した。 「サーバ/インフラを支える技術」に載っている、id:naoyaさんの共有しているメモリのサイズを計算するスクリプトとあわせて、エクセルに落とし込んでごにょごにょと計測してみる。 http://d.hatena.ne.jp/naoya/20080212/1202830671 http://archive.linux.or.jp/JM/html/LDP_man-pages/man5/proc.5.html [www]~ $ cat memory_size.sh #!/bin/sh GREP="/bin/grep" AWK="/bin/awk" PRINTF="/usr/bin/printf" if [ $# -lt 1 ]; then echo "usage: ${0} [pid .

    Apacheチューニングのためのメモリ使用量計算 - 仙台の山奥で自転車に乗ったり転んだり
  • これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編)|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

    これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編) こんにちは nob です。 前編 これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編) の記事から1年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を(システム編)としてお届けいたします! 今回の(システム編)で紹介するツボは 4 つです。(クエリ編)のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 (ツボ1)Load Average < (1 + (cpu数-1)/3) (ツボ2)Checkpoint Age が水平線になったら要注意 (ツボ3)MyISAM は無いよね監視 (ツボ4)万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL

    これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(システム編)|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
  • MySQL の wait_timeout と thread_cache_size の関係 | Carpe Diem

    Jeremy Zawodny 氏のブログに MySQL, Linux, and Thread Caching という興味深い記事があったので、理解するために自分翻訳してみた。この記事は、今はないけれども rember.yahoo.com で MySQL を使ったときの話のようです。ちなみに MySQL のバージョンは 4.0.4。 わぉ、とても忙しい一週間だった。私は、remeber.yahoo.com の MySQL サーバや関連するものごとに実に何日かを費した。そして、私は1日か2日を休息に使った(睡眠やシャワーなど) ところで、私はいくつか興味深い発見をした。もっとも驚いたことは MySQL サーバがとても忙しくなったときの Linux 上でのスレッドキャッシングの挙動だ。ポイントは、忙しいときのみということだ。忘れずに。 あなたも分かっていると思うが、われわれがすべてのウェブサーバ

  • サービス終了のお知らせ - NAVER まとめ

    サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

  • 第11回 パフォーマンス管理・実践編(前編)

    Webシステムのパフォーマンスを管理するには,「設計→実装→検証→対処→設計に戻る」というサイクルを回すと説明した。今回と次回ではこのサイクルの中でも特に重要な,「設計」と「検証」の実践法を説明する。具体的には,設計時にネットワーク帯域やサーバー機のスペック,台数などを見積もる「キャパシティ・プランニング」と,検証時にパフォーマンスを実測して確かめる「負荷テスト」のポイントを示す。 キャパシティ・プランニングの実践 「1秒当たり100件のリクエストを処理する」というスループット要件があるとしよう。さて,このWebシステムのネットワーク構成やサーバー構成をどう決めればいいのだろうか? まずは,アプリケーションの特性を見極めて,「Web層」「AP層」「DB層」のどこでリクエストが完了するかの割合を把握する。DBアクセスを伴うリクエストはAP層を経てDB層で完了するが,静的なHTMLページを返す

    第11回 パフォーマンス管理・実践編(前編)
  • [ThinkIT] 第1回:定量的な情報収集のススメ (1/3)

    MySQLサーバに限らず、大量のアクセスを処理するデータベースやアプリケーションサーバ群に対して、それぞれの環境に合わせたチューニングを行うことは企業システムにおいて必須の項目です。しかし「チューニングすべきパラメータとその最適値をどのように決定すればよいのか」、また「実際にチューニングを施すことによってどの程度効果があったのか」を把握することは意外に難しいものです。 ですが、敢えていえば答えは明瞭で、「定量的な情報収集と分析」の他にないでしょう。あらかじめ情報を収集しておけば、チューニング前後でのデータを比較することによってどのような変化が起きたのかを知ることができます。 連載では、まずはMySQLサーバにおいて収集すべき情報を提示し、その後、それらを利用した基的なパラメータについてのチューニング方針を紹介します。 また、今回はOSにCentOS 5.0、データベースにMySQL 5

  • MySQLのEXPLAINを徹底解説!!

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

    MySQLのEXPLAINを徹底解説!!
  • @IT:httpd.confによるWebサーバの最適化(1/3)

    などに配置されています。 なお、httpd.confの更新内容を有効にするには、httpd.conf編集後にApacheを再起動する必要があります。Apacheの再起動は、第1回の「起動/終了、サービスの登録」を参考にしてください。 不要な機能、設定の削除 不要なモジュールの削除 Apacheは、モジュールによって機能を追加することができます。Apacheインストール時に組み込まれているモジュールは、以下のようにして確認できます。

    @IT:httpd.confによるWebサーバの最適化(1/3)
  • PHP コード最適化 Best Practices 63+ - カタコト日記

    みたいなタイトルの記事を Digg 経由で発見。チートシート代わりにと思い超訳。*1 A Software Architect PHP 最適化 ベストプラクティス! 01. static にできるメソッドは static として宣言しよう。(4倍速い) 02. echo の方が print より速い。 03. echo '文','字'; (カンマ区切り)の方が、'文'.'字' (ドット連結)より速い。 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。 05. 大きい配列のような変数は unset() してメモリを解放しよう。 06. マジックメソッド(例: __get, __set, __autoload)は使用を避けよう。 07. require_once はハイコストなのです。 08. include や require でファイルはフルパスで指定しよう。 09

    PHP コード最適化 Best Practices 63+ - カタコト日記
  • 1