如何识别 ctp 中的慢速订阅者？答案

【问题标题】：how to identify slow subscribers in ctp?如何识别 ctp 中的慢速订阅者？
【发布时间】：2021-12-07 10:49:40
【问题描述】：

我有一个 CTP，我有大约 12-13 个 procs 订阅同一个表。

直到最近下午 1 点到 3 点左右，该表的数据流增加了两倍时，它才出现问题。

//counts by hour

©¬ time x
2021.10.20D10:00:00.000000000   2.861138
2021.10.20D11:00:00.000000000   6.550263
2021.10.20D12:00:00.000000000   12.427463
2021.10.20D13:00:00.000000000   15.083131
2021.10.20D14:00:00.000000000   10.690055
2021.10.20D15:00:00.000000000   4.285406

ctp 中没有花哨的逻辑。我可以看到 tp 正在努力发布到它。

当我在 ctp 中执行 count each .z.W 时...不是消息卡在句柄中。

如何找到我的慢速订阅者？

目前我必须终止 ctp 并重新启动所有连接。

UPDATE1：我的问题是 ctp 订阅速度较慢，但 ctp 的句柄中没有卡住消息。我应该假设处理缓慢是由于 upd 功能吗？

更新函数是：

(Roundtrip: 00:09.844)
{[t;x] t insert x;.u.jcounts[t]+:count x;}

这是一个非常基本的定义，不应引起这些问题。

【问题讨论】：

您是否在 ctp 中使用-25! 进行发布？
没有。我正在使用通用的 .u.pub 函数
我认为 CTP 可能是慢速订阅者。您的所有订阅者是否都获得了相同的数据，或者是否至少存在一些重叠？ -25！或者异步广播将数据序列化一次，以发布给想要相同内容的订阅者。 Kdb >= 3.4 支持它
链式tp是否处于批处理模式？你能分享system"t"和你的.u.pub

标签： kdb

【解决方案1】：

除了将花哨的客户端登录添加到您的自动收报机（Simon Garland 编写了原始模板：https://code.kx.com/q/kb/using-dotz/#tracking-clients-and-servers），我发现 netstat 很有用：

netstat -altnp | grep -e Proto -e 1234

在托管 CTP 的机器上运行它，并将 1234 替换为 CTP 的端口。这提供了有关谁连接到您的 CTP 的信息，还提供了接收队列和发送队列的详细信息。它给出了连接的程序/应用程序的 PID。它不会在盘子上为您提供答案，但应该可以帮助您知道在哪里寻找。

【讨论】：

嘿。非常感谢您的回复。我知道哪些进程连接到它，我只是不知道如何查看导致问题的进程。发布到 ctp 的 tp 有发布问题，但没有消息卡在 ctp 的句柄 (.z.W) 中，好像......没有慢速订阅者。所以.. atm 我认为问题出在 ctp 中的 ... upd 函数中？但是 upd 非常基本 --->>> (Roundtrip: 00:09.844) {[t;x] t insert x;.u.jcounts[t]+:count x;}
有人向您的 CTP 发送查询/命令吗？ .u.sub 和重播相关请求除外
毫米。我不希望任何人向这些 ctp 发送查询。这是一个内部ctp。我的问题是连接到它的 12 个进程中的哪一个导致了问题。我真的不知道如何调试。