タグ

ブックマーク / www.drk7.jp (42)

  • ネットオーディオ・プレイヤー NP-S2000 を購入

    不思議なことに定期的に沸々とわき上がるオーディオ熱。 この記事に興味を持って読んでいただいた皆様なら、この心情、ご理解いただけると思います。(*^ー゚)b まずは購入編 ここ2年ほどは USB DAC とネットオーディオに興味津々でした。もともと面倒くさがりな性格ゆえに CD プレーヤの CD を入れ替えるのが面倒くさい。PC にためてる itunes の音楽をいい音で聴きたい。そんな欲望がわき上がるもコレという製品が見つからず今日に至ります。 自分の欲求を深掘りして分析した結果、最も重視するのは有線じゃなく無線であること。なので USB DAC は選択肢から外されました。つぎに優先するのは使い勝手よりも音質を優先。でも出せる金額は欲望消化のために貯めていたお小遣い 20 万円まで。そんな観点でネットオーディオを絞り込んだ結果、パイオニアの N-50 かヤマハの NP-S2000 に絞り込

    dann
    dann 2012/09/21
  • 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 の状態をさらに詳しく確認 おおよその原因特定から設定を

    dann
    dann 2011/08/21
  • Oracle 使いなら手元におきたい! - 書評 - 詳解Oracle アーキテクチャ

    久々に図書館で借りたネタです。最近は図書館通いの頻度も減り、ネットで読みたいを読む方向に変わってきました。まぁそのせいで普段読まないジャンルのに出会う頻度は極端に減りましたけど。 さて今回読んだは詳解 Oracle アーキテクチャというオラクルです。前々から気になってたけど図書館で借りられるとは思いもしていなかった。この手のは一読してからじゃないとスペースの無駄になるだけってが結構あるので一読してみたかった。 でいきなり結論。Oracle マスター GOLD 相当の参考書数冊を実務に必要な部分のみこの1冊に凝縮した感じ。逆に言うと Oracle マスターとるための参考書としては情報不足です。ただコレから Oracle を運用して行かなくちゃならないという人にとっては、いつも手元においておきたい一冊です。

    dann
    dann 2011/02/26
  • Oracle の B*Tree インデックスの内部構造についてお勉強中(その3)

    このリーフは必ずソートされて状態で管理されているがために、データの挿入、更新でリーフ分割によるインデックスのパフォーマンス劣化が発生するわけです。また、この解析からわかるように同一ブロック内もしくは近くのブロック内には第一キーが同じものがかたまって存在します。それゆえ、複合索引の場合は、第一キーのみによる SELECT 文でも、効率よくアクセスが可能( INDEX RANGE SCAN )で、逆に第二キーのみによる SELECT 文では、いくつものブロックを読む( INDEX SKIP SCAN もしくは TABE FULL SCAN )必要がでてくるわけです。 見ての通り、同一ブロック内の第一キーの同一値がほぼ全て網羅されています。Oracle はブロック単位で I/O 管理されているため、上記の例だと where ID=1 のように第一キーの等価評価による絞り込みを行う場合、ブロックを

  • Oracle の B*Tree インデックスの内部構造についてお勉強中(その2)

    まずは前エントリで書いた Oracle のインデックス構造図解を再掲から。 題です。Oracle のインデックスの内容をダンプする TreeDump の使い方と解析方法について説明をします。これも定型文なので、覚えておいて損はないかと思います。特にインデックスに関して深追いするなら必須のテクニックです。参考にしたページは下記の2つです。 Bツリーインデックスに最高のパフォーマンスを(1/4) − @IT パフォーマンス劣化はインデックスのせいなのか!? をみっちり検証 − @IT 特に株式会社インサイトテクノロジーの記事が秀逸です。この会社の Oracle スキルは尋常じゃぁありませんね。お仕事で見ている DB システムでは、同社が開発している Performance Insight というツールを導入して Oracle を運用管理しているのですが、パフォーマンスチューニング、障害監視な

    dann
    dann 2011/01/09
    TreeDump
  • Oracle 運用術 : インデックスと統計情報の自動再構築

    僕の場合は、実行計画を変更したくない場合は、sql に hint 句をつけてアプリ側でどうこうしています。綺麗じゃないけど、oracle 任せで 100% 最速な実行計画を練ってくれる訳ではないと経験上思っています。 まずは、あるユーザが保持する全てのインデックスを再構築し、テーブルとインデックスの統計情報を再構築する sql について。spool する場所とかのしては適宜変更して下さい。 ※oracle EE 向けの sql です。再構築時に online 指定があります。oracle SE 向けの場合は online オプションを外して下さい。但し、インデックス再構築時にテーブルロックがかかるので oracle SE の方は実行するタイミングには十分ご注意を。 idxrebuild_and_analyze.sql spool /tmp/idxrebuild_and_analyze.ls

    dann
    dann 2010/12/25
  • 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 を高速なものに交換する以外ありません。 というわけで

  • SSD SSDN-ST256H を bonnie++ で I/O 性能をベンチマーク

    お次は簡単な性能測定として、お馴染みの hdparm を使って測定してみました。比較したのはサーバの中でもっとも高性能な dev02 です。7200rpm を付けているときに /prox/scsi/scsi の値を取得しておくのを忘れましたが、SEAGATE ST9250421ASG なので、それっぽく /proc/scsi/scsi の値を補完しておきました。 [root@srv01 proc]# cat scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: TOSHIBA THNS256G Rev: AGYA Type: Direct-Access ANSI SCSI revision: 05 [root@srv01 bonnie++-1.03e]# hdparm -t

  • bonnie++ で I/O 性能を測定 (Linux/Unix での IO ベンチマークソフト)

    今まで Linux 上でハードディスクのパフォーマンスを計測する方法として hdparm を使ってきましたが、もう少しいろいろなケース別にパフォーマンスを計測したいなぁーとか NFS のパフォーマンスを計測したいなぁーとか思って、ベンチマークツールがないものかと調べてみたら bonnie++ ってのを知りました。 Bonnie++ now at 1.03e (last version before 2.0)! Bonnie++ is a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance. Then you can decide which test is important and decide how to compa

  • syslog は I/O 負荷が高い → daemontool に移行しよう! :: Drk7jp

    qmail のログを daemontool 経由にする方法 まずは、qmail 1.03 内の FAQ テキストの 7.7 項をみる。ちょろっと情報が記載されています。 7.7. How do I avoid syslog? It chews up a lot of CPU time and isn't reliable. Answer: Install daemontools (http://pobox.com/~djb/daemontools.html). Make a /var/log/qmail directory, owned by qmaill, mode 2700. Do qmail-start ./Mailbox /usr/local/bin/accustamp \ | setuser qmaill /usr/local/bin/cyclog /var/log/qmail

  • ブラウザキャッシュによる HTTP 高速化チューニング

    かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の3つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - 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) は、マルチスレッドとマルチプロセスのハイブリッド型サーバを 実装して

  • Log::Dispatch::Email は即座にメールが配信されない件

    今面倒を見ているアプリケーションのログ管理として Log::Dispatch 系を採用しました。 SQL などのトレースログは Log::Dispatch::FileRotate を使ってファイルに書き出しています。エラーログは同じく Log::Dispatch::FileRotate を使ってファイルに書き出すとともに、Log::Dispatch::Email を使ってメール通知をする仕組みで実装しました。 すでにこのアプリケーションは稼働させてから半年ほど経つわけですが、どうにもエラーメールの配信が遅れたり遅れなかったりと不思議な挙動をしていました。幸いにも致命的なエラーは1つもなく今に至っているので、大事には至っていないのですが、長い間メールの遅延の原因がわからず悩んできました。 最初はメールサーバが遅延しているかと考えていたので、メールサーバ側を解析していたのですが、どうにも原因わ

    dann
    dann 2009/11/07
  • CPAN 最速検索を自サーバにコピーってみた

    とあるので、自分用にサーバに、まるごとコピってみました。Ajax で使うための辞書データ生成は perl でさっくりとでっち上げました。公開されていない perl 部分以外は、まるっとコピーしただけですが、これで満足しているので、これ以上のメンテは予定してません・・・。 http://www.drk7.jp/pub/js/cpanmala/ えーっと・・・まぁ CPAN 最速検索がどういうものかってのは、最速インターフェース研究会 :: CPAN最速検索 を観て頂ければOKとして、データ生成の perl プログラムは晒しておきますので、ご自分のサーバでやりたい方は、どうぞご自由にお持ち下さい。 CPAN 最速検索の設置手順書 http://cpan.ma.la/index.html を保存する。 ここから保存もできます。 http://cpan.ma.la/ie_xmlhttp.js を保

    dann
    dann 2009/03/01
  • Devel::Profiler を使ってスクリプトのチューニング実践編

    Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 と書きましたが、プロファイラ使っていろいろ見つかったパフォーマンス劣化を招くモジュールについて少しだけまとめてみました。もちろん全ての環境で同じ結果になるとは限りませんし、僕が書いてるアプリに依存しまくっている前提ですが、何かの参考になればと。 想定していたパフォーマンスより10倍遅い状態の時の Devel::Profiler の結果は以下に示すとおり。 Log::Dispatch::Config::config_dispatcher が全体の 50% 程度も占めています。そ

  • Perl スクリプトで遅い場所を特定する方法 - Devel::Profiler / Devel::NYTProf

    仕事で書いてる Sledge アプリがあるのですが、先日負荷テストを行った結果びっくりすることに現行アプリの10倍遅いことが判明してしまいました・・・orz Sledge フレームワーク自身が重くないことは今までの経験でわかってるのですが、どうにもソースを見直しているだけでは原因が特定できない・・・そんな活躍するのがプロファイラです。プロファイラの御陰で遅いヶ所を特定することができ、無事に想定するパフォーマンスを得ることができました。この内容に関してはまた別エントリにて。 さて、プロファイラを使うとプログラム実行時の各種情報を収集し、性能解析を行うことが可能です。プロファイラについてもう少し詳しくしるには 性能解析 - Wikipedia あたりを読むと良いでしょう。 プロファイラ(英: Profiler)は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの

    dann
    dann 2008/11/09
    Devel::Profiler
  • strawberry perl に DB_File モジュールをインストールする方法

    会社のえろい人に Windows で ActivePerl 使っている時点で負け。Strawberry Perl にスイッチしろって言われてから Strawberry Perl を愛用しています。Windows なのに ppm じゃなくて cpan 使ってモジュールを管理できるのがすごく自然な感じです。 もう ActivePerl には戻れません。 なんと言っても gcc 環境がくっついてくるので XS 系のモジュールもコンパイルできちゃうのが素晴らしいです。nmake.exe をダウンロードしてきて、あーだこーだとコンパイルできなくて悩まなくてすみます。コンパイルに失敗してもコマンドプロンプトを立ち上げて、いつものように、ちょこちょこっといじって手動でインストールを続行したりもできます。 がっ!・・・DB_File がなんだかうまく入らないことに気がつきました。ちょこちょこっとぐぐったら

  • Perl の内部処理系をお勉強

    ちょっと前に perlfilter - Source Filters - についてお勉強したときから調べようと思っていたことなのですが、Perl の内部処理の流れ(Perl 5 Internals)についてお勉強中です。思いっきり見逃してしまいましたが、Perl 5 Internals に興味を満ち始めたこのタイミングにあわせたかのように Shibuya Perl Mongers : Shibuya Perl Mongersテクニカルトーク#9 で XS ネタをやっていたみたいです。残念です。 さて、今回のお勉強の方法は、ズバリ perl 5.8.8 のソースの読解です。もちろん今回は流れを把握するためのものなので、あまり樹海の奥深くまで足を踏み入れたくはないのですが・・・。この記事を書いている時点では perl_parse までの流れを読み終えたところなのですが、構文解析と字句解析が樹海

    dann
    dann 2008/06/28
  • Perl 言語自身すら拡張する Filter 機能をお勉強

    で、そんなことをして何が嬉しいかというと、perl に独自の言語仕様(構文)を加えることができます。ぱっと思いつくものでいえば、Filter::SQLSwitch あたりで使われていたりします。 そもそもなんで今毎 source filter 機能なんて調べているかというと、つい最近、このブログのカテゴリ部分に jQuery の jquery.pager.js を使ってページ分割をしてみました。最近エントリ数が多くなってきて見づらいなぁ〜と思っていたところなんです。 脱線しないように詳しい話はまた別エントリにするとして、MovableType 3.3 の ContextHandlers.pm を一部書き換えないとコレが実現できなかったんですけど、どうせなんでプラグインで配布しようかなぁ〜と考えてしまったわけです。・・・がですね、MT4 系等をサポートしようとすると・・・結構ソースが違

    dann
    dann 2008/06/17
    Filter::Simple
  • perl で Captcha 認証(セキュリティ画像)をやる方法について

    ユーザ登録とかでロボット等でのスパム登録を防止したりって用途に使われているアレです。こんなヤツ。 最近はブログのコメントとかのスパム防止でもよく見かけます。まずは基礎知識。このような画像で認証を行うことを Captcha っていいます。wikipedia の情報を引用すると、 CAPTCHA(キャプチャ、"Completely Automated Public Turing test to tell Computers and Humans Apart"; コンピュータと人間を区別する完全に自動化された公開チューリングテスト)は チャレンジ/レスポンス型テストの一種で、ユーザが人間であるかどうかを決定する計算処理に使われる。この用語はカーネギーメロン大学のLuis von Ahn、マヌエル・ブラム、Nicholas J. Hopper、IBMのJohn Langfordによって2000年に