giới hạn bộ nhớ của nhân Linux

Tôi có một vấn đề bối rối. Tôi có một thư viện sử dụng sg để thực thi các CDB tùy chỉnh. Có một vài hệ thống thường xuyên có vấn đề với việc cấp phát bộ nhớ trong sg . Thông thường, trình điều khiển sg có giới hạn cứng khoảng 4mb, nhưng chúng tôi thấy nó trên một vài hệ thống có yêu cầu ~ 2.3mb. Đó là, các CDB đang chuẩn bị phân bổ cho việc chuyển 2,3mb. Không nên có bất kỳ vấn đề nào ở đây: 2.3 <4.0.

Bây giờ, hồ sơ của máy. Đó là CPU 64 bit nhưng chạy CentOS 6.0 32 bit (Tôi không xây dựng chúng cũng như không có gì để làm với quyết định này). Phiên bản kernel cho bản phân phối CentOS này là 2.6.32. Chúng có 16gb RAM.

Đây là cách sử dụng bộ nhớ trên hệ thống (mặc dù, vì lỗi này xảy ra trong quá trình kiểm tra tự động, tôi chưa xác minh nếu điều này phản ánh trạng thái khi lỗi này được trả về từ sg ).

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k total,        0k used,  4194296k free,  8497424k cached

Tôi tìm thấy bài viết này từ Tạp chí Linux về phân bổ bộ nhớ trong kernel. Bài báo có niên đại nhưng dường như liên quan đến 2.6 (một số ý kiến ​​về tác giả ở đầu). Bài viết đề cập rằng kernel bị giới hạn trong khoảng 1gb bộ nhớ (mặc dù nó không hoàn toàn rõ ràng khỏi văn bản nếu mỗi 1gb cho vật lý và ảo hoặc tổng số). Tôi tự hỏi nếu đây là một tuyên bố chính xác cho 2.6.32. Cuối cùng, tôi tự hỏi nếu các hệ thống này đang đạt đến giới hạn này.

Mặc dù đây không thực sự là một câu trả lời cho vấn đề của tôi, tôi tự hỏi về tính xác thực của khiếu nại trong 2.6.32. Vậy thì, giới hạn thực tế của bộ nhớ cho kernel là bao nhiêu? Điều này có thể cần phải được xem xét để khắc phục sự cố. Những đề nghị khác dều được hoan nghênh. Điều khiến điều này trở nên khó hiểu là các hệ thống này giống hệt với nhiều hệ thống khác không thể hiện cùng một vấn đề này.

Giới hạn 1 GiB cho bộ nhớ nhân Linux trong hệ thống 32 bit là kết quả của việc đánh địa chỉ 32 bit và đó là giới hạn khá cứng. Nó không phải là không thể thay đổi, nhưng nó ở đó vì một lý do rất tốt; thay đổi nó có hậu quả.

Chúng ta hãy mang máy trở lại vào đầu những năm 1990, khi Linux được tạo ra. Quay trở lại những ngày đó, chúng ta sẽ có những tranh luận về việc liệu Linux có thể được tạo ra để chạy trong 2 MiB RAM hay không nếu nó thực sự cần 4 MiB . Tất nhiên, những kẻ hợm hĩnh cao cấp đều chế nhạo chúng tôi, với 16 máy chủ quái vật MiB của họ.

Những họa tiết nhỏ thú vị đó có liên quan gì? Trong thế giới đó, thật dễ dàng để đưa ra quyết định về cách phân chia không gian địa chỉ 4 GiB mà bạn nhận được từ việc đánh địa chỉ 32 bit đơn giản. Một số hệ điều hành chỉ chia đôi một nửa, coi bit trên cùng của địa chỉ là "cờ kernel": địa chỉ 0 đến 2 ³¹ -1 đã bị xóa bit trên cùng và dành cho mã không gian người dùng và địa chỉ 2 ³¹ đến 2 ³² - 1 có tập bit trên cùng và dành cho kernel. Bạn chỉ có thể nhìn vào địa chỉ và nói: 0x80000000 trở lên, đó là không gian hạt nhân, nếu không đó là không gian người dùng.

Khi kích thước bộ nhớ PC tăng vọt về giới hạn bộ nhớ 4 GiB, sự phân chia 2/2 đơn giản này bắt đầu trở thành một vấn đề. Cả không gian người dùng và không gian kernel đều có yêu cầu tốt về rất nhiều RAM, nhưng vì mục đích của chúng tôi là có một máy tính thường là để chạy các chương trình người dùng, thay vì chạy hạt nhân, các hệ điều hành bắt đầu chơi xung quanh với phân chia người dùng / kernel. Sự phân chia 3/1 là một sự thỏa hiệp phổ biến.

Đối với câu hỏi của bạn về vật lý và ảo, nó thực sự không quan trọng. Về mặt kỹ thuật, đó là giới hạn bộ nhớ ảo, nhưng đó chỉ là do Linux là HĐH dựa trên VM. Cài đặt 32 GiB RAM vật lý sẽ không thay đổi bất cứ điều gì, cũng không giúp swaponphân vùng trao đổi 32 GiB. Bất kể bạn làm gì, một nhân Linux 32 bit sẽ không bao giờ có thể xử lý đồng thời hơn 4 GiB.

(Vâng, tôi biết về PAE . Bây giờ, các hệ điều hành 64 bit cuối cùng đã tiếp quản, tôi hy vọng chúng ta có thể bắt đầu quên đi vụ hack khó chịu đó. Tôi không tin rằng nó có thể giúp bạn trong trường hợp này.)

Điểm mấu chốt là nếu bạn đang chạy trong giới hạn VM 1 GiB, bạn có thể xây dựng lại kernel với phần chia 2/2, nhưng điều đó ảnh hưởng trực tiếp đến các chương trình không gian của người dùng.

64-bit thực sự là câu trả lời đúng.

Tôi muốn thêm một chút vào câu trả lời xuất sắc của Warren Young , bởi vì mọi thứ thực sự tồi tệ hơn anh ấy viết.

Không gian địa chỉ kernel 1GB được chia thành hai phần. 128 MB là cho vmallocvà 896 MB cho lowmem. Đừng bận tâm những gì nó thực sự có nghĩa. Khi phân bổ bộ nhớ, mã kernel phải chọn cái nào trong số này. Bạn không thể lấy bộ nhớ từ bất kỳ hồ bơi nào có không gian trống.

Nếu bạn chọn vmalloc, bạn bị giới hạn ở 128MB. Bây giờ 1GB trông không tệ lắm ...

Nếu bạn chọn lowmem, bạn bị giới hạn ở 896 MB. Không quá 1GB, nhưng trong trường hợp này, tất cả các phân bổ được làm tròn đến sức mạnh tiếp theo là 2. Vì vậy, phân bổ 2,3 MB thực sự tiêu tốn 4 MB. Ngoài ra, bạn không thể phân bổ nhiều hơn 4 MB trong một cuộc gọi khi sử dụng lowmem.

64-bit thực sự là câu trả lời đúng.