修改RDB作为发布者的效率及内存暴涨问题咨询

问题背景 #

我修改了RDB的r.q，让它具备发布结果的能力，方便q订阅者做后处理，后台运行原生tick.q。现在有两个核心问题：

1. 在r.q中使用.u.pub的方式是否高效？如果不高效，推荐什么方案？
2. 运行该RDB的q进程内存从基线1.5GB突然飙升至38.5GB，经常导致进程崩溃。基线内存和tick.q日志文件数据量匹配，但内存暴涨的情况很困惑。同时r.q运行时出现snd handle: 9. OS reports: Broken pipe警告。我怀疑是订阅者速度慢，但检查后发现订阅者每次迭代耗时约100ms，远低于1000ms的超时设置。

修改后的r.q代码 #

/q tick/r.q [host]:port[:usr:pwd] [host]:port[:usr:pwd]
/2008.09.09 .k ->.q

\l tick/u.q
\l tick/sym.q

if[not "w"=first string .z.o;system "sleep 1"];

upd:insert;

/ get the ticker plant and history ports, defaults are 5010,5012
.u.x:.z.x,(count .z.x)_(":5010";":5012");

/ end of day: save, clear, hdb reload
.u.end:{t:tables`.;t@:where `g=attr each t@\:`sym;.Q.hdpf[`$":",.u.x 1;`:.;x;`sym];@[;`sym;`g#] each t;};

/ init schema and sync up from log file;cd to hdb(so client save can run)
.u.rep:{(.[;();:;].)each x;if[null first y;:()];-11!y;system "cd ",1_-10_string first reverse y};
/ HARDCODE \cd if other than logdir/db

/ connect to ticker plant for (schema;(logcount;log))
.u.rep .(hopen `$":",.u.x 0)".u.sub[`;`];`.u `i`L";

/ modified section
.u.init[]

.z.ts:{.u.pub[`quote;quote]};
\t 1000

\p 5011

1. .u.pub在RDB中的效率问题 #

.u.pub本身是KDB+内置的轻量发布订阅机制，但你当前的用法并不高效，核心原因：

• RDB的核心职责是实时写入与查询，用定时任务.z.ts每秒全量发布quote表，会重复发送大量历史数据，浪费带宽和订阅者资源。
• 若quote表数据量较大，每秒序列化全表的开销会拖慢RDB的核心写入性能，甚至引发内存压力。

推荐方案 #

• 改用增量发布：不要全量推送整个quote表，而是只推送新增的数据。可以在upd函数中加入发布逻辑，示例：

  upd:{[t;x] insert[t;x]; .u.pub[`updQuote;(t;x)];}
  

  这样每次插入新数据时，只把增量推送给订阅者，避免重复发送历史数据。
• 分离发布职责：如果需要全量数据的定时快照，建议单独启动一个订阅进程，从RDB订阅增量并本地维护全量数据，再对外发布，不要让RDB承担额外的发布压力。

2. 内存暴涨与Broken Pipe问题 #

内存暴涨原因 #

你的代码中.z.ts:{.u.pub[quote;quote]}会每秒尝试序列化整个quote表并发送。如果订阅者接收不及时，KDB+会把待发送的数据缓存到内存中，随着时间推移，缓存的数据会越来越多，最终导致内存暴涨。即使订阅者单次处理耗时100ms，若每秒生成的quote`数据量较大，或订阅者在某些时段出现阻塞，都会导致发送队列积压，内存持续增长。

Broken Pipe警告原因 #

该警告表示RDB尝试向已经断开的连接发送数据，常见场景：

• 订阅者进程意外崩溃或主动断开，RDB未检测到连接关闭，仍尝试发送数据。
• 网络波动导致连接中断，RDB的连接状态未及时更新。

解决方案 #

• 替换全量发布为增量发布：减少待发送的数据量，从根源避免队列积压。
• 添加连接状态检测：发布前检查订阅者连接是否存活，示例：

  .z.ts:{if[count .u.pubConns; .u.pub[`quote;quote]];}
  

  （.u.pubConns是.u模块维护的订阅者连接列表，可通过.u.sub的回调函数跟踪连接状态）
• 调整发送参数：设置.z.so（发送超时）或限制待发送队列长度，避免无限制缓存数据。
• 监控关键指标：用-21!查看进程内存使用情况，用.u.pubConns查看订阅者连接状态，定位具体积压点。

内容的提问来源于stack exchange，提问作者marital_weeping