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 の状態をさらに詳しく確認 おおよその原因特定から設定を
ネットショップ運営者必見？迷惑メール扱いを回避する手順
つい最近ネットショップ運営の方から相談を受けた案件ですが、飯の種として解決方法のエッセンスを公開しておこうと思います。今回いただいた要件は概ね下記の通りでした。 ネットショップを運営しているが、注文確認メールや問い合わせ対応などで、自社から顧客に対して送るメールがスパムメール扱いされてしまい、迷惑メールフォルダなどへ格納されてしまい大変困っている。特に顧客の多くが Yahoo! メールを使っているが、Yahoo! メールにはメールが届かない時が多くて困っている。 以前に書いた「メール送信者認証技術 SPF/Sender ID についてお勉強」でも Yahoo! メールの迷惑メール判定でメールが迷惑メールフォルダへ格納される理由について説明しましたが、今回の Yahoo! メールへ届かないという不都合は、迷惑メールフォルダへ格納されて顧客が気がつかないというパターンだと疑いました。 まずはク
ブクログのパブー（Puboo）で Groonga 本を執筆しました
昨年 10 月頃に AMN 経由で執筆依頼を受けて執筆活動をしました。初執筆と言うことでボツ原稿が溜まるばかりで、なかなか原稿があがらず、第一回目を締め切りを落とし、第二回目の原稿に間に合わせ、その後いろいろと調整ということで、執筆完了してから約3ヶ月後にめでたく販売開始となりました。 電子書籍という形ですが、いつかは、一度は、本を書いてみたいという夢が叶いました。 今回執筆した内容ですが、個人的に注目した groonga という全文検索エンジンを用いて作る検索システムってのが題材です。検索システムの基本的な概念を解説しつつ、僕が昔から使い続けているブログシステム MovableType の検索 CGI を、全文検索エンジン groonga を使って作り直すぞっていう実用的？技術本です。何を隠そう、このブログの検索 CGI で個人的に必要に思って作った経験を汎用化して書籍化しただけです。
KDDI の CloudCore VPS の使用感および他社比較
まず結論からですが、ベンチマークの数値上では他の VPS に負けてしまってますが、物理コア、メモリ量、ディスク容量を考えると、今一番オススメできる VPS だと感じています。ただし CentOS をゼロベースで運用できるスキルが必須になります。セキュリティも設定も貴方次第。そんな感じのサービスです。そこが一番のハードルだと思います。 それぞれの VPS を調査したデータを記載しておきます。KDDI の物理コアが AMD Phenom(tm) 9550 だったことは、僕にとっては相当ショックだったのは内緒です。Intel 系であって欲しかったです。安さのポイントは AMD 系にあったってところでしょうか。まぁそれであっても物理コアなので、ホスト側で重たい処理を実行中だったり、同一ホストに収容されている他の VPS の影響を受けにくい（CPU的な観点では）ことは、サービス運営側にとっては大きな
ab を用いた簡易的な性能・負荷テストの雛形
Web サービスをリリースするにあたり避けては通れない（避けて通ってはいけない）性能・負荷テスト工程。 ウォーターフォールやアジャイルなど開発手法は様々ありますが、現実問題、概ね開発工程が遅延する傾向があります。なんとか単体テスト・結合テスト・システムテストはやりきるものの、力尽きて性能・負荷テストを実施せずにリリース・・・なんてことはありませんでしょうか？ そんな場合に限って、リリース直後に高負荷でサービスダウン・・・なんてことになりがちです。 そうならないために性能・負荷テストは必ず実施すべき項目です。ツールとして JMeter がメジャーですがシナリオ作ったり、使い方覚えたりと、正直面倒です。でも apache bench なら使ったことあるし知ってる！という方も多いことでしょう。そこで僕が "簡易的" に性能・負荷テストで使っている方法を公開します。 ab を用いた簡易的な性能・負
PerlMagick が OpenMP 有効だと高負荷になる件
ImageMagick と PerlMagick を使った CGI が原因不明の高負荷になり、ドツボに嵌ったので、備忘録として残しておくことにします。結論からすると apache + ImageMagick + PerlMagick を安定稼働させるには ImageMagick を OpenMP 無効化してコンパイルする必要があるようです。 具体的には下記のようなオプションを付けてコンパイルを行うことで安定動作となります。 ※ --disable-openmp --disable-opencl は一緒に指定する必要があります。 cd /usr/local/src/ wget http://image_magick.veidrodis.com/image_magick/ImageMagick-6.7.4-2.tar.gz tar xvfz ImageMagick-6.7.4-2.tar.gz
CSS sprite 導入や javascript 最適化でブログ表示を高速化
７月下旬くらいから徐々に進めてきた作業ですが概ね形になりました。 このチューニング作業で当ブログの表示を約２倍に高速化することができました！ ∩(≧ο≦)∩ 高速化と行っても得意分野の動的コンテンツ（プログラムやＤＢのチューニング）ではなく静的コンテンツのチューニングです。チューニングの観点は文末の二冊の参考書を読むと理解が深まると思いますが、大きく分類するとサーバのチューニングとコンテンツのチューニングに分けられます。そして個人運営のサーバではちょっとチューニングの余地がなさそうな項目は除外すると次のような項目がチューニングポイントとなります。 コンテンツの構成によるチューニング HTTP リクエストを減らす → CSS スプライト導入、JavaScript/CSS ファイルを１つに統合 スタイルシートのロードを head 内に記述 可能な限りスクリプトのロードを /body タグ直前に
そろそろ Xperia arc と iPhone4 について語っておくか・・・
xperia arcを手に入れてから約一ヶ月が経ちました。手に入れた直後に感想を書くのも相当量の偏見が入りそうだったので、まずは一ヶ月使い続けてみました。もうそろそろ語っておいても良かろうと思いエントリとして書き綴ってみます。 iphone4 と Xperia arc の評価は評価者の属性によって大きく変わると考えているの で、まずは僕の属性をちょっとだけ書いておきます。 38歳男性 docomo ガラケーユーザ歴10数年。 iphone4 歴約8ヶ月。現在は Xperia arc, N905is, iphone4 のケータイ三台持ち 新しい物好き、デジタル家電好き、PC 歴 20 年、超絶面倒くさがり屋 iPhone4 と Xperia arc をともに使ってみて感じた差などを独断と偏見で語ってみたいと思います。 まず結論から。 比ぶべくもなく圧倒的な差で iPhone4 の勝ちです。
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
Linux/UNIX 上でコマンドの実行履歴を残す方法
最近、セキュリティ関連の話が多いが身の回りで多いのですが、今回は、Linux / UNIX 系で誰がいつどのコマンドを実行したかってのをログにとる方法のお話しです。 「＠IT：止められないUNIXサーバの管理対策 第6回 - Page2」にも参考になるロギングの話が掲載されていますが、実行コマンドのログをとる方法は以下の５つが考えられます。 sudo を使って実行ログをとる .bash_history を定期的にバックアップして実行ログとして保存する script コマンドを使うことで実行ログ（画面出力のコピー）をとる システムアカウンティング機能（psacct）を有効にして実行ログをとる 実行シェルを改造し、ログを保存するようにする 僕が考えつくところで、セキュリティ的に最も強固であるのはシェルの改造と思います。但し、その OS 上で使える Shell をその改造 Shell のみに限定
Slowloris HTTP DoS 攻撃について
ちょっと前に Apacheに新たな脆弱性発見 - スラッシュドット・ジャパン で紹介されていた脆弱性なんですけど・・・会社のお達しで各サービス毎に状況報告ってイベントがあったので、ちょいと脆弱性試験してました。そのまとめです。 Apacheに、DoS攻撃に繋がる脆弱性が新たに見つかったそうだ（本家/.記事より） この脆弱性は、これを利用したHTTP DoSツール「Slowloris」がリリースされたことから明らかになったとのこと。この攻撃ツールはApacheに不完全なリクエストヘッダーを送り続けるもので、Apacheが最後のヘッダが送られてくるのを待つ間、偽のヘッダを送ることで接続をオープンにし続け、Apacheのプロセスを一杯にさせるものだという。 脆弱性はApache 1.x、 2.x、 dhttpd、 GoAhead WebServer、そしてSquidにて確認されているが、IIS6
Yahoo! のキーフレーズ抽出 API の使い道を軽く考えてみた
先日ですが Yahoo!デベロッパーネットワーク - テキスト解析 - キーフレーズ抽出 なる API が公開されました。 この API を駆使すれば個人でも Google AdSense のようなコンテンツマッチ広告すらできちゃいそうなシロモノです。この手の技術に興味がある僕からすれば、コンテンツマッチ技術の根幹の技術を、よくもまぁ無料の API で公開したものだなぁ〜 Yahoo! って太っ腹だなぁ〜と唯々感心するばかりです。 さて、どうせなので、コンテンツマッチの技術についてもう少ししゃべってみます。 基本的に”とあるページ”にコンテンツマッチの”何か”を表示するロジックはこんな感じ。 ”とあるページ"（解析対象）”の html を取得 html 全体から本文抽出 特徴語抽出（キーフレーズ抽出） 特徴語をベースに”表示する何か”を類似度順にソート（例えばコサイン距離とか） ”とあるペ
memcached で SERVER_ERROR out of memory storing object というエラー
ちょっと前にエントリにも書いた業務アプリですが、セッション管理に repcached を使っています。repcached とは memcached にデータのレプリケーション機能を追加実装したもので KLab 株式会社が開発したソフトウェアです。レプリケーションの機能により可用性は飛躍的に向上しているかわりに、まぁぶっちゃけ速度はかなり犠牲になっています。※ベンチマークをとったわけではないけど負荷テストで体感できるくらい違う。 さて、今回のアプリケーションサーバの構成としては、Oracle RAC + memcached でオラクルでも快適なセッション管理を！ で書いたような以下の構成になっています。 memcached のメモリには 1GB を割り当てていたのですが、ちょっとメモリが少なかったようです。運用し始めて数日後にセッションが保持されない不具合にみまわれました。随所に warn
Googlebot のアクセスが多すぎて悩ましい時の対処方法
その昔に Amazon の API が公開されたばかりの時に作った − Butsuyoku.info :: 最新の口コミ情報を見ながら Amazon でショッピング！ なんですが、作ってすぐに興味もなくなり、口コミ情報といいつつ、API 変更にも対応せず口コミ情報が取得できない状態になっていたり、ボロボロ状態で数年放置状態なわけですが、Googlebot さまは一生懸命にクロールしに来てくれています。 ってかマジヤバイ。コンテンツキャッシュにMySQL を使って作ったんですけど、テーブルサイズがすぐに 4GB になっちゃいます。MySQL側の設定で 4GB 超え対応していないので、いつの間にか FastCGI がエラー吐きまくっていて Lighttpd 全体がフリーズしてしまう。なんてことが度々ありました。 Googlebot のアクセスはこんな感じ。毎秒アクセスしに来る感じです。つまり、
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 を高速なものに交換する以外ありません。 というわけで
二度押し防止の onsubmit で disable にするやつ :: Drk7jp
もう２年ほど前に話題になったアレなんですけど、今更ながらあるサービスでこの仕組みの導入を検討しています。 onsubmit で submit ボタンを disable にしてユーザビリティを良くする - naoyaのはてなダイアリー submit ボタン disable 技の罠 - naoyaのはてなダイアリー onsubmit で submit ボタンを < disable にしてユーザビリティを悪くするのはやめてください - のヮの うんこ♥ onsubmit で disable にするやつ - 鷹の島 onsubmit の disable 化ですが既に議論が終わっているように、onsubmit disable の実装方法として、 onsubmit イベント発生時に submit 要素を disable にして値をサーバへ渡すための hidden 要素を生成する方法 setTimeou
メール送信者認証技術 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
ISP から帯域制限をかけられてたので ISP 変更しました
ここ数ヶ月、回線速度が妙に遅いと感じていました。僕の住まいは団地で各棟にＢフレッツマンションの VDSL 方式でネット接続ができるようになっているのですが、他の人が動画とか見ていて帯域を使ってるのかなぁ〜と思いこんでました。 仕方がないからＢフレッツファミリーへ乗り換えるべく新規加入申し込みをしました。ＮＴＴから通常マンションタイプがあるときはファミリーはひかないと思うので管理人に工事許可を取ってきて下さい。と言われて週末に話をしに行くかというところでした。でそんなときに読んだのが、 ゆーすけべー日記: 「連絡 - ISP から帯域制限をかけられつがりにくくなってます」自宅サーバ管理者の憂鬱 あぁっっっ！なるほどっ！ この可能性があったかっ！ まさに見落とし。早速調べてみました。 今使っているプロバイダは ASAHI ネットです。いろいろと調べてみるとでてくるでてくる。大量のリクエストがあ
ロードアベレージに関する考察
ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー
Lighttpd 1.5.0 を検証 → 現時点で移行は見送りだ
lighttpd-1.5.0 が stable バージョンに近づいてきたようです。以前も紹介したとおり、1.4.x → 1.5.0 では多くの変更点があります。I/O 周りのパフォーマンス改善とか proxy 機能の多機能化が主な変更点かと。 Latest Pre-Release ・ lighttpd-1.5.0-r1691.tar.gz was release on 2007-02-23 Changes On the way from 1.4.x to 1.5.0 many things have been improved, changed and added and we try to keep track of them to make it easier for user to migrate their configuration. ・ IMPORTANT requires g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
