タグ

TroubleShootingに関するsilver_arrowのブックマーク (6)

  • フォトレポート:時代を振り返る--Windows XPの「ブルースクリーン」

    深刻なシステム障害によってSTOPエラーが発生したとき、恐ろしげな「死のブルースクリーン」(BSOD)に表示される情報を解読できるかどうかで、トラブルシューティングのスピードが違ってくる。このフォトレポートでは、「Windows XP」の一般的なBSODエラーメッセージを紹介する。 STOP: 0x0000000A IRQL_NOT_LESS_OR_EQUAL このSTOPエラーは、ソフトウェアかハードウェアのいずれかが原因で発生し、カーネルモードプロセスまたはドライバがアクセス権限のないメモリロケーションにアクセスしようとしたか、カーネル割り込み要求レベル(IRQL)が高すぎるメモリロケーションにアクセスしようとしたことを示している。 提供:Greg Shultz 深刻なシステム障害によってSTOPエラーが発生したとき、恐ろしげな「死のブルースクリーン」(BSOD)に表示される情報を解読

    フォトレポート:時代を振り返る--Windows XPの「ブルースクリーン」
    silver_arrow
    silver_arrow 2008/12/16
    いちおうメモ。
  • 減り続けるメモリ残量! 果たしてその原因は!? 第1回 (1/3) − @IT

    減り続けるメモリ残量! 果たしてその原因は!?:Linuxトラブルシューティング探偵団 番外編(1)(1/3 ページ) NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団! 助けを借りたいときは、いつでもいってくれ! OS:高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。 Web:福山義仁 俺は、福山義仁。Web技術の達人さ。Ap

    減り続けるメモリ残量! 果たしてその原因は!? 第1回 (1/3) − @IT
  • スレッドダンプの森で覚えた死のロックへの違和感

    スレッドダンプの森で覚えた死のロックへの違和感:現場から学ぶWebアプリ開発のトラブルハック(11)(1/3 ページ) 連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) スレッドダンプはトラブルハックに非常に有効 Javaを用いたシステムで発生したトラブルを解析する際、スレッドダンプは非常に有効な手掛かりを指し示してくれる。 例えば、連載第3回の「【実録ドキュメント】そのログ当に必要ですか?」ではログ出力がボトルネックとなったトラブルを、解析ツールを用いたスレッドダンプ解析により発見している。また、連載第10回の「ThreadとHashMapに潜む無限回廊は実に面白い?」では、レースコンディション(競合

    スレッドダンプの森で覚えた死のロックへの違和感
  • パスワードを紛失したDomUをリカバリ

    RHEL/CentOS、Xenを中心にメモを残していきます。内容は無保証。適用する場合は、十分確認の上、自己責任で。 指摘、質問、要望をコメントしてもらえると喜びます。 DomUのパスワードを忘れてしまった場合の復旧作業のメモ。 簡単に言うと、当該DomUのイメージファイルなり論理ボリューム(logical volmume, LV)をマウントし、/etc/shadowを編集すればよい。DomUで論理ボリュームを使用している場合、Dom0と同じボリュームグループ(volume group, VG)名だと面倒なことになる(『LVMをXenを使ってサルベージする』参照)ため、Dom0のVG名は、事前にVolGroup00ではなく、例えばVolGroupXX等に変更しておく。以下、Dom0上で作業する。# kpartx -a /dev/VolGroupXX/LVNAME # pvscan PV /

    silver_arrow
    silver_arrow 2008/11/26
    マウントして、openssl のコマンドでパスワード生成して shadowを編集汁と。
  • Kazuho@Cybozu Labs: MySQL のクエリ最適化における、もうひとつの検証方法

    « メッセージキュー事始め with Q4M | メイン | フレンド・タイムライン処理の原理と実践 » 2008年06月09日 MySQL のクエリ最適化における、もうひとつの検証方法 EXPLAIN を使用して MySQLSQL を最適化するというのは、良く知られた手法だと思います。しかし、EXPLAIN の返す結果が、かならずしもアテになるわけではありません。たとえば、以下のような EXPLAIN を見て、このクエリが最適かどうか、判断ができるでしょうか。私には分かりません。 mysql> EXPLAIN SELECT message.id,message.user_id,message.body FROM message INNER JOIN mailbox ON message.id=mailbox.message_id WHERE mailbox.user_id=2 OR

  • PostgreSQLを遅くしている犯人はどこだ?

    PostgreSQLを遅くしている犯人はどこだ?:Linuxトラブルシューティング探偵団(3)(1/3 ページ) NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。引き続きOSSに関するトラブルの解決過程を@ITで連載していくぜ。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団! 助けを借りたいときは、いつでもいってくれ! OS:高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。

    PostgreSQLを遅くしている犯人はどこだ?
  • 1