@kai_infra | IT Infrastructure Engineer

SIerで働いているITインフラエンジニアです。 Linux / ITインフラを「図解」で発信しています。 主なテーマは、 Linux / CPU / Memory / I/O / Network / DB / Middleware / Virtualization。 トラブルシューティングや性能解析など、現場で役立つ知識を中心にまとめています。 「知っている」から「説明できる」へ。 皆さんと一緒に楽しくスキルアップしていけたら嬉しいです！ 📝 Blog eeengineer.com/ 📚 Kindle｜Linux技術書 amazon.co.jp/stores/author/B… ✅ Habicheck｜習慣管理アプリ habicheck.eeengineer.com/ #Linux #インフラエンジニア #Troubleshooting

CPU使用率が高くないのに、コンテナやアプリケーションの処理が遅い。 その原因のひとつとして考えられるのが、cgroupによるCPUスロットリングです。 cgroupでは、CPUの使用時間（Quota）を一定期間（Period）ごとに制限できます。 例えば 100ms / 200ms の場合、 -200msの期間内で最大100ms分のCPU時間を使用可能 -Quotaを使い切ると、残りの期間は実行を制限 -次のPeriodで再び実行可能 cpu.stat の nr_throttled や throttled_time を確認すれば、スロットリングの発生状況も把握できます。 #Linux #LinuxPerformance #cgroup #SRE

What happens inside Linux when a client establishes a TCP connection? A TCP connection involves more than just connect() and accept(). Here's the flow: ① socket() → bind() → listen() The server prepares a listening socket. ② TCP 3-way handshake SYN → SYN-ACK → ACK ③ SYN Queue → Accept Queue Pending requests are tracked in the SYN Queue. Once the handshake completes, an established socket is placed in the Accept Queue. ④ accept() → send() / recv() The server retrieves the connected socket and exchanges data with the client. The key distinction: The SYN Queue manages pending handshakes, while the Accept Queue holds completed connections waiting for accept(). Explore the full explanation and Linux commands on my blog: eeengineer.com/en/how-linux-… #Linux #TCP #Networking #SysAdmin

LinuxのCPUコアごとの使用率を確認するとき、何のコマンドを使っていますか？ ・mpstat -P ALL 1 ・sar -P ALL -u 1 どちらも %usr、%sys、%iowait、%idle などをCPU単位で確認可能。 さらに、sarなら過去の性能データも分析 個人的には、普段からsarを使っていれば、mpstatを使う必要はあまりないと思っていますが、皆さんはどう使い分けていますか？ #Linux #パフォーマンス分析 #インフラエンジニア

Oracle DatabaseのTablespaceとDatafile、どのような関係になっているか説明できますか？ 論理Storageは、次の階層で構成されます。 ① Tablespace：論理的な領域を管理 ② Segment：TableやIndex単位で領域を管理 ③ Extent：複数のBlockをまとめて領域を割り当て ④ Data Block：実際のデータを格納 このように分ける理由は、オブジェクト管理・領域割り当て・データ格納の役割を分離するためです。 また、1つのSegmentは複数のDatafileにまたがれますが、1つのExtentは単一のDatafile内に収まります。 詳細は以下を参照ください👇 eeengineer.com/oracle-databa… #OracleDatabase #Database #インフラエンジニア

How does a Linux server accept TCP connections from clients? It all starts with a socket. ① socket() — Create a socket ② bind() — Assign a local IP address and port ③ listen() — Mark the socket as listening ④ accept() — Accept a connection and obtain a new connected socket ⑤ send() / recv() — Exchange data with the client Key point: The listening socket remains available for new connections, while each accepted connection gets its own connected socket. Learn more about Linux networking: eeengineer.com/en/how-linux-… #Linux #Networking #TCPIP #Sockets

Webサービスの性能を見るとき、Latencyだけを見ていませんか？ 「遅くなった」という事象を捉えるには、 どれだけ処理しているのか？ どれだけ失敗しているのか？ どれだけ時間がかかっているのか？ をセットで見ることが重要です。 そこで役立つのが REDメソッドです。 R：Rate → 単位時間あたりのRequest数（RPS） E：Errors → 失敗したRequestの数・割合 D：Duration → Requestの処理時間（平均・p95・p99など） Rate・Errors・Durationを並べて見ることで、サービスの状態を整理しやすくなります。 詳細は以下も合わせて参照ください👇 eeengineer.com/linux-perform… #Linux #LinuxPerformance #PerformanceEngineering #Observability #REDMethod #WebApplication

