<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
  <channel>
    <title>Malloc_trim - 标签 - William</title>
    <link>https://williamlfang.github.io/tags/malloc_trim/</link>
    <description>Malloc_trim - 标签 | William</description>
    <generator>Hugo -- gohugo.io</generator><language>zh-CN</language><lastBuildDate>Fri, 02 Oct 2026 22:30:00 &#43;0900</lastBuildDate><atom:link href="https://williamlfang.github.io/tags/malloc_trim/" rel="self" type="application/rss+xml" /><item>
  <title>tmux lag, round 2: every status-bar fork froze the server for 30 ms</title>
  <link>https://williamlfang.github.io/2026-10-02-tmux-lag-round-2/</link>
  <pubDate>Fri, 02 Oct 2026 22:30:00 &#43;0900</pubDate>
  <author>william</author>
  <guid>https://williamlfang.github.io/2026-10-02-tmux-lag-round-2/</guid>
  <description><![CDATA[<p>Two days after the
<a href="/2026-09-30-tmux-status-bar-lag/">last fix</a>, my tmux was laggy
again, and the server was back at about a quarter of a CPU core. The culprit was
the same as last time: the status bar&rsquo;s <code>#()</code> jobs. This time, though, the
number of jobs wasn&rsquo;t the problem. Each one had become slow, because every job
is a fork of the whole tmux server and my server had grown to 1.5 GB.</p>
<p>This post covers how I measured it, where the 1.5 GB came from (mostly the
scrollback of three panes), and the fixes. One of them corrects a claim in my
previous post.</p>]]></description>
</item>
</channel>
</rss>
