はじめに LPIC201にて出題されるカーネルソースコードのディレクトリ構成について学習する。 なお、執筆時の環境がWSLのため、実機検証はなし。概念理解に留める。 （カーネルソースコードを改めてインストールするのはオーバーだと判断） カーネルソースコードの概要 カーネル（OSの中核、ハードウェアとアプリケーションの仲…

結論 概念 役割 オーバーロード 同じクラス内に同名のメソッドを複数定義すること 成立条件 引数の型リスト（型・個数・順序）が異なること シグネチャ メソッド名 + 引数の型リスト（戻り値・修飾子・throwsは含まない） コンストラクタ 同じ仕組みで複数定義できる オーバーロードとは 同じクラス内に同名のメソッドを複…

LPIC201 の主題200(キャパシティプランニング)で、概念問題の答え合わせをしていて気づいたことがある。「継続的にシステムリソースを測定する目的は?」と聞かれて 1 つだけ選ぶ問題のつもりが、実は 3 つ全選択 が正解だった。キャパシティプランニングは「拡張・予測・問題切分」の 3 軸で、継続測定の目的もそれに …

LPIC201 の主題200(キャパシティプランニング)で監視ツールの章にきて、collectd / MRTG / Nagios / cacti を「どれもサーバ監視」と一括りにしていた。実際は 役割が独立した別カテゴリで、collectd はプラグイン式デーモン、MRTG は SNMP トラフィック専用、Nagios…

LPIC201 の主題200(キャパシティプランニング)で free の出力を見て「free 列が小さいからメモリ不足」と判断する選択肢に引っかかった。Linux はメモリを積極的にバッファ・キャッシュに回す設計のため、free 列単独では「真の空き」を表さない。実質利用可能メモリは available 列(buff/…

LPIC201 の主題200(キャパシティプランニング)で iostat と mpstat を「どっちもシステム全体のリソースを見るやつ」程度にざっくり覚えていたら、画像問題で取り違えた。iostat は CPU + デバイス毎I/O の 2 ブロック構造、mpstat は CPU 毎(コア毎) の統計が主役で、観点軸…

LPIC201 の主題200(キャパシティプランニング)で出力スクリーンショットからコマンドを当てる問題を解いていて、iotop と top を取り違えた。両者とも対話型 ncurses で見た目が似ているが、ヘッダと列が完全に違う。iotop は Total DISK READ / Total DISK WRITE …

LPIC201 の主題200(キャパシティプランニング)で「CPU 負荷平均を表示するコマンドを全て選べ」という問題に出会って、top だけ選んで失点した。load average を表示するコマンドは top / w / uptime の 3 兄弟で、出力第 1 行が完全に同一書式。さらに load average …

LPIC201 の主題200(キャパシティプランニング)でネットワーク監視周りの問題を解いていて、netstat -i と netstat -s を「どっちも統計でしょ」と一緒くたにしていたら、画像問題で外した。-i は NIC 毎(インターフェース)のテーブル、-s は プロトコル毎(IP/ICMP/TCP/UDP)…

LPIC201 の主題200(キャパシティプランニング)で ps 系の問題を解いていて、ps aux と ps -ef を「どっちかを覚えていればいい」程度に流していたら、出力列の判別問題で詰まった。aux と -ef は オプション系統そのものが違う(BSD系 vs UNIX系)ので、出力列も並びも別物として独立に押…