代码之家 › 专栏 › 技术社区 › Utsav

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

kdb

0

Utsav · 技术社区 · 6 年前

缓慢的消费者会杀死或减慢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被杀死或减慢?

0 回复 | 直到 6 年前

1

5

terrylynch 6 年前

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

理想情况下,生产tickerplant将具有某种形式的监视,定期监视输出队列-如果队列超过某个阈值,则应停止订阅(暂时从.u.w订阅字典中删除句柄,允许队列耗尽),并在订阅方赶上时恢复订阅。或者更积极地完全关闭订阅服务器连接(hclose),这会清除输出队列。

如果您的系统经历了大量的排队,那么tickerplant也可能需要每天进行垃圾收集(比如在EOD时),以确保输出队列没有导致其保留未使用的内存(或者您可能希望将其保留在未使用的内存中,以便下次出现大队列时不必从操作系统重新请求内存)

2

3

Callum Biggs 6 年前

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

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