Có ai thực sự sử dụng và hưởng lợi từ các trang lớn minh bạch?

Tôi đã phải vật lộn với các vấn đề hiệu suất trang lớn trong suốt về muộn và nhận thấy nhiều hệ thống cơ sở dữ liệu khuyên bạn nên tắt nó đi. Tôi đang nói về Oracle, Postgresql, MySQL, Cassandra, NuoDB, Redis, Hadoop, v.v.

Ví dụ như:

• Peter Zaitsev (2014-07-23). Tại sao TokuDB ghét HugePages trong suốt . Percona.
• Michele Casey (2013-09-17). Các vấn đề về hiệu suất với các trang lớn trong suốt . Oracle.
• Adam Abrevaya và Oleg Levin (2014-05-15). Các trang lớn trong suốt của Linux, JEMalloc và NuoDB . NuoDB DevCentre.

Vì vậy, tôi tự hỏi: những loại khối lượng công việc làm lợi ích từ tính năng này?

Các trang khổng lồ sẽ hữu ích trong trường hợp bạn cần một lượng thông tin khổng lồ để được viết trong cùng một khối. Nó có thể liên quan đến chiến lược ghi đĩa và có thể có ý nghĩa đối với bộ nhớ đệm. Giống như tất cả các tùy chọn cấu hình, sẽ không có nghĩa gì nếu trường hợp sử dụng của bạn không phù hợp.

Vì vậy, câu trả lời là, khối lượng công việc thực sự cần một tấn dữ liệu khổng lồ trong cùng một khối sẽ được hưởng lợi từ các trang lớn. Nếu dữ liệu quá lớn, nó sẽ không thể phù hợp, nhưng sẽ phải chia thành nhiều tệp trang và số lượng lớn trong số đó sẽ quá nhiều để xử lý hoặc xấu vì một số lý do và số lượng lớn hơn thấp hơn tập tin là tốt hơn - có trường hợp của bạn cho các tập tin trang lớn.

Về mặt thực tế, tôi chưa bao giờ gặp bất kỳ nhu cầu nào về nó nhưng tôi biết từ việc quản lý bộ nhớ cache - đó là một điều có thật và ai đó, ở đâu đó, có thể được hưởng lợi từ các trang lớn.

Không biết ai đã nói với bạn rằng cassandra sẽ không được hưởng lợi từ những cái ôm. Có lẽ bạn muốn trò chuyện một chút theo hướng tùy chọn chống phân mảnh từ / sys / kernel / mm / suốt_hugepage.

Cá nhân tôi chỉ thử nghiệm một cụm cassandra có và không có hugepage và sau các thử nghiệm khác nhau với kích cỡ khác nhau, bắt đầu từ 300 b đến 4k, tôi có thể nói rằng tôi sẽ kích hoạt chúng.