---
title: vm.max_map_count 参数设置错误导致 OBServer 频繁被 OOM-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于vm.max_map_count 参数设置错误导致 OBServer 频繁被 OOM相关的常见问题和使用技巧，帮助您快速解决vm.max_map_count 参数设置错误导致 OBServer 频繁被 OOM的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# vm.max_map_count 参数设置错误导致 OBServer 频繁被 OOM

更新时间：2026-08-25 02:41

适用版本： V4.2.x 内容类型：Troubleshoot  

## 问题现象

OBServer 进程被频繁 OOM Kill。通过 `grep -i "oops"` 或 `grep "CHUNK_MGR"` 查看日志，可以看到 `virtual_memory_used` 非常高，远高于物理内存。其中 OceanBase 4.x 版本发生最多，其他版本可能也适用。

## 问题原因

OBServer 服务器的操作系统参数 `vm.max_map_count` 设置不满足要求：

```bash
sysctl -a | grep max_map_count

```

输出结果：

```plain
vm.max_map_count = 65530

```

`vm.max_map_count` 控制进程可分配的虚拟内存区域（virtual_memory_area）的数量。当不连续的虚拟内存区域数量超过该值时，后续的内存分配就可能失败。

当前环境 `vm.max_map_count=65530`，远低于最佳实践值 655360。按 OBServer 一次内存申请为 2M 的粒度来估算，最差情况下申请 128G 内存就会达到 65530 个虚拟内存区域。该环境的实际内存占用是 600G+，已经远超 128G。

## 关键信息

暂无额外诊断信息。通过检查 `vm.max_map_count` 参数值和日志中的 `virtual_memory_used` 即可判断。

## 问题的风险及影响

OBServer 进程被频繁 OOM Kill，导致数据库服务中断。

## 影响租户

该 OBServer 节点上的所有租户均受影响。

## 适用版本

OceanBase 所有版本。

## 解决方法

永久修改此参数，将 `vm.max_map_count` 设置为 655360：

```bash
echo "vm.max_map_count=655360" >> /etc/sysctl.conf
sysctl -p

```

修改后重启 OBServer。

## 规避方式

确保 `vm.max_map_count` 参数设置为推荐值 655360。

Previous

[如何手工重启一个 OBServer 进程](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006894154)

Next

[ussl-hook 模块中并发问题导致 OBServer 可能拉起失败](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000008230) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线