Xử lý nhanh trong 5 phút: Cách truy cập và điều hướng esxtop
Khi vCenter phản hồi chậm hoặc VM bị “đứng hình”, việc ngồi chờ biểu đồ giao diện web tải xong chỉ làm bạn thêm sốt ruột. Cách nhanh nhất là SSH trực tiếp vào host ESXi và gõ lệnh:
esxtopMàn hình mặc định sẽ hiển thị thông số CPU. Để soi các tài nguyên khác, bạn hãy dùng các phím tắt sau:
- c: Xem hiệu năng CPU.
- m: Kiểm tra chi tiết RAM (Memory).
- u: Xem thông số Disk Device (Dùng để check độ trễ ổ cứng – Latency).
- n: Theo dõi lưu lượng Network.
- f: Thêm hoặc ẩn các cột dữ liệu không cần thiết.
- V: Chỉ hiển thị các dòng của máy ảo (VM), loại bỏ các tiến trình nền của hệ thống.
Mẹo nhỏ: Sau khi đã tùy chỉnh các cột vừa ý, hãy nhấn W để lưu cấu hình vào file .esxtop4rc. Lần sau mở lại, mọi thứ sẽ hiển thị đúng ý bạn ngay lập tức.
Phân tích CPU: Tại sao %USED cao chưa chắc đã tệ?
Nhiều quản trị viên thường lo lắng khi thấy cột %USED tăng cao. Tuy nhiên, trong thế giới ảo hóa, %RDY (Ready Time) mới là chỉ số bạn cần đặc biệt quan tâm.
Chỉ số %RDY: Thước đo sự chờ đợi
Nó cho biết máy ảo đã sẵn sàng xử lý nhưng phải xếp hàng chờ host ESXi cấp phát tài nguyên CPU vật lý.
- Dưới 5%: Hệ thống đang vận hành rất tốt.
- 5% – 10%: Bắt đầu có hiện tượng nghẽn, người dùng sẽ cảm thấy ứng dụng hơi lag.
- Trên 10%: Mức báo động. Đây thường là hệ quả của việc gán quá nhiều vCPU cho một máy ảo (Over-provisioning).
Thực tế, mình từng xử lý một hệ thống Web Server được cấp tận 32 vCPU nhưng chạy cực chậm. Kiểm tra bằng esxtop, %RDY vọt lên 20%. Nguyên nhân là CPU scheduler phải đợi đủ 32 core vật lý rảnh cùng lúc mới cho VM chạy. Sau khi hạ xuống còn 4 vCPU, máy chạy mượt ngay lập tức. Hãy nhớ: Ít vCPU đôi khi lại mang lại hiệu năng cao hơn.
Chỉ số %CSTP (Co-stop)
Nếu %CSTP vượt ngưỡng 3%, các vCPU trong cùng một máy ảo đang bị mất đồng bộ. Điều này thường xảy ra khi bạn nhồi nhét quá nhiều máy ảo đa nhân (Multi-vCPU) vào một host có tài nguyên hạn hẹp.
Giải mã bài toán RAM: Khi nào cần nâng cấp phần cứng?
Nhấn m để chuyển sang tab Memory. Hãy nhìn vào dòng MEM Overcommit avg ở trên cùng. Nếu con số này lớn hơn 0, nghĩa là host của bạn đang phải gồng mình vì thiếu RAM vật lý.
Dưới đây là 3 thông số “tử thần” cần soi kỹ:
- MCTLSZ (MB): Lượng RAM bị thu hồi qua Balloon driver. Nếu số này lớn hơn 0, host đang phải “vay mượn” RAM từ VM này để cứu VM khác.
- SWCUR (MB): Lượng RAM đang bị đẩy xuống ổ cứng (Swap). Tốc độ ổ cứng chậm hơn RAM hàng trăm lần, nên nếu thấy số này lớn hơn 0, VM chắc chắn sẽ bị treo hoặc giật lag.
- ZIP/s (MB/s): Tốc độ nén RAM. ESXi sẽ nén dữ liệu để tiết kiệm không gian trước khi dùng đến Swap. Nếu số này nhảy liên tục, đã đến lúc bạn cần đặt mua thêm thanh RAM mới.
Storage và Network: Truy tìm thủ phạm gây nghẽn I/O
Đo độ trễ ổ cứng (Disk Latency)
Nhấn u để kiểm tra Disk Device. Đây là nơi bạn tìm ra nguyên nhân tại sao Database truy vấn chậm. Hãy tập trung vào 3 cột sau:
- DAVG/cmd: Độ trễ từ phía phần cứng (Storage/SAN). Nếu con số này > 20ms, hãy kiểm tra lại ổ cứng, cáp quang hoặc cấu hình SAN switch.
- KAVG/cmd: Độ trễ do Kernel của ESXi. Thông thường số này phải xấp xỉ bằng 0. Nếu nó cao (> 1ms), có thể do driver hoặc firmware của card RAID/HBA đang bị lỗi.
- GAVG/cmd: Tổng độ trễ thực tế mà máy ảo phải chịu (DAVG + KAVG).
Kinh nghiệm cho thấy, nếu dùng ổ SSD/NVMe mà GAVG vẫn trên 10ms thì chắc chắn hệ thống đang gặp vấn đề nghiêm trọng về cấu hình I/O.
Kiểm tra nghẽn mạng
Nhấn n để xem Network. Thay vì nhìn vào băng thông MB/s, hãy để ý cột %DRPRX và %DRPTX (Dropped Packets). Nếu thấy xuất hiện các con số khác 0, gói tin đang bị rơi rụng trên đường truyền. Nguyên nhân có thể do Switch vật lý bị quá tải hoặc driver VMXNET3 trong VM chưa được cập nhật bản mới nhất.
Nâng cao: Chạy esxtop ở chế độ Batch Mode
Nhiều lỗi hệ thống chỉ xảy ra chớp nhoáng vào lúc nửa đêm. Để bắt được các khoảnh khắc này, hãy dùng Batch mode để ghi dữ liệu vào file CSV:
esxtop -b -d 5 -n 200 > log_hieu_nang.csvLệnh trên sẽ ghi lại thông số 5 giây một lần, lặp lại 200 lần. Sau đó, bạn có thể tải file về máy, mở bằng Excel hoặc VisualEsxtop để vẽ biểu đồ và phân tích xu hướng.
Lời khuyên thực chiến cho System Admin
- Đừng quá tin vCenter: Dữ liệu trên vCenter thường có độ trễ nhất định.
esxtopcung cấp dữ liệu thời gian thực với độ chính xác tuyệt đối. - Quy tắc vàng về Latency: Luôn giữ GAVG dưới 15ms cho ứng dụng thường và dưới 5ms cho các hệ quản trị cơ sở dữ liệu (SQL, Oracle).
- Tùy chỉnh thời gian làm mới: Nhấn s và nhập 2 để màn hình cập nhật dữ liệu nhanh hơn (mặc định là 5 giây).
Làm chủ esxtop giúp bạn không còn phải đoán mò nguyên nhân gây chậm hệ thống. Nó tách bạch rõ ràng lỗi do phần cứng hay do cấu hình phần mềm, giúp bạn đưa ra quyết định nâng cấp hoặc tối ưu chính xác nhất.
