TokyoCabinet のデータサイズは 64GB 付近で性能劣化
当ブログでサービスを提供している AmazonSearch ですが、子ども部屋の確保が最大の理由で、自宅サーバから sakura VPS 2G へ一ヶ月ほど前に移行を行いました。移行手順は以前もご紹介した、ブログをさくら VPS へ移行手順に準じて行いました。 AmazonSearch は内部計算が複雑なため、さくら VPS では QPS（queries per second）が 5-6 程度しかでません。したがって、高速化を図るためレスポンス結果を TokyoTyrant（TokyoCabinet）にキャッシュする仕様で実装を行っています。先日まで安定運用できていたのですが、RDB（casket-a.tch） のデータサイズが 64GB 付近に近づいた時点で性能が急激に劣化して高負荷でレスポンスが返せない事象が発生しました。ちょうど 2012/6/2 15:30 付近からです。 [tts
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 を高速なものに交換する以外ありません。 というわけで
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 の状態をさらに詳しく確認 おおよその原因特定から設定を
Kernel 2.6 はディスク I/O情報が /proc/diskstat へ移動
新サーバの設定でパフォーマンス監視のために使っていたMRTG をやめて、より高性能で Web インタフェースで管理もできる Cacti ってのに移行を試みていたのですが、どうにもグラフが真っ白のまま更新されず、諦めて MRTG に戻ることにしました。RRDTool 経由で SNMP の情報を MySQL までデータ格納できていることまでは確認済みなのですが・・・ ※ 誰か教えて！m(_ _)m MRTG も一筋縄ではいかず。設定しているのですが、ディスクI/O 情報が取得できなくなってしまいました。原因を調べると /proc/stat から /proc/diskstats へ情報が移動したようです。 これにあわせて、MRTG で設定しているディスク I/O 取得用のスクリプトも更新しなくてはなりません。 kernel 2.4 までは、こんな感じで上手くいっていると思います。 mrtg.cf
ロードアベレージに関する考察
ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
あなたの作ったメール配信システムはエラーメール処理をしていますか？
今回はメルマガ等やメーリングリストのように大量のメールを配信するためのメール配信システムを自前で開発している方向けの情報（備忘録？）です。 大量のメールを配信する場合、配信できなかったエラーメールを適切に処理することが重要です。たとえば、 なんて感じです。適切なエラーメール処理なくば、知らず知らずのうちに SPAMer と同じようなメール配信をしていることになってしまうのです。かく言う僕の作ったメール配信システムも、それほどエラーメール処理を厳密に行っているわけではなく、何とかしないとなぁ〜と思っている今日この頃で、ちまちま資料を集め始めて仕様検討している次第です。
メール送信者認証技術 SPF/Sender ID についてお勉強
お勉強の背景に関しては 「迷惑メール対策 OP25B（Outbound Port25 Blocking）についてお勉強」 に書いたとおりですが、迷惑メール対策としての SPF/Sender ID についてもいろいろ勉強したのでそのまとめです。（DomainKeys については思いのほかエントリが長くなったのでまた別の機会で・・・）まずは参考になったサイトの紹介から。 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 Sender ID: Authenticating E-Mail DNS関連技術の最新動向 - SPF/DomainKeysとは Sendmail 社 - 送信者認証技術の導入におけるレコメンデーション メール送信者認証の仕組みを探る(2/2):スペシャル - ZD
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
qmail の配信能力を極限まで引き出す方法（ログ関連）
「syslog は I/O 負荷が高い → daemontool に移行しよう！」でも書きましたが、メール配信サービスのような用途の場合、メールサーバの配信ログってのは極めて重要。qmail の配信能力を極限まで引き出すには、様々なチューニングの中でも重要なのがログの出力。 そこで思いついたのがログの出力を RAMディスク上に出力するって方法。もちろんログの出力は daemontool 経由で。 もちろん出力したログは日時バッチでローカルディスク上にバックアップログとして保存。OS フリーズ等でメモリ上のログが失われるって可能性は許容するって要件で構築。 実際に業務で採用して速度の計測をしていたところ、 Intel(R) Xeon(TM) CPU 3.06GHz × ２、 メモリ４Ｇ （うち、RAMディスクは２Ｇ） なＨＷ環境、 net-qmail ベースにいろいろな patch を適用し
Linux/UNIX 上でコマンドの実行履歴を残す方法
最近、セキュリティ関連の話が多いが身の回りで多いのですが、今回は、Linux / UNIX 系で誰がいつどのコマンドを実行したかってのをログにとる方法のお話しです。 「＠IT：止められないUNIXサーバの管理対策 第6回 - Page2」にも参考になるロギングの話が掲載されていますが、実行コマンドのログをとる方法は以下の５つが考えられます。 sudo を使って実行ログをとる .bash_history を定期的にバックアップして実行ログとして保存する script コマンドを使うことで実行ログ（画面出力のコピー）をとる システムアカウンティング機能（psacct）を有効にして実行ログをとる 実行シェルを改造し、ログを保存するようにする 僕が考えつくところで、セキュリティ的に最も強固であるのはシェルの改造と思います。但し、その OS 上で使える Shell をその改造 Shell のみに限定
VMware が頻繁にディスクアクセスして OS 全体が固まる件
こんな現象が発生するようになったのも XP + VMware 5 → Vista + VMware 6ベータ にしてからなのですが、物理メモリもたっぷりのっていて空きメモリもある状態にもかかわらず、VM を起ち上げていると頻繁にディスクアクセスが発生してマシンが数分間フリーズしたかのごとく固まる現象が続いています。 以前物理メモリが 2GB だった時は、まぁ〜しょうがないか〜と思っていたのですが今は 3GB のっていて（ホントは4GBだけど OS が 32bit なのでうまく認識しない・・・）コレは流石にキツイ。ってことで原因を調べてみました。 まずはリソースモニタを起ち上げて VM を使ってディスクアクセスが発生するのを待つ。すぐに発生した。 どうやら VMware の .vmem ってのが頻繁にディスクアクセス（read）を行っている模様。もう少し様子を見てみる。 こんどは頻繁にディス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
