タグ

linuxに関するshase_labのブックマーク (33)

  • HARDWARE ERRORでKernel panicした場合の対処 : しげふみメモ

    2009年06月16日21:24 カテゴリLinux HARDWARE ERRORでKernel panicした場合の対処 Linux機がコンソールに HARDWARE ERROR や Machine Check Exception 等と出力して、Panicしてダウンしたことを経験されたことがあるかもしれません。 例えば、Dual core XEON を2個搭載したあるシステム(SLES10 SP1)が以下のようなメッセージを出してダウンしました。 HARDWARE ERROR CPU 2: Machine Check Exception: 5 Bank 5: b200001802000e0f RIP !INEXACT! 10:<ffffffff80109e70> {mwait_idle+0x36/0x4a} TSC 8f0d8745a874f This is not a software

    HARDWARE ERRORでKernel panicした場合の対処 : しげふみメモ
  • ページが見つかりません | 日本HP

    ページが見つかりません。 目的のページは、移動または削除によって無効になっている可能性があります。申し訳ありませんが、検索またはリンク先よりお探しください。

  • インフラ系SEのやさぐれblog RHEL5.5 GRUB 2TBの壁 その2

    サーバーからネットワークまで広く浅くこなす器用貧乏なSEブログ。何でもこなせるが何一つ極められない赤魔道士みたいなもの。昔は技術情報を発信していたが、最近はマラソンのことしか書いてない RHEL5.5 GRUB 2TBの壁 前回記事の続きです。 2TBのSASディスク5でRAID5を構成→約8TB弱のディスク容量 作成したRAIDアレイは二つの仮想ディスクに分けました。 インストーラからもsda(200GB)とsdb(7.4TB)という二つのディスクとして認識されています。 200GBの方を/bootを含むOS領域として、7.4TBの方をDATA領域とします。 今回はインストーラに怒られることなくパーティション設定が完了です→問題なくインストールできました 2TBの壁には2種類あります。一つがMBRの制限で、もう一つがCDB/LBAの制限です。 今回はMBRの方ですね。2TBの壁をOS別

  • インフラ系SEのやさぐれblog RHEL5.5 GRUB 2TBの壁

    サーバーからネットワークまで広く浅くこなす器用貧乏なSEブログ。何でもこなせるが何一つ極められない赤魔道士みたいなもの。昔は技術情報を発信していたが、最近はマラソンのことしか書いてない 8TBのディスク容量があるサーバーにRedHat EL5.5のインストールをして出荷する案件がありました。 クライアントである無能は働き者HG氏からは、通話録音用のサーバーとするためなるべく1パーティション で構築しろと、弊社の営業OD氏(地獄のミサワ似)経由で指示あり。 2TBの壁とかないんでしたっけ?と聞いてみたら、2TBの壁って、いつの時代の人間ですか。石器時代ですか。 LVMでパーティションをきれば8TBまでいけます。 みたいな感じで小バカにされたので、適当に設定して出荷することに。 パーティション設定で、/bootに128MB、swapに4GB、残りはLVMで全て / にして進めようとすると /b

  • 18:initrdファイルの作成

    開発マシンのファイルを流用してinitrdファイルを作成する 早速,自分Linux用initrdファイルの作成を開始しよう。自分Linux用initrdファイルは,他のファイルと区別しやすいようにファイル名「ramdisk.img」とする。なお,作成手順が複雑なため,2段階に分けて作業する。前半の手順は次の通りだ。 (1)ひな形のinitrdファイルを作成 (2)initrdファイルを展開 (3)ファイル・システムとしてマウント (4)linuxrcスクリプトの書き換え (5)ドライバの導入 (1)のひな形になるinitrdファイルとは,自分Linux開発マシンで用いられているinitrdファイルだ。mkinitrdコマンドにより作成できる。initrdファイルを一から作成するにはディレクトリを作ったり,linuxrcスクリプトを記述したり,起動時に必要なドライバを用意したりと煩雑な作業が

    18:initrdファイルの作成
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

    ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
  • Linuxでうっかりrm -rfしちゃったけど復活出来たよー\(^o^)/ - y-kawazの日記

    サーバのファイル整理作業をしていたところ…、 間違えてrm -rfしてしまった! ぎゃーバックアップもねー! 長いこと生きてたらこんな経験の1度や2度はありますよね? えぇ、ついさっきやらかしちゃいましたwwオワタwww 速攻「rm 復活」とか「rm 取り消し」とかでググッたねw、したらmcってプログラムのUndelete機能使えばよいって情報が出てくるが、どうやらこれext2じゃないと使えないっぽいぞ…、うちext4だ。 混乱。以下ターミナルのヒストリーより実況。 ## こーいうときはまずあれだ、現場保存! ## まずは今いるパーティションを確認 # df -hT Filesystem Type サイズ 使用 残り 使用% マウント位置 /dev/sdb2 ext4 193G 6.9G 176G 4% / /dev/sdb1 ext3 194M 22M 163M 12% /boot /d

    Linuxでうっかりrm -rfしちゃったけど復活出来たよー\(^o^)/ - y-kawazの日記
  • 1.カーネルとカーネルモジュール(第1章カーネル:基本管理コースII)

    ドライバなどカーネルに組み込まれる機能をモジュール化したもの カーネルがコンパクトになっている 動作中のカーネルに組み込むことが可能 ドライバのアップデートにモジュール単位で対応できる ハードウェア構成が変わってもカーネル再構成を必要としない カーネルモジュール カーネルモジュールとは、カーネルの機能を拡張するためのバイナリファイルです。 カーネルモジュールの代表的なものとしては、ディスク、ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバがあげられます。このデバイスドライバは、基的には、各ハードウェアベンダから提供されるもので、これを使用することによって、Linuxカーネルは、多種多様なハードウェアに対応することが可能になっています。 初期のUNIX系OSでは、カーネルの機能を拡張する場合、デバイスドライバなどはすべてカーネルに組み込むという設計になっていま

  • Linux on Power Systems JPN

    The developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ. (Read in Japanese.)

  • LinuxがメジャーなデスクトップOSになるチャンスはもうない? | スラド

    非常に残念でならないが、LinuxがメジャーなデスクトップOSになる夢はもう終わっていると言えるだろう。 安定性もセキュリティも群を抜いて優れており、互換性、パフォーマンス、ユーザビリティをとっても素晴らしい進歩をみせるLinuxだが、どう見てもデスクトップOSとしてヒットしているとは言い難い。LinuxデスクトップOSとして成功するチャンスはあったのかもしれないが、それはとうに昔のことだろう。 結局のところ、Linuxには決定的にコンテンツが不足しており、デスクトップ市場でやっていくには成功の見込みがないのである。コンテンツ不足の原因は「Linuxプラットフォームの細分化」と「オープンソースコミュニティの激しいイデオロギーそのもの」、この2点にあるのではないだろうか。 家/.には「あれ?『終わってる』のはBSDじゃなかったっけ?」といった皮肉や、「デスクトップユーザの1~2%というL

  • ハードウェアRAIDとLinuxカーネルによるソフトウェアRAIDのベンチマーク比較

    ハードウェアRAIDとLinuxカーネルによるソフトウェアRAIDのベンチマーク比較:Validation Case Study(1/3 ページ) ソフトウェアの処理で行うソフトウェアRAIDと、高価なハードウェアRAIDカードとではディスクアクセスの速度はどれほど向上するのだろうか。ベンチマーク結果を基に、すこし硬派な検証を行ってみよう。 ソフトウェアRAIDとハードウェアRAIDの双方について、750GバイトのSamsung SATAドライブ6台を使ってRAIDレベル5、6、10の各構成を評価した。パフォーマンスの測定にはBonnie++とIOzoneの各ベンチマークを用いた。また、チャンクサイズがハードウェアまたはソフトウェアのRAID構成に与える影響を確かめるために、チャンクの大きさを変えてベンチマークを実行した。 ハードウェアRAIDの評価には、12ポートのAdaptec製SAS

    ハードウェアRAIDとLinuxカーネルによるソフトウェアRAIDのベンチマーク比較
  • ページが見つかりません | 日本HP

    ページが見つかりません。 目的のページは、移動または削除によって無効になっている可能性があります。申し訳ありませんが、検索またはリンク先よりお探しください。

  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • vmstatはcpu waをどうやって算出しているのか

    はじめに vmstatには'cpu wa'フィールドがあります. このフィールドの値はどっからでてきているのでしょうか. それをソースコードの面で探求したストーリー. 出張カーネル読書会の前座として発表させていただきました. 資料 発表に利用したプレゼンテーション資料のPDF版(540k). Linux kernel 2.6.11 のソースコードとDebian sidのprocpsに入っているvmstatのソースコード をgonzui 0.9を利用して解析してみたときの記録です. 発表トランスクリプト 西尾さんからのいただきものです.ありがとうございます. わたしは、上川と申します。Debianのデベロッパーやってます。今日は前座と して、思いつきでvmstatでお話します。vmstatでいろんな項目出てきますけど、 これってどういう意味だろうというのを調べてみようと思って、力尽きてioの

  • Linux I/O のお話 write 編 - naoyaのはてなダイアリー

    write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、当にそうなんでしょうか?(否定しているわけではなく、純粋な疑問です。) と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネルの 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方

    Linux I/O のお話 write 編 - naoyaのはてなダイアリー
  • kill and killall

    kill はその名の通りプロセスを強制終了するためのコマンドですが、 その他にも便利な使い方があります。 kill と killall の違い kill は引数としてプロセス ID (PID, ps で確認できる)を取り、 killall は引数としてコマンドやデーモンの名前を取ります。 1つの PID は1つのプロセスに対応するため、 kill は1つのプロセスしか強制終了しませんが、 killall は同じ名前のプロセスが走っていればそれらを すべて強制終了させます。だから、kill"all" です。 たとえば、次のような状況を考えます。 PID COMMAND 1001 kterm 1002 kterm 1003 kterm kterm は3つとも終了します。 kill と killall のオプション kill や killall はさまざまなオプションを持ち、 さまざまなシグナル

  • ITmedia エンタープライズ:PD思考法の基礎と情報収集(その2)

    Linux環境で問題が発生した場合、管理者がするべきことは「その原因がどこにあるか」の正確な把握である。今回は、発生した問題に対し原因がどこにあるかを判別するための基的な考え方と、問題判別に必要な情報収集の基礎について解説しよう。 情報収集のポイント PDにおいて、問題を特定するために情報収集は必要不可欠である。実際に収集すべき情報はケースに応じて異なるが、問題自体に関する記録がないからといって、不要な情報であるとは限らない。情報の収集は、問題そのものを直接に特定するほか、システムの構成や問題点を絞り込むための要素を見つけるためにも必要である。そのことを認識して、情報収集を行っていただきたい。 Linuxで取得できる情報には、OSやユーザープロセスの稼働に関するものと、ハードウェア関連の構成に関するものがある。また、ハードウェアの稼働に関する情報はBIOSから直接取得するほか、最近のIA

    ITmedia エンタープライズ:PD思考法の基礎と情報収集(その2)
  • PCサポート - Linuxデバイスドライバ導入・設定ガイド (Red Hat Enterprise Linux 4 for x86編) - xSeries

    Linuxデバイスドライバ導入・設定ガイド (Red Hat Enterprise Linux 4 for x86編) - xSeries xSeriesで使用する各種デバイスドライバの導入・設定ガイドです。 Red Hat Enteprise Linux 4 for x86 Update1における手順を記載しています。 ドキュメント内で使用しているデバイスドライバのバージョンは、2006年3月時点の最新バージョンとなります。 新しいバージョンのドライバがリリースされている可能性がありますので、導入前にxSeriesサポートサイトをご確認ください。 目次 1. 注意点 2. デバイス・ドライバに関連する前提知識 2.1 xSeriesオプションとデバイス・ドライバの対応 2.2 デバイス・ドライバ作成に必要となるパッケージ 2.3 デバイス・ドライバ関連コマンド/ファイル

  • ぺんぎん戦記 RHEL5をローカルでyumを使ってupdate

    RHEL5からはパッケージ管理にyumが使えるようになりました。 これまでめんどくさかったrpmの依存関係もコレで簡単に。 しかし、普通はRHNにシステムの登録しとかないとyumで updateかけようとしてもできませんし、インターネットに 接続できる環境でないと基的にはあまり使えなかったりします。 でも今回はせっかくupdate1もリリースされているので OSのisoイメージをローカルにマウントし、yumを使って バージョンアップを試みます。 yumのコマンドでパッケージ情報の参照先は /etc/yum.repos.d/の下にリポジトリファイルがあって そこの中身を見ています。 標準だとredhat-debuginfoのファイルしかないはずです。 ここに新たに設定ファイルを作ってしまえばよいのです 適当に/etc/yum.repos.d/local.repo とか作ることにします。 書