Sybase 轮询性能影响答案

【问题标题】：Sybase polling performance impactSybase 轮询性能影响
【发布时间】：2018-11-26 02:35:41
【问题描述】：

我们有一个 Sybase ASE 简单表，只有一列，如下所示

Table Name: Items
+------------+
|  itemId    | 
+------------+
| ABCDEFGH1  |
| ABCDEFGH2  |
+------------+
itemId is the primary key.

生产者会以不确定的速率使用数据填充此表。

我们有一个消费者（Java 进程）不断轮询这个表（使用 JDBC），通过这样做

SELECT TOP 5000 itemId FROM Items ORDER BY itemId desc

这些 itemId 将在成功处理后（例如每 200 毫秒）被消费者删除。 我们可以假设消费者总是比生产者快，这意味着表中的记录数很少会超过 5000。

我们不断进行轮询，因为我们希望尽快将更新发送给消费者，以模拟“推送”行为。

我的问题：

【问题讨论】：

我想这取决于您轮询的频率，因此您需要多长时间轮询消费者才能领先于生产者。
@TimBiegeleisen Sybase 是做什么的？由于使用“order by”对小表进行持续轮询，它会在内存缓存中放入任何内容吗？或者每次我在使用硬盘驱动器但 CPU 和内存消耗很少时？关于建立一个好的环境来测试这个有什么想法吗？或者这是因为使用的资源很少而几乎可以忽略的东西？
我不太了解 5000 行的固定轮询？如果生产者插入行直到某个点然后停止，然后在删除它们之前将它们拾取，那么生产者在单独的表中设置信号量/状态肯定会更好地允许它们之间进行一些交互而不是假设5k 行总是可以的？这使您能够执行“如果存在（从中选择 1 ...执行某些操作”类型的 SQL，它将轮询该表中的任何内容，并大大减少数据库的工作量，而不是读取 5k 键跨度>

【解决方案1】：

（假设这里只有一个消费者，所以消费者之间不需要协调）

如果 itemId 是主键（使用 itemId 列上的“主键”约束创建的表），则 Sybase 会在该列上隐式创建唯一聚集索引。

所以你的“top 5000”命令应该使用聚集索引来扫描表。我假设一旦消费者获得了一批行，它就会停止轮询/扫描，直到完成处理并删除已处理的 itemId。

所以您实际上是在谈论在表为空时频繁（轮询）运行“SELECT TOP 5000 itemId FROM Items”查询，对吧？

假设是这种情况（在空表上运行 select），它将运行得非常快，但如果您连续运行它，它可能会以每秒数千次空轮询耗尽所有 Sybase CPU。也许你说的是每秒轮询一次？应该没问题。

更多想法：

如果您开始谈论将键值递增到聚集索引的疯狂高插入率，那么您可能会涉及诸如优化聚集索引的页面拆分之类的事情。请参阅“升序插入的效果”：

我猜这不是你所在的地方。

本

【讨论】：

谢谢本。我很想知道为什么“它可能会用每秒数千个空轮询来耗尽你所有的 Sybase CPU。”。我假设“死循环”空表查询要么 1. 使用一些 IO，这意味着 CPU 不会太忙，因为 IO 慢得多 2. IO 不多，但在这种情况下，我假设 Sybase 已经缓存了桌子是空的（否则它怎么知道）？但是如果它以某种方式被缓存，我想它会使用非常少的 CPU 周期？
你每秒会调用多少次投票？如果你有一个只占用 1 毫秒 CPU 时间的 select 语句，但你称它为 1000 次/秒，那就是 100% 的 CPU。
我认为您错过了调用同步的要点，这意味着在第一次调用完成之前不会启动第二次调用。我们所说的规模更像是 IO 需要 1 秒才能完成，而 CPU 每次查询只需要 1 纳秒。