Không phải cứ "hàng khủng" là tốt

Cách đây hơn 2 tháng, một khách hàng của tôi có một project rất quan trọng: nâng cấp máy chủ database từ Oracle 9i lên Oracle 10g cho hệ thống core-banking của họ.

Mọi việc diễn ra tốt đẹp cho đến ngày đưa hệ thống vào production. Cứ chạy chừng 30' là con server "hàng khủng" 16 CPU Intel Itanium 2 + 32G RAM "sụm bà chè". CPU idle 0%, ssh vào còn không được, huống hồ chi là chạy Oracle. Họ liên hệ với tôi để tìm cách cứu chữa (tôi vốn có làm dự án core-banking này từ trước).

Việc đầu tiên tôi làm là...nhất nút reboot máy chủ. Dẫu biết đối với hệ thống database, việc hard reset như thế là điều tối kỵ, nhưng lúc đó quả thật tôi chẳng còn lựa chọn nào khác để giải thoát máy chủ ra khỏi tình trạng treo cứng, đành phải gửi trọn niềm tin vào Larry Ellison, hi vọng "bé" Oracle sẽ tự phục hồi sau khi reboot (thật ra vẫn còn một giải pháp dự phòng nếu Oracle không thể tự phục hồi được nên tôi mới tự tin vậy).

Sau khi reboot, tôi bắt đầu chuẩn bị một mớ công cụ cần thiết như top, vmstat, iostat, sar, oprofile; mở vài cái "tail -f" trên alert log của Oracle, đăng nhập vào Oracle Metalink...Xong xuôi, tôi bật Oracle lên lại và thử cho người dùng kết nối vào lại.

Chạy được đúng 20', server lại "hấp hối". top báo rằng CPU idle là 0%, trong đó iowait (iowait = network i/o + memory i/o + disk i/o) chỉ dao động từ 3-4%, user (các thao tác thuộc user space, Oracle process nằm ở đây) cũng chỉ tầm 5%-10%, còn lại tất cả tập trung dồn vào sys (các thao tác thuộc kernel space). Trong danh sách process list của top, kswapd liên tục dẫn đầu. Đây là điều bất thường so với baseline của server này. Lẽ ra user phải chiếm đa số, kế tiếp là iowait, rồi mới đến sys.

Rồi server bắt đầu swapping đến chóng mặt. iowait tăng lên, sys vẫn không giảm, user và idle luôn ở mức xấp xỉ 0%. Mà bạn biết rồi đó, một khi server đã swapping thì chẳng còn cách nào khác ngoài việc reboot nó. May mắn là tôi đã chuẩn bị sẵn lệnh shutdown Oracle trước khi quá muộn, thành ra lần này không cần reboot nữa.

Có hai câu hỏi được đặt ra:

- Tại sao sys lại chiếm đa số? kswapd đang làm gì?

- Tại sao với lượng RAM nhiều như thế mà iowait vẫn tăng lên và server bắt đầu swapping dữ dội?

----

Kinh nghiệm trong quá khứ làm việc với Oracle cho tôi biết rằng, mọi câu hỏi liên quan đến Oracle đều có thể được trả lời trong Oracle Metalink (nếu sếp của bạn bắt bạn sử dụng Oracle nhưng không mua account Metalink cho bạn, lời khuyên là hãy xin nghỉ việc càng sớm càng tốt :-d).

Tôi bắt đầu tìm kiếm với các keyword có thể nghĩ ra được. Mất gần 1h mò mẫm mà tôi vẫn chưa tìm được bất kì tài liệu nào đề cập đến hiện tượng giống với tình trạng hiện thời của tôi. Cũng may là lúc này đã qua giờ giao dịch rồi, nên thời gian cũng tương đối rộng rãi hơn. Tôi quyết định dành ra 30' nữa để tìm, trước khi tạo một service request yêu cầu sự hỗ trợ trực tiếp từ Oracle.

Ngoài tôi ra, các anh chị DBA cũng ra sức tìm kiếm. Thường trong trường hợp như thế này, tất cả sẽ join vào một conference để tiện việc trao đổi thông tin. Đây là việc làm rất có lợi và cần thiết, bởi lẽ các anh chị DBA thường không rành lắm về Linux, còn bản thân tôi cũng không có nhiều kiến thức về Oracle.

Trong số các tài liệu được các anh chị DBA gửi lên conference, tôi chú ý đến một tài liệu có tên như sau: How to Configure RHEL 4 32-bit for Very Large Memory with ramfs and HugePages Note:317141.1 Type: WHITE PAPER.
Chà, "very large memory", sao tôi không nghĩ đến keyword này nhỉ?

Lúc đầu tôi vẫn không nghĩ tài liệu này sẽ giải quyết được vấn đề, bởi lẽ nó ghi rõ ràng là 32-bit, trong khi hệ thống của tôi là 64-bit. Hơn nữa nếu tôi nhớ không lầm, HugePages chỉ có tác dụng cho hệ thống 32-bit mà thôi. Tuy thế, tôi vẫn mở nó ra xem; dẫu gì nãy giờ cũng tiêu tốn nhiều thời gian rồi, tốn thêm một chút nữa cũng không sao :-p.

Điều đầu tiên tôi nhìn thấy trong tài liệu là dòng:

This document aims to guide Linux system administrators on Red Hat Enterprise Linux 4.0 to configure Very Large Memory and big SGA for Oracle RDBMS with ramfs and hugepages

The configuration provided in this document applies strictly to 32-bit Linux. For HugePages on 64-bit Linux, see Note 361468.1

Chà, nó ghi là nếu muốn tìm hiểu về HugePages trên Linux 64-bit thì coi cái Note:361468.1. Như vậy có nghĩa là vẫn có thể áp dụng được HugePages cho 64-bit Linux àh? Tôi nhanh chóng tải cái Note:361468.1 về và quả thật, nó chính là thứ tôi cần tìm!

Hóa ra tôi hiể nhầm về HugePages thật:

HugePages is a feature of the Linux kernel which allows larger pages to manage memory as the alternative to the small 4K pagesize. For a detailed introduction, see Note 361323.1.

There is a general misconception where the HugePages is a feature specific to 32-bit Linux. This document focuses on uses of HugePages on 64-bit Linux platforms.

Phần cuối của tài liệu này trông có vẻ rất promising:

Why HugePages Should Be Used on 64-bit Linux?

* Very Large Memory: The 64-bit systems do have VLM. So the general VLM issues apply.

* Not swappable: HugePages are not swappable. Therefore there is no page replacement mechanism overhead. HugePages are universally regarded as pinned.

* Eliminated page table lookup overhead: Since the pages are not subject to replacement, page table lookups are not required.

* Faster overall memory performance: On virtual memory systems each memory operation is actually two abstract memory operations. Since there are less number of pages to work on, the possible bottleneck on page table access is clearly avoided.

* kswapd: kswapd will get very busy if there is a very large area to be paged (i.e. 13 million page table entries for 50GB memory) and will use an incredible amount of CPU resource. When HugePages are used, kswapd is not involved in managing them.

Có vẻ như tôi đang đi đúng hướng rồi. Tôi quyết định đọc lại về HugePages để hiểu rõ hơn về nó. Một điều may mắn là trước đây tôi có đọc rất kĩ về phần memory management của Linux kernel trong cuốn Understanding The Linux Kernel, thành ra tôi không mất nhiều thời gian lắm để hiểu rõ HugePages.

(còn tiếp)