Sửa lỗi Elasticsearch: vm.max_map_count [65530] is too low

Vấn đềElasticsearch thường bị crash trong giai đoạn bootstrap nếu hệ điều hành host không được tinh chỉnh cho các tác vụ database nặng. Nếu node của bạn không khởi động được, hãy kiểm tra log bằng lệnh docker logs hoặc theo dõi các file trong /var/log/elasticsearch/. Bạn có thể sẽ thấy một lỗi nghiêm trọng thông báo rằng vm.max_map_count đang ở mức 65530, vốn là mặc định trên hầu hết các bản phân phối Linux.

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Đây không chỉ là một gợi ý; đó là yêu cầu bắt buộc đối với môi trường production. Elasticsearch mặc định sử dụng thư mục mmapfs để lưu trữ các index. Giới hạn mặc định của Linux là 65.530 vùng memory map đơn giản là quá nhỏ để Lucene có thể map các segment một cách hiệu quả, dẫn đến các ngoại lệ out-of-memory hoặc lỗi khởi động.

Cách kiểm tra và xác nhậnTrước khi thay đổi bất cứ điều gì, hãy kiểm tra cài đặt kernel hiện tại của bạn. Mở terminal và chạy lệnh sau:

cat /proc/sys/vm/max_map_count

Hoặc, sử dụng công cụ sysctl để truy vấn giá trị:

sysctl vm.max_map_count

Nếu terminal trả về 65530, bạn đã tìm thấy điểm nghẽn. Bạn cần tăng con số này lên ít nhất 262.144 để đáp ứng các kiểm tra bootstrap của Elasticsearch.

Giải phápBạn có thể áp dụng bản sửa lỗi ngay lập tức cho phiên làm việc hiện tại hoặc thiết lập vĩnh viễn để cấu hình này vẫn tồn tại sau khi khởi động lại server.

1. Sửa lỗi tạm thời (Có hiệu lực ngay)Để cụm (cluster) của bạn hoạt động trở lại ngay lập tức mà không cần khởi động lại server, hãy cập nhật tham số kernel đang chạy. Bạn sẽ cần quyền root hoặc sudo:

sudo sysctl -w vm.max_map_count=262144

Thay đổi này có hiệu lực ngay khi bạn nhấn Enter. Bây giờ bạn có thể khởi động lại dịch vụ Elasticsearch hoặc container Docker, và nó sẽ vượt qua bước kiểm tra bootstrap.

2. Sửa lỗi vĩnh viễn (Duy trì sau khi khởi động lại)Lệnh trên chỉ tồn tại trong bộ nhớ tạm thời của hệ thống. Nếu server khởi động lại, giới hạn sẽ quay về 65530. Để thay đổi này có hiệu lực vĩnh viễn, bạn phải chỉnh sửa file sysctl.conf.

• Mở file cấu hình bằng trình soạn thảo văn bản như Nano:sudo nano /etc/sysctl.conf- Thêm dòng này vào cuối file:vm.max_map_count=262144- Lưu và thoát (Trong Nano, nhấn Ctrl+O, sau đó Enter, rồi Ctrl+X).- Tải lại các thiết lập để áp dụng ngay lập tức:``` sudo sysctl -p

## Trường hợp đặc biệt: Docker và WSL2### Người dùng DockerMột sai lầm phổ biến là cố gắng thiết lập `vm.max_map_count` bên trong `Dockerfile` hoặc file `docker-compose.yml`. Vì đây là một **tham số cấp kernel**, các container không thể sửa đổi nó. Bạn phải áp dụng bản sửa lỗi trên **máy host**—server Linux thực tế hoặc máy ảo đang chạy Docker engine. Khi host được cập nhật, mọi container chạy trên đó sẽ tự động sử dụng giới hạn mới.
### Người dùng Windows (WSL2)Nếu bạn đang chạy Docker Desktop trên Windows thông qua WSL2, host thực chất là một máy ảo tiện ích ẩn. Bạn cần thiết lập giới hạn tại đó:
- Mở PowerShell.- Truy cập terminal WSL2: `wsl -d docker-desktop`.- Thiết lập tham số: `sysctl -w vm.max_map_count=262144`.- Để thiết lập này vĩnh viễn trên Windows, hãy tạo hoặc chỉnh sửa file `.wslconfig` trong thư mục profile người dùng của bạn (ví dụ: `C:\Users\Admin\.wslconfig`) và thêm các dòng sau:```
[wsl2]
kernelCommandLine = "vm.max_map_count=262144"

Xác minh cuối cùngKiểm tra kỹ xem hệ thống đã ghi nhận giá trị mới chưa trước khi thử khởi động lại các dịch vụ của bạn:

sysctl vm.max_map_count

Nếu nó trả về 262144, hãy tiến hành khởi chạy dịch vụ của bạn:

# Cho người dùng Docker Compose
docker-compose up -d

# Cho người dùng Systemd
sudo systemctl restart elasticsearch

Các lưu ý quan trọng- Kernel chia sẻ: Các container chia sẻ kernel của host. Bạn không thể sửa đổi giới hạn kernel từ bên trong môi trường container tiêu chuẩn.- Kiểm tra Bootstrap: Elasticsearch bắt buộc thực hiện các giới hạn này khi phát hiện nó đang ở "chế độ production" (ví dụ: khi bind với một IP không phải loopback). Điều này giúp ngăn ngừa hỏng dữ liệu và giảm hiệu suất.- Sử dụng bộ nhớ: Việc tăng giới hạn này thực chất không tiêu tốn thêm RAM. Nó chỉ đơn giản là cung cấp cho kernel "không gian" cần thiết để quản lý nhiều file memory-map hơn, điều này rất quan trọng đối với việc lập chỉ mục tìm kiếm hiệu suất cao.