LinuxのCPUスケジューリング、仕組みの違いを理解していますか？ Linuxには主に3種類のスケジューリングポリシーがあります。 ① 通常タスク（SCHED_OTHER） CFS / EEVDFでCPU時間を公平に配分 ② リアルタイムタスク（FIFO / RR） 固定優先度で実行。RRは同一優先度で時間片を使って交代 ③ デッドラインタスク（DEADLINE） EDFで期限の早いタスクを選択し、CBSでCPU実行時間を制御 詳細は以下でまとめているので、合わせて参照ください👇 eeengineer.com/linux-cpu-sch… #Linux #LinuxKernel #インフラエンジニア

EEVDF（Earliest Eligible Virtual Deadline First）は、LinuxのCPU Schedulerが「次にどのタスクを実行するか」を決める仕組みです。 大まかな流れは以下の通りです。 ① Runnableなタスクを確認 ② eligibility で「CPUを受け取る資格」があるか判定 ③ 資格のあるタスク同士で virtual deadline を比較 ④ 最も早いタスクを選んでCPUで実行 詳細は以下をご覧ください👇 eeengineer.com/linux-cpu-sch… #Linux #EEVDF #CPU #Scheduler #インフラエンジニア

pidstat、なんて読むか知っていますか？ 「ピッドスタット」と読みます。 Process / Thread単位でCPU・Memory・I/Oなどを確認できるコマンド。 topで全体を確認 → pidstatで深掘り。 障害調査で覚えておきたいコマンドです。 #Linux #Troubleshooting #インフラエンジニア

Linuxでは、プロセスやスレッドをカーネル内部で「タスク」として管理し、CPUスケジューラが実行するタスクを選択します。 大まかには以下の流れでCPUが実行されます プロセス ↓ スレッド ↓ タスクとして管理 ↓ CPUスケジューラが選択 ↓ CPUコアで実行 複数のCPUコアがあれば、異なるタスクを並列に実行することもできます。 詳細は以下を参照ください！ LinuxプロセスとCPUの仕組みを徹底解説｜スレッド・状態遷移・CPU実行まで #Linux #LinuxKernel #CPU #インフラエンジニア

LinuxのKernelが使うメモリ、どこまで確認していますか？ プロセスのRSSだけでは、Kernelが消費するメモリの内訳は分かりません。 そんなときに役立つのが slabtop です。 特に確認したいのは、 ・CACHE SIZE：Cache全体のメモリ使用量 ・NAME：dentry、inodeなどのCache名 ・OBJS / ACTIVE：オブジェクト数と使用状況 特定のSlab Cacheが増え続けていないか、時系列で確認することも重要です。 メモリ関連のトラブルシューティングについて、以下でまとめてるので合わせて参照ください👇 eeengineer.com/linux-high-me… #Linux #メモリ管理 #トラブルシューティング

Linuxのプロセスのメモリ使用量、RSSだけで判断していませんか？ RSS・PSS・USSは、共有メモリの扱いが異なります。 ・RSS：共有メモリを全量計上 ・PSS：共有メモリをプロセス間で按分 ・USS：専有メモリのみ計上 RSSを複数プロセスで合計すると、共有メモリが重複計上され、実際の物理メモリ消費より大きくなる場合があります。 一方、PSSは共有分を按分するため、プロセスごとの実質的なメモリ使用量を評価するのに適しています。 メモリ関連トラブルシューティング詳細については、以下で説明しているので合わせてご参照ください👇 eeengineer.com/linux-high-me… #Linux #メモリ管理 #トラブルシューティング

Hyper-Threading（SMT）は、常に性能が上がるわけではないので注意が必要です。 同じ物理コアの実行リソースを2つのスレッドで共有するため、ワークロードによっては競合して逆に遅くなることもあります。 ✅ 向いている ・I/Oやメモリ待ちが多い処理 ・Webサーバなど多数の処理を並行実行 ⚠️ 向いていない場合がある ・CPUをフルに使う計算処理 ・HPC / LINPACKなどの高負荷処理 #Linux #CPU #HyperThreading #SMT

Does a successful write() mean your data is already on disk? Not necessarily. With Linux Buffered I/O, write() typically copies data into the Page Cache and marks the modified pages as dirty. The actual storage write happens later through kernel Writeback. This diagram illustrates the entire flow, from write() to storage. For a deeper explanation 👇 eeengineer.com/en/linux-file… #Linux #PageCache #Writeback #LinuxKernel #Performance

LinuxのLoad Averageが高いとき、どこから調査していますか？ Load Averageが高いからといって、必ずしもCPUが不足しているわけではありません。 Load AverageにはCPU実行待ちだけでなく、D stateのタスクも反映されます。 私だったらまず、CPU使用率を確認し、次の観点で切り分けをしています。 ・CPU使用率が高い → vmstatのrを確認し、CPU待ちを調査 ・CPU使用率が低い → vmstatのr・bや%waを確認し、D state・I/O待ちなどを調査 #Linux #トラブルシューティング #インフラエンジニア

