ディスク複製で LVM の VG（VolumeGroup）名の重複の解決方法
前エントリの SSD ベンチマーク、前々エントリの SSD 購入報告で書いたように、自宅サーバのストレージを HDD から SSD へ移行する際に、LVM の VG（VolumeGroup）名が重複していたために、簡単にはディスクコピーができず苦しんだばかりか、ディスクコピーをした後に、正常起動させるまでに更に苦しんだ備忘録です。 まず結論というか今後の自分へのアドバイス。インストール時の LVM 設定では、必ず VG（VolumeGroup）名をデフォルトの VolGroup00 を日付などを用いて VolGroup100321 みたいにユニーク化して、他と重複させない癖を付けよう！ さて、今から備忘録として記述する Linux のディスク交換の方法は、クローン作成の最適解でも何でもない方法だと思うけど、自分的には非常に慣れ親しんだ方法なので精神的に楽です。 まず、僕が知っているディスク
HTML - meta タグの仕様詳細まとめ :: Drk7jp
前エントリ - 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
nfs が umount できなかった。kill できないプロセスができちゃった。
えー結論からすると nfs を使ってるときには以下の３点に注意。 1. nfs client 側で umount せずに nfs server が動いているマシンを停止させない。 2. 上記状態になってしまったときに df -k など mount された状態を前提としたコマンドを実行させない。 3. 実行してしまって STAT が D の状態になってしまったプロセスが生まれてしまったらリブートしか解決方法はない。 です。では、何故こんな状態になってしまったか、ポカミスについて備忘録として情報公開です。 まず一番の原因として nfs client の接続を切らずに nfs server が動いているサーバを停止しちゃいました。これが前日にやったこと。バッチ処理で df -k の実行が走りました。 この通りロードアベレージが急上昇しました。df -k によって本来 mount されている nf
syslog のローテート設定
Linux ならログ管理は syslog を利用すると大変便利で、Apache + mod_perl の負荷分散として導入する Pound とかのログやアプリケーションログも syslog に任せてしまっている。 syslog 経由でログを出力したい場合、/etc/syslog.conf に設定を記述してやればよく、例えば、 local0.* /var/log/applog なんて記述を追加してあげて、Perl からは、 use Sys::Syslog; openlog(__FILE__, 'cons,pid', 'local0'); syslog('info', 'this is test message!!'); closelog(); で完了だ。自前でログ管理モジュールを作るよりも Linux の機能として一元管理できて大変便利です。忘れてならないのが（僕は忘れていたので、
ecl.js (Escape Codec Library) と Sleipnir の相性が悪い件について
とあるサイトで ecl.js を使っています。ecl.js とは JavaScript で文字コード変換を行うライブラリで Escape Codec Library が正式名称です。配布元は Escape Codec Library: ecl.js です。ちなみに yaplog に組み込まれている /blog/js/urlEnDecoding.js も元ネタは ecl.js みたいですね。もちろん Sleipnir で yaplog 見ると激遅です・・・ Shift_JISエンコードやEUC-JPエンコードなども可能な escape エンコード・デコード関数のライブラリ 文字列をすべてのコンピュータで読めるような形式に変換したり、変換されたものを元の文字列にデコードすることができる関数のライブラリです。 ビルトイン関数 escape() , unescape() とは異なり、どの種類のブラ
高負荷、大量アクセスなサイトで Lighttpd を使う場合の注意点
今回、Amazon Search が落ちていた原因は、Lighttpd プロセスが FastCGI プロセスと socket 通信不能になるバグ？が原因です。実は、ちょくちょくこの現象が発生しています。具体的には、 2006-02-01 20:29:03: (server.c.1033) [note] sockets disabled, out-of-fds 2006-02-01 20:29:33: (server.c.998) [note] sockets enabled again 2006-02-01 20:29:33: (server.c.1033) [note] sockets disabled, out-of-fds 2006-02-01 20:30:22: (server.c.946) connection closed - write-request-timeout: 71
破れた掃除機のホースを修復する方法
我が家には２台掃除機あります。１つはElectrolux エルゴラピード サイクロニック っていう充電式でデザイン重視の掃除機で、もう一つが普通の掃除機です。正直、充電式の方が遙かに吸引能力が劣るので、隅々まで掃除したいときは普通の掃除機を使って掃除をして貰っています。 古い掃除機は６年ほど使ってきたのでホースが老朽化したためか、遂に根本が破れてしまいました。 でもこの程度のホースの破れであれば、簡単に修復できちゃいます。 修復するために、次の物を用意します。多分自宅にある物ばかりだと思います。 ペットボトルに付いているビニール セロハンテープとガムテープ ドライヤー 1. ビニールをホースの破れたヶところに巻き付けて、セロハンで仮止めします。 2. 次に、ドライヤーの風量を弱にして熱風を満遍なく当て続けます。見る見るうちにビニールがホースに張り付くように縮まっていきます。 3. 最終的に
Windows で消えないファイルを消す方法
エクスプロラーが不正終了したり、ダウンロードが途中で不正終了した場合、たまに消せないファイルができることがあります。ごみ箱へ移動しようとすると、「ファイルを削除できません。送り側のファイルまたはディスクから読み取れません。」と表示されてしまいます。 このようなときは、dos 窓を開いて、windows からは直接設定することのできないファイル属性を変更する必要があります。以下に説明する手順で削除することが可能となりますが、手順を間違えると大変なことになるので、慎重に作業する必要があります。 「スタート」→「プログラム」→「アクセサリ」→「コマンドプロンプト」から dos 窓を起動する。 cd "消したいファイルが存在するディレクトリ名" と入力し、ディレクトリを移動。"" で囲むと半角スペースを含むディレクトリが指定できます。 attrib と入力。通常のファイルなら「A 〜」と表示され
Spreadsheet::WriteExcel = Perl で Excel 出力
業務系アプリを書いていると、csv 出力ぢゃなくて、Excel データそのものを出力できたらなぁ・・・と思うことがあると思います。そこで、 Perl で Excel データを生成する方法と日本語を扱うときの注意点をまとめてみました。 環境構築編／必要な Perl モジュールをインストールします。 下記コマンドを root 権限のあるユーザで実行してください。 perl -MCPAN -e 'install Spreadsheet::WriteExcel' perl -MCPAN -e 'install Spreadsheet::ParseExcel' perl -MCPAN -e 'install Unicode::String' 日本語を含む Excel データの生成例 #!/usr/bin/perl -w use strict; use Jcode; use Unicode::Stri
lighttpd + FastCGI は mod_perl + Apache1.3 より１割ほど高速 :: Drk7jp
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が１割
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
