<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" 
  xmlns:content="http://purl.org/rss/1.0/modules/content/" 
  xmlns:dc="http://purl.org/dc/elements/1.1/" 
  xmlns:atom="http://www.w3.org/2005/Atom" 
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" 
  xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Io on Mark 的滿紙方糖言</title>
    <link>https://blog.mygraphql.com/zh/tags/io/</link>
    <description>Recent content in Io on Mark 的滿紙方糖言</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh</language>
    <managingEditor>labile.zhu@gmail.com (Mark Zhu)</managingEditor>
    <webMaster>labile.zhu@gmail.com (Mark Zhu)</webMaster>
    <copyright>Mark Zhu ©2026, All Rights Reserved</copyright>
    <lastBuildDate>Sat, 23 Sep 2023 03:12:15 +0800</lastBuildDate>
    
        <atom:link href="https://blog.mygraphql.com/zh/tags/io/index.xml" rel="self" type="application/rss+xml" />
    

      
      <item>
        <title>eBPF 求证坊间传闻：Java GC 日志可导致整个 JVM 服务卡顿？</title>
        <link>https://blog.mygraphql.com/zh/notes/java/java-gc-log-stuck/</link>
        <pubDate>Sat, 23 Sep 2023 03:12:15 +0800</pubDate>
        <author>labile.zhu@gmail.com (Mark Zhu)</author>
        <atom:modified>Sat, 23 Sep 2023 03:12:15 +0800</atom:modified>
        <guid>https://blog.mygraphql.com/zh/notes/java/java-gc-log-stuck/</guid>
        <description>&lt;p&gt;&lt;img src=&#34;https://blog.mygraphql.com/zh/notes/java/java-gc-log-stuck/index.assets/logo.png&#34; alt=&#34;image-20230924103632524&#34;&gt;&lt;/p&gt;
&lt;p&gt;[TOC]&lt;/p&gt;
&lt;h2 id=&#34;概述&#34;&gt;概述&lt;/h2&gt;
&lt;p&gt;实现世界的 Java 应用，都会记录 GC 日志。但不是所有人都知道小小的日志可能导致整个 JVM 服务卡顿。本文尝试用 eBPF 等分析方法，去证明具体环境下，问题的存在与否。&lt;/p&gt;</description>
        
        <dc:creator>Mark Zhu</dc:creator>
        
        
        
        
          
            
              <category>java</category>
            
          
            
              <category>jvm</category>
            
          
            
              <category>gc</category>
            
          
            
              <category>kernel</category>
            
          
            
              <category>io</category>
            
          
        
        
        
      </item>
      
      <item>
        <title>eBPF 求证坊间传闻：mmap &#43; Java Safepoint 可导致整个 JVM 服务卡顿？</title>
        <link>https://blog.mygraphql.com/zh/notes/java/java-reach-safepoint-stalled/</link>
        <pubDate>Sat, 23 Sep 2023 03:12:15 +0800</pubDate>
        <author>labile.zhu@gmail.com (Mark Zhu)</author>
        <atom:modified>Sat, 23 Sep 2023 03:12:15 +0800</atom:modified>
        <guid>https://blog.mygraphql.com/zh/notes/java/java-reach-safepoint-stalled/</guid>
        <description>&lt;p&gt;&lt;img src=&#34;https://blog.mygraphql.com/zh/notes/java/java-reach-safepoint-stalled/index.assets/logo.jpg&#34; alt=&#34;logo&#34;&gt;&lt;/p&gt;
&lt;p&gt;[TOC]&lt;/p&gt;
&lt;h2 id=&#34;概述&#34;&gt;概述&lt;/h2&gt;
&lt;p&gt;Java 支持好几种文件读取方法，本文要说的是小众的 &lt;code&gt;mmap(MappedByteBuffer)&lt;/code&gt; 以及它与 Safepoint、JVM 服务卡顿之间的关系。本文尝试用 eBPF 等分析方法，去证明具体环境下，问题的存在与否。&lt;/p&gt;</description>
        
        <dc:creator>Mark Zhu</dc:creator>
        
        
        
        
          
            
              <category>java</category>
            
          
            
              <category>jvm</category>
            
          
            
              <category>safepoint</category>
            
          
            
              <category>kernel</category>
            
          
            
              <category>io</category>
            
          
        
        
        
      </item>
      
      <item>
        <title>如何测量进程级别或容器级别的 IO 延迟</title>
        <link>https://blog.mygraphql.com/zh/posts/low-tec/kernel/task-io-accounting/</link>
        <pubDate>Sat, 23 Sep 2023 03:12:15 +0800</pubDate>
        <author>labile.zhu@gmail.com (Mark Zhu)</author>
        <atom:modified>Sat, 23 Sep 2023 03:12:15 +0800</atom:modified>
        <guid>https://blog.mygraphql.com/zh/posts/low-tec/kernel/task-io-accounting/</guid>
        <description>&lt;h2 id=&#34;概述&#34;&gt;概述&lt;/h2&gt;
&lt;p&gt;IO 延迟问题几乎是每个生产系统都会或多或少遇到的问题。虽然现在 NVMe + SSDs 已经可以到达 10Gbytes/s 的呑吐量，价格也非常亲民。但 IO 延迟问题不会消失。因为：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;一些基于网络的的存储方案，如 Ceph，天然地有不稳定性&lt;/li&gt;
&lt;li&gt;SSD / RAIN Controller 本身的不稳定性&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在 Linux 下，传统地，我们有 iostat / sar 等等工具可以看系统级、存储设备级的问题。但均不能告诉你以下几点：&lt;/p&gt;</description>
        
        <dc:creator>Mark Zhu</dc:creator>
        
        
        
        
          
            
              <category>linux</category>
            
          
            
              <category>kernel</category>
            
          
            
              <category>io</category>
            
          
        
        
        
      </item>
      

    
  </channel>
</rss>
