由于我的环境宿主机是一台64c笔记本，16c64g，
安装的企业版v425版本，每台OBServer虚机给到5c18g，启动后发现：
第一节点load值100+，二三节点load值10+
cpu最多都是OBServer消耗的，OBServer日志未见ERROR，至多只有wdiag和ediag，大概是说一阶段各种超时，且OBServer一直在初始化。
感觉一节点的load高导致初始化不能完成，但又看不出为啥OBServer cpu开销如此之大。
3 个赞
配置是不是不够啊
3 个赞
配置确实有点极限压榨了，可我也没办法，真的一滴也挤不出来了……哈哈
2 个赞
装 3 个 虚拟机太消耗资源。
windows 里装一个 wsl2，用 ubuntu 系统。改 wsl 参数，让wsl 能使用的内存上限到 38G.
然后单机起3个进程 （cpu_count=8,memory_limit=12G,datafile_size=50G,log_disk_size=50g) 也可以组建集群（软件目录和数据目录都分开）。
2 个赞
根据文档库中的信息，以下是一些可能的原因和排查建议：
1. OBServer 节点初始化问题
- 根据文档片段 4 的信息：
- 错误码
8001表示 OBServer 节点在启动过程中收到 RPC 请求。 - 解决方式是等待 OBServer 节点重启完成。
- 错误码
- 如果 OBServer 一直在初始化状态，可能是由于资源不足或配置问题导致初始化无法完成。
2. 资源分配问题
- 根据文档片段 5 的信息：
- 磁盘划分不合理可能导致 I/O 资源竞争。如果系统日志、事务日志和数据文件位于同一块磁盘上，可能会导致性能下降。
- 建议分别挂载三块磁盘并使用 SSD 存储，或者对磁盘进行分区。
- 可以开启日志限流功能，控制系统日志所能占用的磁盘 I/O 带宽上限。例如：
alter system set syslog_io_bandwidth_limit='10M'; - 开启回收系统日志功能并设置最大文件数量。例如：
alter system set enable_syslog_recycle = true; alter system set max_syslog_file_count = 1000;
3. CPU 资源不足
- 根据文档片段 8 的信息：
- 当集群租户请求量升高或复杂的查询处理时，CPU 资源不足会导致队列请求积压，表现为 SQL 响应时间变长。
- 您提到第一节点的 load 值非常高（100+），而其他节点相对较低（10+）。这可能是因为第一节点承担了更多的工作负载，或者存在线程调度不均的问题。
4. 硬件资源限制
- 您的环境确实非常极限：宿主机为 64 核 CPU 和 16 核 64GB 内存，每台 OBServer 虚机分配了 5 核 CPU 和 18GB 内存。
- 这种情况下，建议检查以下几点：
- 是否有其他进程占用了大量 CPU 或内存资源。
- 是否可以适当调整 OBServer 的资源配置，例如减少 CPU 核数或增加内存。
5. 健康检查
- 根据文档片段 1 的信息：
- 在排查任何应急事件之前，建议先执行 OB 集群健康检查。
- 确认以下基础问题是否已经排除：
- NTP 时钟是否同步。
- 日志磁盘、数据磁盘空间是否已满。
- 机房网络是否抖动。
- 负载均衡设备/组件（如 F5/LVS 等）是否故障。
6. 进一步排查
- 如果上述方法仍无法解决问题，可以尝试以下步骤：
- 查看 OBServer 的详细日志，尤其是 wdiag 和 ediag 中提到的超时信息。
- 使用 OCP Express 或其他监控工具查看集群的资源使用情况，确认是否存在特定租户或任务占用过多资源。
- 如果可能，尝试减少 OBServer 的工作负载，例如暂停非必要的任务或减少并发请求。
总结
- 第一节点的高 load 值可能是由于资源不足或线程调度不均导致的。
- 建议优化磁盘划分、调整资源配置，并执行集群健康检查。
- 如果问题仍然存在，请提供更多日志信息以便进一步分析。
希望以上建议能帮助您解决问题！
检索到的文档如下:
1 个赞
谢谢
1 个赞
确实很吃配置
1 个赞
现在勉强够用。哈哈