OracleとPostgreSQL、内部の処理構造はどう違う？ 実は、大きな仕組みは共通しています。 ・SQLを処理するプロセス ・共有メモリによるデータキャッシュ ・REDO/WALによる更新ログ ・バックグラウンドでのデータ書き出し 一方、プロセス構造やMVCCの実装には違いがあります。 特に、OracleはUndo、PostgreSQLはVACUUMが性能・運用上の重要なポイントかと。 この辺りの仕組みの違いや性能への影響についても、別途まとめようと思います😆 #Oracle #PostgreSQL #データベース #性能設計

Linuxでメモリが不足してきたとき、内部で何が起きるか説明できますか？ Linuxのメモリ管理は、 「仮想メモリ」「Page Cache」「Swap」「kswapd」「OOM Killer」など、用語がいろいろ出てきてわかりずらいので整理しています👇 ・kswapd / Direct Reclaimでページ回収 ・File-backed PageはPage Cacheを回収 ・Anonymous Pageは必要に応じてSwapへ退避 ・それでもメモリを確保できなければOOM Linuxメモリ管理について、Kindle本（Kindle Unlimited）でまとめているので、興味ある方がいたら見てもらえると嬉しいです👇 amazon.co.jp/dp/B0HGCXQFHN #Linux #LinuxKernel #インフラエンジニア

Can you explain how a File Descriptor is connected to an Inode in Linux? The VFS (Virtual File System) manages files through several interconnected objects: File Descriptor: An integer used by a process File: Represents an open file and its state Path: Combines a Dentry and a Mount Dentry: Maps a filename to an Inode Inode: Stores file metadata Superblock: Stores filesystem-wide information Understanding these relationships is essential for understanding how Linux handles file operations. Read more on my blog: eeengineer.com/en/linux-vfs-… #Linux #VFS #FileSystem #LinuxKernel

Can you explain what VFS (Virtual File System) actually does in Linux? VFS provides a common interface for different filesystems, such as ext4, XFS, and NFS. Its key responsibilities include: - Path Resolution: Locate files using Dentries and Inodes. - Permission Checks: Verify access permissions for file operations. - File Descriptor Management: Create File objects and associate them with File Descriptors. - Mount Management: Integrate different filesystems into a unified directory tree. - Operation Dispatch: Route read(), write(), and other operations to the appropriate filesystem implementation. See how it works in the diagram👇 eeengineer.com/en/linux-vfs-… #Linux #VFS #FileSystem #LinuxKernel

Oracle Databaseの仕組みを理解するとき、SGAやREDOなどを個別に覚えるだけでは、全体像がなかなか見えてきません。 実際のSQLは、 Application → Listener → Server Process → SQL解析・最適化・実行 → Oracle Instance → Database → Filesystem / ASM → Linux / Multipath → Storage という複数のレイヤーを通って処理されます。 特にインフラエンジニアとしては、Oracle内部だけでなく、最終的にLinuxのBlock I/Oを経由してStorageへ書き込まれるところまでつなげて理解することが重要だと思っています。 詳細は以下を参照ください👇 eeengineer.com/oracle-databa… #Oracle #OracleDatabase #Linux #データベース #インフラエンジニア

LinuxのLoad Averageが高いとき、どこから調査していますか？ Load Averageが高いからといって、必ずしもCPUが不足しているわけではありません。 Load AverageにはCPU実行待ちだけでなく、D stateのタスクも反映されます。 私だったらまず、CPU使用率を確認し、次の観点で切り分けをしています。 ・CPU使用率が高い → vmstatのrを確認し、CPU待ちを調査 ・CPU使用率が低い → vmstatのr・bや%waを確認し、D state・I/O待ちなどを調査 #Linux #トラブルシューティング #インフラエンジニア

LinuxでLoad Averageが高い。 「CPUが忙しい」と単純に判断していませんか？ 実は、Load Average ≠ CPU使用率です。 Linuxでは主に👇がカウントされます。 ・R state → CPUで実行中 / 実行待ち ・D state → I/O待ちなどの割り込み不可状態 そのため、CPU使用率が低くてもLoad Averageが高くなることがありますので、注意が必要です。 #Linux #LinuxPerformance #トラブルシューティング #インフラエンジニア #障害対応

障害が起きたとき、どんな順番で対応していますか？ 私は障害対応の基本フローを、次の5段階で整理しています。 ① 影響範囲の確認 ② エビデンス収集 ③ 仮説検証・原因特定 ④ 暫定対処・復旧確認 ⑤ 恒久対処 特に意識したいのは、いきなり原因を決めつけず「事実 → 仮説 → 検証」を繰り返すこと。 詳しくは以下を参照ください👇 eeengineer.com/linux-trouble… みなさんの現場では、障害対応をどんな流れで進めていますか？ #Linux #障害対応 #トラブルシューティング #インフラエンジニア

TomcatへのHTTP接続は、いきなりThreadで処理されるわけではありません。 SYN Queue → Accept Queue → Tomcat Connection → Worker Thread という複数のレイヤを通ります。 負荷が高まると、 maxThreads → maxConnections → acceptCount と後段から詰まりが波及し、最終的には接続拒否やTimeoutにつながります。 詳細は以下にまとめてるので、興味あればご覧ください。 eeengineer.com/how-to-tune-t… #Tomcat #Linux #インフラエンジニア