能否在kdb中降低实时订户kill tickerplant的速度

缓慢的消费者会杀死或减慢tickerplant吗

我有一个自动售票机工厂，有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或使其减速？

是的，速度慢的使用者可以杀死tickerplant。慢速使用者在tickerplant中创建输出队列，该输出队列消耗内存。最终，如果它运行的时间足够长，tickerplant或运行它的机器可能会耗尽内存并中止

理想情况下，生产tickerplant将具有某种形式的监视，定期监视输出队列-如果队列超过某个阈值，则应暂停订阅，暂时从.u.w订阅字典中删除句柄，如果/当订阅方赶上时，允许队列排空并恢复。或者更具攻击性，完全关闭订阅服务器连接，从而清除输出队列

---

如果您的系统经历了大量的排队，那么tickerplant可能也需要每天进行垃圾收集，比如在EOD时，以确保输出队列没有导致其保留未使用的内存，或者您希望将其保留在未使用的内存中，以便下次出现大队列时不必从操作系统重新请求内存答案是100%正确。我只想在订户速度慢的TP中扩展对垃圾收集的需求

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

在TP中正常执行期间，发布的数据永远不是引用的对象，而是随后发布的传入消息的参数。因此，不存在触发自动垃圾回收的对象取消引用