独身の頃は安い縦型式洗濯機を使っていましたが、結婚当初にドラム式洗濯機に買い替え、それから洗濯機と言えばドラム式派になりました。一回買い替えを経験し、丸 16 年間ドラム式洗濯機を使い続けてきました。 そして今だからこそ断言できます。乾燥機を多用するならドラム式洗濯機はおすすめできません。一年に一回ほどのペースで故障＆メンテを繰り返すのは、もう疲れたよ。 今使っている東芝のドラム式洗濯機。5 年の延長保証が切れた後も何度も何度も修理を繰り返して使ってきましたが、ここ最近、またも例の EH8 エラーが発生して乾燥機能が使えなくなってしまいました。家電の寿命は 10 年が一般的でして、メーカー側も概ね 10 年ほどしか修理パーツをストックしていません。そんなわけで 10 年目に入るこの洗濯機もいよいよお役御免かなと諦めて、洗濯機を買い換えることにしました。 というわけで、結婚してから初めて縦型

かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。

じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで

随分久々の 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 の状態をさらに詳しく確認 おおよその原因特定から設定を

ここ最近ロードアベレージについて調べています。本業の Oracle サーバのロードアベレージが最近高いのです。本日の夜はまだまだ安定した値。下のグラフは loadavg x 100 のグラフ。 Dual Core Xeon が２枚のサーバなので一般的なロードアベレージの解釈からすると４以下なら安全圏。ここ最近は６〜８という数値が多いわけですが、実際の体感的なパフォーマンスがそれほど悪いるわけではなくと言うか全然重く無くってイマイチ良く判らない。CPU とか他の数値は至って安全圏のものばかり。仕方がないので kernel 2.6 のソースを眺める日々がここ数日。とにかく kernel まわりの記事を手当たり次第読んでみました。 マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー Linux カーネルのコンテキストスイッチ処理を読み解く - naoyaのはてなダイアリー

前エントリ　-　Internet Explorer のイメージツールバーを無効化する meta タグ　で予告したとおり meta タグについて生まれて初めてまじめに調べてみました。改めて調べてみると知らなかったこと満載です。っていうか Web エンジニアたるもの一度は W3C勧告 くらいは一通り目を通しておかなくてはダメだなと思ったりしました。面倒なくらい分量があるけど。ひとまず meta タグ情報としての自分にとって永久保存版まとめという位置づけです。 まずは参考になったサイトの紹介から。 W3C勧告HTML4.01 :: The global structure of an HTML document W3C勧告HTML4.01 私的日本語訳 :: The global structure of an HTML document(ja) rfc2616.txt Another HTML