可以减慢实时订阅者在kdb中杀死tickerplant答案

【问题标题】：Can slow real time subscriber kill tickerplant in kdb可以减慢实时订阅者在kdb中杀死tickerplant
【发布时间】：2020-03-22 07:56:00
【问题描述】：

一个缓慢的消费者可以杀死或减慢蜱虫吗？

我有一个自动收报机，它有 3 个实时订阅者，其中一个订阅者很慢。

q).z.W
7 | `long$()
8 | 969393 198 198 197 197 198 196 199 197 196 143 198 196 196 197 197 198 19..
9 | 199 198 198 143 197 199 197 197 197 197 199 196 199 145 196 198 198 198 1..
10| 198 196 198 144 199 198 198 198 196 197 196 199 198 143 199 198 197 198 1..

q)count each .z.W
7 | 0
8 | 85547
9 | 77931
10| 0

q)count each .z.W
7 | 0
8 | 191552
9 | 0
10| 0

在接收数十亿条记录的生产 kdb+ 系统中，缓慢的消费者能否杀死tickerplant 或减慢其速度？

【问题讨论】：

标签： kdb

【解决方案1】：

是的，一个缓慢的消费者可以杀死一株植物。慢消费者在tickerplant中创建输出队列，这个输出队列消耗内存。最终，如果它持续足够长的时间，tickerplant（或它正在运行的机器）可能会耗尽内存并中止。

理想情况下，生产自动收报机将具有某种形式的监控，定期监视输出队列 - 如果队列超过某个阈值，它应该停止订阅（暂时从 .u.w 订阅字典中删除句柄，允许queue to drain) 并在订阅者赶上时恢复。或者更激进地完全关闭订阅者连接（hclose），这会擦除输出队列。

如果您的系统遇到大量排队，那么tickerplant 可能还需要每天进行一次垃圾收集（比如在 EOD 时），以确保输出队列没有导致它持有未使用的内存（或者您可能希望保留它使用未使用的内存，以便下次出现大队列时不必从操作系统重新请求内存）

【讨论】：

【解决方案2】：

特里的答案是 100% 正确的。我只是想扩展在订阅速度较慢的 TP 中对垃圾收集的需求。

重要的是，这个集合是通过.Q.gc[] 实现的，而不是通过即时集合\g 1 实现的。仅当删除对对象的所有引用并将对象返回到堆时才会触发立即收集，如果大于 64MB 则触发收集。

在 TP 中正常执行期间，发布的数据永远不是引用对象，它是传入消息的参数，然后发布出去。因此，没有触发自动垃圾收集的对象取消引用。

【讨论】：