sarの過去ログをグラフ化できる「kSar」をご存じですか？ Linuxの性能分析でsarは便利ですが、数値だけでは長時間の負荷変動を把握しにくいことがあります。 そんなときに役立つのが kSar。 ・CPU・Memory・I/O・Networkの推移を可視化 ・リソース使用量の変動やスパイクを発見しやすい ・過去の障害発生時間帯の分析に便利 添付画像はMemory使用状況をグラフ化した例です。 RHEL 9でのsar収集設定からkSarの使い方まで、詳細は以下を参照ください👇 eeengineer.com/linux-sar-com… #Linux #sar #sysstat #パフォーマンス分析

Why can disk usage remain high even after you delete a file with rm? The key is whether a process still has the file open. When rm app.log runs: Directory entry → removed But if a process still holds the file open: File Descriptor → struct file → inode → data blocks The filename disappears, but the underlying file data can remain allocated until the process closes the file. So you may see: ls → file is gone df → disk usage is still high I explain Linux filesystem internals with diagrams on my blog. eeengineer.com/en/linux-file… #Linux #LinuxKernel #Filesystem #inode #dentry #FileDescriptor #DiskUsage #LinuxTroubleshooting

What’s the difference between a Socket, Core, and Logical CPU? They are often confused, especially when discussing server performance. The basic hierarchy is: Socket → Core → Logical CPU Socket: A physical CPU package installed on the motherboard Core: A physical execution unit inside the CPU package Logical CPU: An execution unit recognized by the OS; with SMT, one core can expose multiple logical CPUs I explain Linux and CPU architecture concepts with diagrams on my blog. eeengineer.com/en/linux-cpu-… #Linux #CPU #CPUArchitecture #SMT #HyperThreading #Virtualization #PerformanceEngineering

「CPU使用率が高いから遅い」 「メモリ使用率が高いから問題だ」 本当にそれだけで判断してよいのでしょうか？ Brendan Gregg氏が提唱するUSEメソッドでは、Resourceごとに以下の3つの観点で確認します。 U：Utilization（使用率） S：Saturation（飽和・待ち） E：Errors（エラー） 例えばCPUなら、 Utilization → CPU使用率 Saturation → Run Queue Errors → CPU関連エラー というように、「使用率」だけでなく「待ち」と「エラー」まで見るのがポイントです。 詳細は以下を参照ください👇 eeengineer.com/linux-perform… #Linux #LinuxPerformance #PerformanceEngineering #USEMethod

「メモリ使用率は高くないのに、なぜかシステムが遅い」 そんなときに確認したいのが、Linuxの Memory PSI（Pressure Stall Information） です。 /proc/pressure/memory では、メモリ不足によってTaskがどの程度Stallしているかを確認できます。 some：1つ以上のTaskがMemory PressureでStallしていた時間 full：実行可能なTaskがすべて同時にMemory PressureでStallしていた時間 avg10 / avg60 / avg300：直近10秒・60秒・300秒におけるStall時間の割合 total：累積したStall時間 単純な「メモリ使用率」だけでは見えにくい、メモリが原因でTaskが足止めされている状態を捉えられるのがポイントです。 PSIの有効化状況はディストリビューションやKernel設定などによって異なるため、利用環境で確認してみてください 詳細は以下を参照ください👇 eeengineer.com/linux-latency… #Linux #PerformanceEngineering #PSI #Memory #LinuxPerformance

Why doesn't the CPU always access main memory directly? Because memory latency matters. Modern CPUs use a cache hierarchy to keep frequently accessed data closer to the CPU: L1 → L2 → L3 → Main Memory L1: Fastest, smallest L2: Larger, but slower L3: Larger and typically shared by multiple cores DRAM: Much larger, but much slower than CPU caches This hierarchy reduces the need to access DRAM for frequently used data and helps the CPU spend more time executing instructions instead of waiting for memory. I explain Linux and computer architecture concepts with diagrams on my blog. eeengineer.com/en/cpu-cache-… #Linux #CPU #Cache #Memory #ComputerArchitecture #PerformanceEngineering #OperatingSystems

What actually happens when an application calls open() in Linux? It’s more than simply “open the file.” The basic flow is: Application ↓ Path Resolution (VFS) ↓ dentry — associates the filename with an inode ↓ inode — manages file metadata ↓ struct file — represents the state of the open file ↓ File Descriptor — the number used by the process A key point: Filename ≠ inode ≠ File Descriptor I explain Linux internals with diagrams on my blog. eeengineer.com/en/linux-file… #Linux #LinuxKernel #Filesystem #VFS #SystemCall #FileDescriptor #OperatingSystems

