原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
日々是横着 - 「サーバ」に対する誤った認識
最近、常時接続というのが当り前になり、自宅サーバを立てることを 勧めるような書籍や Web ページが非常に多く出てきているので、 自分でもサーバを立ててみたいと思っている人を多く見受けます。 しかし、サーバを立てる際に気をつけるべきことを全く認識せずに 立てようとしている例も非常に多く見受けられます。 ここは、インターネットに公開するサーバを立てる際に一般の方が 勘違いしがちなこととそれに対する(私の個人的な)回答を、 世の中に溢れる「自宅サーバ立てよう！」系の書籍/Web ページには あまり書かれない 「自分でサーバを立てるのは大変だからやめよう！」 という視点で行い、 サーバ運営の現実をしっかり認識して頂くための ページです。 対象とする読者は基本的に 「サーバを自分で立てようと思っている人全員」で す。特に 「あまりコンピュータに詳しいわけじゃないけど、 なんだか自分で立てられるって
MySQL Clusterその後（これから使ってみようと思っているみんなに）: zak blog
以前に書いた、MySQL Clsuterを使ったシステム本運用開始直後のログから2年近くが経過しました。ちょうどいい機会なので、その後の運用を踏まえての感想と、今後の展開について記録を残します。現時点で秘密でない事項についてのみ書きます。 １．SunからOracleへ 知っての通り、MySQLはSunを経てOracleの所有物になりました。 気がついてみるとOSSの主要なデータベース技術のうち、Berkeley DB、InnoDB、MySQLがOracleになってしまいました。 （よかったこと） GPLのデュアルライセンスは今のところ守られています。そのためMySQLにお金を払ってくれるユーザは、今まで通り限られたままで財政的には厳しいはずなんですが、今のところOracleはMySQLに対してコミットを守っているようです。特に変わったところとして、「リリースのスケジュールが守られるようにな
HDDのプラッタ外周部と内周部の性能差を検証してみた - シリコンの谷のゾンビ
けっこう前に秋葉原に行ったときに何も買わずに帰るのも失礼かと思い，カッとなって値崩れしたHDDとSSDを買って帰った．自宅サーバでいろいろ遊んでみる予定だったのだけれど，そのまま放置して3ヶ月近く経ってしまった．最近になってタイの洪水の影響でHDDが高騰しているのでびっくりしている．(2TB HDDが2万円超え・・・だと・・・) さて，この実験をしたくなった原因はだーいーぶ前のWSDM2009のJeff Dean講演のときにチラっと出てきたインデクスの外周部と内周部の使い分け．当たり前のようにさらっと書かれていた． HDDの外周部はパフォーマンス高いんで，インデクスはこっちに置くよ． という部分．へー，そんなに性能が違うのか今度HDD買ったら試してみようと思ってから早2年．ようやく思い立って検証した． なお，Jeff Deanの講演資料は以下にアップされている． Challenges in
ZFS のトラブル続き | HRS's Web Page - The Design and Implementation of the Gracious Days
新しい秩序の確立は、他の何にも増して難しく、 成功する可能性が低く、危険な事業である。 改革者は旧秩序から利益を得ている 全ての者を敵にまわし、 新秩序から利益を受けるはずの者からは 及び腰の支持しか集められない。 --- Niccolo Machiavelli, The Prince この種の「保護」は初心者を保護するかも知れないが、 熟練ユーザを窮地に追い込むことになる。 というのは、何が親切であり、何が適切でないかかという オペレーティングシステムの考え方の裏をかくことばかりに かなりの労力を費やさなければならないからである。 --- A.S.Tannenbaum, Modern Operating Systems 不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得す
memcached-1.4.7-rc1でmixiの大規模障害の原因となったmemcachedの不具合が全て解消されました - blog.nomadscafe.jp
こちらとこちらのエントリーの続き memcached 1.4.6でmixiの障害の原因となったaccept_new_connsがスレッドセーフじゃない件は修正されているはずだったのですが、検証したところ別のスレッド競合による不具合が発生し、Bugは全て解消されてはいませんでした。 この件についてmixiたんぽぽGの森本さんと調査していたところ、memcachedのcommiterにtwitter上で補足され、つたない英語で報告をあげていたら1.4.7-rc1で修正されたのでその報告。 memcached 1.4.6での不具合再現方法 まず、1.4.6で不具合を再現させる方法について。mixiのエンジニアブログと同じように、memcachedは次のオプションで起動し、 $ ./memcached -U 0 -u nobody -p 11222 -t 4 -m 16000 -C -c 1000
大規模システム運用でpuppetやchefだけでは解決しづらいことを解決するMCollective！ - よかろうもん！
もはや説明は不要かもしれませんが、"puppet"は、Puppet Labsが開発しているシステム運用管理ツールで、puppet管理下にあるサーバ群のシステムの状態を"あるべき状態"に保つための補助ツールです。 chefもpuppetと同等の機能を持ち、システムの運用管理をするには大変便利ではありますが、管理するサーバ台数が増加してくると、chef/puppetだけでは解決しづらいことも発生し始めます。 例えば、数百台のサーバの運用管理をしていたら、その中の一部だけサーバの状態が不安定になり、daemonが停止してしまったり、予期せぬレスポンスを返してしまったりする事態に遭遇することが稀にあります。 他にも、特定のロケールに配置してあるサーバでのみ、何かしらの処理を1度だけ実行しなければならないと事態も発生しがちです。 そのような場合は、puppetを利用して状況確認や処理の実行をすること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
