IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
メールログを解析する簡易 Perl スクリプト
「あなたの作ったメール配信システムはエラーメール処理をしていますか？」 という記事が結構よく読まれています。最近は本業の方でもメール未達について調べて欲しいとかいろいろ頼まれた経緯もあり、そのときにでっちあげたスクリプトを晒しておきます。誰かの役にたちそうだなぁ〜と思いまして。 ちなみにメールログの形式は qmail のものでしか試したことがないので各メールサーバにあわせて若干の改変は必要かもしれませんがあしからず・・・。 実行結果例（※解析結果の変数がダンプされます） OK:$VAR1 = { '36224868' => { 'drk@****.jp' => '2008-03-03 19:30:20.173540500 delivery 36224868: success: 127.0.0.1_accepted_message./Remote_host_said:_250_ok_dird
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
Apache2 - worker MPM のプロセス＆スレッド数のチューニング
前エントリ pound と apache をバランスよくチューニングする必要性について の続きです。Apache2 のチューニングによる高負荷（大量アクセス）対策を考えてみます。 ここまできてやっと、そもそも高負荷時に apache2 のプロセス数が足りていなく、静的コンテンツの応答時間が遅延しているのかも？という仮説を立てることができました。図解するとこんな感じです。 Apache2 はもちろん worker MPM で動作させています。worker MPM ってなんぞ？という方は、このブログを読んで頂けている方にはいらっしゃらないかと思いますが http://httpd.apache.org/docs/2.0/mod/worker.html あたりを読むと良いでしょう。 このマルチプロセッシングモジュール (MPM) は、マルチスレッドとマルチプロセスのハイブリッド型サーバを 実装して
pound と apache をバランスよくチューニングする必要性について
もう二ヶ月ほど前の話なのですが、お仕事でサイトが異常に重い（遅い）んだけど・・・という苦情が月に１〜２件ほどきていたので、重い腰を上げて本格的に調査・解析して pound と apache のチューニングを実施しました。チューニング後はサイトが重いという苦情は皆無になりました。(≧∇≦)b 今回のチューニングのキモは pound と apache をバランスよくチューニングするということでした。完全に見落としていた点でもありました。とりあえず苦情がきてた時点までの構成を図にするとこんな感じでした。 何しろ Web サーバの Load Average も CPU 負荷も高くないのでサーバ側は悪くないという思い込みが原因特定を遅らせた一番の原因。この２つの数値はとっても重要なのですが、この数値に真実の見極めを惑わされてはいけません。 以下、調査手順など備忘録的なメモ。途中かなり寄り道したり脱線
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
セキュリティレベルの高いサイトを構築する 22 カ条 :: Drk7jp:
最近、何処の会社でもセキュリティに関してうるさく言われているかと思います。自分としても今まで気を遣ってきていたつもりではあります。しかしながら、 なぜSSL利用をケチるのか：IT Pro SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 安全なWebサイト設計の注意点 を読んでみて、お恥ずかしい限りですが勘違いしていた部分もありました。実際、Amazon とか Yahoo! のログイン画面を見ても、デフォルトが http によるアクセスになっていたりして、メジャーどころでも最新の注意が払われている訳ではないのだなぁ〜と思ったり・・・。本当は全ページ SSL が理想とは知りつつも、SSL の処理負荷の高さ故に、ついついケチったページ遷移にしまうからなのでしょう。。。自分含めて。 自分への情報もかねて、上記ページに記載されている、31箇条の鉄則と最近の事情を加
[_11_Install] intel compiler で Apache が 400% 高速化
「無料で30%のパフォーマンスUP!! - intel compiler」でも書いた intel compiler ですが、apache1.3.33 + mod_perl 1.29 を再構築してみました。apache bench で速度を測ってみたら、ナント 400% も高速化していました。?(￣□￣;)ﾅﾝﾄ!! 本当かぁ？？と思って数回試してみましたが、結果は同じでした。スゴイ！ 以下、インストールメモとapache bench のログです。 mv /usr/bin/gcc /usr/bin/gcc.bk ln -s /opt/intel_cc_80/bin/icc /usr/bin/gcc mkdir /usr/local/src/icc cd /usr/local/src/icc wget http://www.meisei-u.ac.jp/mirror/apache/dist/h
無料で30%のパフォーマンスUP!! - intel compiler :: Drk7jp
最近、雑誌の記事でよく見かけるようになった、Intel Compiler 通称 icc ですが、Linux系にプリインストールされる gcc と比較して re-compile するだけで概ね 30 % 程度の高速化が図れるようです。 試しに、当サイトで配布している「高速半角全角ライブラリ」で検証してみました。 gcc - compile版 [h2z]Drk::Encode[1000000]LOOP TIME=13 [z2h]Drk::Encode[1000000]LOOP TIME=13 icc - compile版 [h2z]Drk::Encode[1000000]LOOP TIME=10 [z2h]Drk::Encode[1000000]LOOP TIME=10 とウワサ通りの高速化が実現できてしまいました。実は version 6 の頃に試用したことがあったのですが、 gcc との互
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