LinuxのI/Oが遅いとき、iostatのどこを確認していますか？ 特に重要なのが、awaitとaqu-szの違いです。 ① w_await：書き込みI/Oの平均所要時間（待機＋処理） ② aqu-sz：平均未完了I/O数（待機中＋処理中） ③ %util：デバイスにI/O要求があった時間の割合 awaitが高ければI/Oの遅延、aqu-szが増えれば未完了I/Oの蓄積を疑います。 ただし、%utilが100%に近くても、SSDなどでは必ずしも性能限界とは限りません。 LinuxのI/OについてKindle本（Kindle unlimited）を書いているので、興味があったら見てみてください👇 amazon.co.jp/dp/B0HHCYDMNP #Linux #iostat #パフォーマンス分析 #インフラエンジニア

How does the CPU know that a NIC has received a packet? The NIC can notify the CPU through a hardware interrupt. The basic flow is: NIC receives a packet ↓ NIC generates an interrupt ↓ Interrupt controller receives it ↓ CPU is notified ↓ Interrupt handler runs ↓ Original task resumes The key idea is that the CPU doesn't need to continuously check every device. Interrupts allow the system to respond to device events while continuing normal task execution. I explain Linux and OS internals with diagrams on my blog. eeengineer.com/en/linux-inte… #Linux #LinuxKernel #Interrupt #HardwareInterrupt #NIC #CPU #OperatingSystems #SystemsProgramming

What actually happens when Linux executes read() and write()? The key is the Page Cache. For read(): Application → Page Cache Cache Hit → data can be returned from memory Cache Miss → read from storage → load into Page Cache → return data For write(): Application → Page Cache → Dirty Page → Writeback → Storage A normal buffered write can complete after updating the Page Cache, while the actual storage writeback happens later. I explain Linux I/O internals with diagrams on my kindle book. amazon.com/dp/B0HP6DWQ82 #Linux #LinuxKernel #PageCache #IO #Storage #PerformanceEngineering #OperatingSystems

Oracle Databaseの「Non-CDB」と「CDB/PDB」、何が違うのでしょうか？ 最大の違いは、Instanceを共有できるかどうかです。 🔹 Non-CDB ・Databaseごとに独立したInstance ・SGAやBackground Processも個別に管理 ・障害影響を分離しやすい 🔹 CDB/PDB ・複数PDBでInstanceを共有 ・Resourceや運用管理を共通化 ・PDBごとにSchemaやDataを論理的に分離 CDB/PDBはResource効率に優れる一方、Resource競合や障害影響の拡大には注意が必要です。 詳細は以下を参照ください👇 eeengineer.com/oracle-cdb-pd… #OracleDatabase #Oracle #Database #インフラエンジニア

What actually happens when an application calls read() on Linux? A simple read() call crosses the user space / kernel space boundary and can involve several steps: Application → read() → Kernel → File Descriptor → Page Cache If the data is already in the Page Cache, Linux can read it from memory. If not: Page Cache Miss → Storage I/O → Load into Page Cache → Copy to User Space Then the kernel returns the number of bytes read, and the application continues execution. I explain Linux internals and performance concepts with diagrams on my blog. eeengineer.com/en/linux-user… #Linux #LinuxKernel #SystemCall #PageCache #StorageIO #OperatingSystems #PerformanceEngineering

How does Linux decide which task gets the CPU next? With legacy CFS, the scheduler primarily selected the runnable task with the smallest vruntime. With EEVDF, the selection is based on two steps: 1. Eligibility → Is the task eligible to receive CPU time? 2. Virtual Deadline → Among eligible tasks, which has the earliest virtual deadline? So the basic flow becomes: Runnable Tasks → Eligibility → Virtual Deadline → Select → Run I explain Linux CPU scheduling concepts with diagrams in my blog. eeengineer.com/en/linux-cpu-… #Linux #LinuxKernel #CPU #Scheduler #CFS #EEVDF #OperatingSystems #PerformanceEngineering

「自分はどんな人生を送りたいのか？」 人生でやりたいことを100個考えてみようと意気込みましたが、70個程度しか思いつかず。。。 特に大切にしたいのは、 ・家族や大切な人との時間 ・心身の健康 ・自分が楽しいと思える仕事 ・他人と比較しない、自分らしい生き方 仕事や自己成長だけでなく、人生全体を豊かにしていきたいですね。 note.com/think_clearly/n/n98… #バケットリスト #人生設計 #ITエンジニア