具体来说，名为dbsrv10的进程始终与100％或更多的CPU使用率挂钩。
我已经尝试使用这些命令清除队列flush：zman queue-flush F zman queue-flush S
但是，这只能解决大约20分钟的CPU。
我在VMWare 3.5上运行SLES10 SP2上的ZCM 10.2.0。
我最近完全禁用了补丁pipe理，因为它导致了磁盘空间问题。
我的loader-messages.log文件总是非常繁忙，也许有人可以理解这一点：
[DEBUG] [8/4/09 9:29:19 AM] [] [Loader.Status Storer模块] [] [目录失败大小：1763657] [] [] [DEBUG] [8/4/09 9:29 ：上午19点] [] [Loader.Status存储模块] [] [移动状态_b11714bce362d4ea7e377f550b19e8aa_1249396137593.xml到失败的目录。] [] [] [DEBUG] [8/4/09 9:29:49 AM] [] [Loader .Status Storer模块] [] [Loader.Status Storer模块] [] [失败的目录大小： 1766252] [] [] [DEBUG] [8/4/09 9:29:49 AM] [] Loader.Status Storer模块] [移动Status_f8bbe0db5ba4f3a5d3d5e97b3ca01f52_1249396185 656.xml到失败的目录。] [] [] [DEBUG ] [8/4/09 9:29:49 AM] [] Loader.Status Storer模块] [] [处理Status_f8bbe0db5ba4f3a5d3d5e97b3ca01f52_1249396185 546.xml] [] [] [DEBUG] [8/4/09 9:29:49 AM] [] [Loader.Status Storer模块] [] [failed目录大小：1766856] [] [] [DEBUG] [8/4/09 9:29:49 AM] [] Loader.Status Storer模块] [移动Status_f8bbe0db5ba4f3a5 d3d5e97b3ca01f52_1249396185 546.xml to failed。] [] [] [DEBUG] [Loader.Status Storer Module] [] [Processing Status_f8bbe0db5ba4f3a5d3d5e97b3ca01f52_1249396188 625.xml] [] [ [Loader.Status Storer Module] [] [failed目录大小：1767460] [] [] [DEBUG] [8/4/09 9： [] Loader.Status Storer模块] [] [移动Status_f8bbe0db5ba4f3a5d3d5e97b3ca01f52_1249396188 625.xml到失败的目录。] [] [] [DEBUG] [8/4/09 9:30:19 AM] [] [ [Loader.Status Storer模块] [] [处理状态_194d59f476961bd4f04510f0bb6b0d0e_1249396194 937.xml] [] [] [DEBUG] [8/4/09 9:30:20 AM] [] Loader.Status Storer模块] []目录大小失败：[1768064] [] [] [DEBUG] [8/4/09 9:30:20 AM] [] [Loader.Status Storer模块] [] [移动Status_194d59f476961bd4f04510f0bb6b0d0e_1249396194 937.xml到失败的目录。] [] [] [ DEBUG] [8/4/09 9:31:50 AM] [] [Loader.Status Storer模块] [] [处理状态_488000110f3c7d43b318bc49c7aecca2_1249396293 406.x ml] [] [] [] [DEBUG] [8/4/09 9:31:50 AM] [] Loader.Status Storer模块] [处理状态_c1f956e7e93b594c8404e25478782c07_1249396280 468.xml] [] [] [DEBUG] [8 / 4/09 9:31:50 AM] [Loader.Status Storer模块] [] [Processing Status_db44b8158529bf5031c1597d85530d76_1249396283 593.xml] [] [] [DEBUG] [8/4/09 9:31:50 AM] [] [Loader.Status Storer模块] [] [失败的目录大小：1770464] [] [] [DEBUG] [8/4/09 9:31:50 AM] [] Loader.Status Storer模块] [移动Status_db44b8158529bf5031c1597d85530d76_1249396283 593.xml到失败的目录。] [] [] [] [DEBUG] [Loader.QueueRunner] [] [没有处理程序注册为动作ID：30626，types：SUBSCRIPTION_DOWNLOAD ] [] []
我认为这与来自正在处理的客户端的库存文件有关。 Storer和XML文件是库存过程的过程和数据文件。
ZCM的哪个版本？ 如果可能的话，10.2就是你想要的地方。
我应该build议在support.novell.com的ZCM论坛上发帖，但是他们没有得到正式的支持，那里有志愿者的pipe理员，谁可以帮忙。
为什么ZCM服务器要经常处理这些设备的库存？ 库存计划设置为3小时（部分为1.5）。
我正在运行ZCM 10.2。
Karl，你有联系到维基的所有者吗？ 我似乎无法在网站上find任何个人信息。
哇，这很糟糕，看起来Novell不太支持这个产品。 难怪我们还没有推出这个产品呢…
我在Novell的论坛中发现的一个有用的post，除了清除排队的事情是这一个 。
这家伙的网站似乎是相当有帮助的…如果你不能弄明白，你可能会直接与他联系。
我也在SLES SP2 / ZCM 10.2.0 / ESX 3.5.4中遇到过这个问题。我的虚拟机只运行一个vCPU，而kernel-vmi
到目前为止，我只在DB进程上做了一个“不错的10”。 不是我想要的，但是。
您必须删除旧的禅宗7导入的包。 一些（也许很多）包含错误，只是把周期的屋顶。 我们这样做，CPU使用率下降到地板上。 kfreise发现了这一点，只是忘了发布！