58 lines
1.7 KiB
Markdown
58 lines
1.7 KiB
Markdown
|
# 【K现场】首页Dashboard报错
|
|||
|
|
|
|||
|
|
| ID | Creation Date | Assignee | Status |
|
|||
|
|
|----|----------------|----------|--------|
|
|||
|
|
| OMPUB-434 | 2022-04-06T21:19:07.000+0800 | 戚岱杰 | 已关闭 |
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
首页登录后Dashboard有报错信息，通过接口返回值查看为，top app返回查询异常。**qidaijie** commented on *2022-04-08T10:11:35.764+0800*:
|
|||
|
|
|
|||
|
|
报错原因：部分Druid historical进程启动失败，无法加载traffic_app_stat_log所需的segment，导致界面查询报错。
|
|||
|
|
|
|||
|
|
查看Druid日志发现：
|
|||
|
|
# historical进程在反复重启，每次重启因内存溢出导致启动失败，服务器有大量程序崩溃日志hs_err_pid.log，报错内容均为OutOfMemoryError。
|
|||
|
|
# 进程所占内存未达到上限，服务器内存也有大量剩余，启动失败原因是加载segment时所需的内存映射地址不足，致使启动失败。
|
|||
|
|
|
|||
|
|
出现该问题有两方面原因：
|
|||
|
|
# rc3与21.09版本混部，表的数量翻倍，需要加载的segment也会相应翻倍，每个historical进程加载的数量变大，且rc3版本未开启压缩功能，不会合并小文件。目前集群所需加载segment数量是200W+，不仅影响进程启动，可能也会造成慢查询现象。
|
|||
|
|
# 内存文件映射打开数量不够，官方建议调整Linux vm.max_map_count参数，默认参数是65536，建议调大到655360。
|
|||
|
|
|
|||
|
|
解决方案：
|
|||
|
|
# 提供segment压缩脚本，rc3版本表也开启压缩任务。
|
|||
|
|
# 修改系统参数vm.max_map_count为655360。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## Attachments
|
|||
|
|
|
|||
|
|
**26845/bifang页面报错排查过程.docx**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**26844/compaction-v2.tar.gz**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**26879/historical_log.jpg**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**26880/historical进程崩溃.jpg**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**26881/traffic_app未加载成功.jpg**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**26882/加载的segment数量.jpg**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|