Bộ nhớ đã cam kết trong Linux ít hơn dự kiến

Một trong những cách sử dụng bộ nhớ của máy chủ linux của tôi là lạ. Theo như tôi biết bộ nhớ Cam kết lớn hơn (Committed_AS trong /proc/meminfo hoặc kbcommit trong sar -r) so với bộ nhớ được sử dụng của ứng dụng là bình thường. Nhưng bộ nhớ cam kết của máy chủ của tôi nhỏ đáng kể.

# mèo /proc/meminfo
MemTổng: 32877480 kB
MemFree: 3511812 kB
Bộ đệm: 19364 kB
Bộ nhớ cache: 12080112 kB
SwapCached: 0 kB
Đang hoạt động: 22658640 kB
Không hoạt động: 5906936 kB
Đang hoạt động (không hoạt động): 16460116 kB
Không hoạt động (không hoạt động): 6652 kB
Hoạt động (tệp): 6198524 kB
Không hoạt động (tệp): 5900284 kB
Không thể tránh khỏi: 0 kB
Đã khóa: 0 kB
SwapTotal: 0 kB
SwapMiễn phí: 0 kB
Bẩn: 544 kB
Ghi lại: 4 kB
Trang Anon: 16482208 kB
Đã ánh xạ: 17228 kB
Shmem: 672 kB
Tấm: 529344 kB
SCó thể nhận lại: 460220 kB
Yêu cầu bồi thường: 69124 kB
KernelStack: 12304 kB
Bảng trang: 51412 kB
NFS_Không ổn định: 0 kB
Thoát: 0 kB
Ghi lạiTmp: 0 kB
Giới hạn cam kết: 16438740 kB
Đã cam kết_AS: 4484680 kB
VmallocTổng: 34359738367 kB
VmallocĐã sử dụng: 66424 kB
VmallocChunk: 34359651996 kB
Phần cứng bị hỏng: 0 kB
Trang AnonHuge: 15376384 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Kích thước trang lớn: 2048 kB
DirectMap4k: 4096 kB
DirectMap2M: 2093056 kB
DirectMap1G: 31457280 kB

Như bạn có thể thấy, committed_AS là khoảng 4,4 GB. Nhưng một trong những quá trình đang sử dụng hơn 14GB. Quá trình này không có bất kỳ tệp mmap nào hoặc bất kỳ bộ nhớ dùng chung nào.

# pidstat -r 1 1
Linux 2.6.32-696.16.1.el6.x86_64 (appintprdsearch01) 23/08/21 _x86_64_ (8 CPU)

16:56:34 PID minflt/s majflt/s VSZ RSS %MEM Lệnh
16:56:35 414 19476,24 0,00 17260248 14356476 43,67 isc_mc
# bản đồ -x 414 | egrep '^Địa chỉ|^tổng'
Địa chỉ Kbytes RSS Dirty Mode Mapping
tổng kB 17268588 14363848 14360208
# bản đồ -x 414 | grep anon | awk '{s+=$3} END {print s}'
14326736

Tôi tự hỏi tại sao bộ nhớ đã sử dụng của quá trình này không ảnh hưởng đến bộ nhớ đã cam kết. Có cái gì tôi bị mất?

# mèo /etc/system-release
Bản phát hành Red Hat Enterprise Linux Server 6.8 (Santiago)
# uname -r
2.6.32-696.16.1.el6.x86_64

Cảm ơn trước!!

CHỈNH SỬA: Tôi đã cố gắng hiển thị toàn bộ đầu ra pmap -x được thực hiện hôm nay. nhưng nó dài 758 dòng và vượt quá giới hạn bài đăng. Vì vậy, đây là tóm tắt. Và tôi phát hiện ra rằng các trang anon của nó ngày càng lớn hơn.

# bản đồ -x 414 | grep -vw anon
414: /usr/local/search/sf-1v530/bin/isc_mc -license /usr/local/search/sf-1v530/license/license.xml -conf ../config/config_mc.xml -pid /usr/local /search/sf-1v530/pid/isc_mc.pid -log /usr/local/search/sf-1v530/log/isc_mc
Địa chỉ Kbytes RSS Dirty Mode Mapping
0000000000400000 4616 1720 0 r-x-- isc_mc
0000000000a81000 1304 716 20 rw--- isc_mc
0000003c54200000 128 108 0 r-x-- ld-2.12.so
0000003c54420000 4 4 4 r---- ld-2.12.so
0000003c54421000 4 4 4 rw--- ld-2.12.so
0000003c54600000 1576 584 0 r-x-- libc-2.12.so
0000003c5478a000 2048 0 0 ----- libc-2.12.so
0000003c5498a000 16 16 8 r---- libc-2.12.so
0000003c5498e000 8 8 8 rw--- libc-2.12.so
0000003c54a00000 92 72 0 r-x-- libpthread-2.12.so
0000003c54a17000 2048 0 0 ----- libpthread-2.12.so
0000003c54c17000 4 4 4 r---- libpthread-2.12.so
0000003c54c18000 4 4 4 rw--- libpthread-2.12.so
0000003c55600000 524 80 0 r-x-- libm-2.12.so
0000003c55683000 2044 0 0 ----- libm-2.12.so
0000003c55882000 4 4 4 r---- libm-2.12.so
0000003c55883000 4 4 4 rw--- libm-2.12.so
0000003c55a00000 84 16 0 r-x-- libz.so.1.2.3
0000003c55a15000 2044 0 0 ----- libz.so.1.2.3
0000003c55c14000 4 4 4 r---- libz.so.1.2.3
0000003c55c15000 4 4 4 rw--- libz.so.1.2.3
0000003c56600000 88 16 0 r-x-- libgcc_s-4.4.7-20120601.so.1
0000003c56616000 2044 0 0 ----- libgcc_s-4.4.7-20120601.so.1
0000003c56815000 4 4 4 rw--- libgcc_s-4.4.7-20120601.so.1
0000003c57200000 928 488 0 r-x-- libstdC++.so.6.0.13
0000003c572e8000 2048 0 0 ----- libstdC++.so.6.0.13
0000003c574e8000 28 28 28 r---- libstdC++.so.6.0.13
0000003c574ef000 8 8 8 rw--- libstdC++.so.6.0.13
00007ffdcbf56000 84 48 48 rw--- [ ngăn xếp ]
---------------- ------ ------ ------
tổng kB 18462068 15806748 15802956

Đây là kích thước được sắp xếp của bản đồ anon và số lượng của nó.

# bản đồ -x 414 | grep -w anon | awk '{s[$2]++} END {for (x in s) {print x,s[x]}}' | loại
-rnk 1
254728 1
225520 1
197220 1
196608 1
131480 2
131072 2
124008 1
65740 3
65536 142
65532 5
65528 3
65524 2
65520 1
65512 2
65508 2
65504 3
65500 3
65488 2
65484 5
65480 2
65476 1
65464 2
65456 1
65452 1
65448 2
65440 4
65436 3
65432 3
65428 2
65424 1
65420 28
65412 1
65404 1
65400 1
65372 1
65192 1
65188 1
64804 1
64636 1
63940 1
63912 1
63792 1
63584 1
63408 1
63400 2
63244 1
63008 2
63004 1
61996 1
61848 1
61792 1
61624 1
60976 1
59940 1
58276 1
57736 1
55992 1
52348 1
51212 1
50084 1
40840 1
24696 1
15452 1
14324 1
13188 1
10396 1
10240 1
9544 1
7800 1
7260 1
7064 1
5596 1
4560 1
3912 1
3744 1
3688 1
3540 1
3216 1
2532 1
2528 2
2292 1
2136 2
2128 1
1952 1
1744 1
1624 1
1596 1
1024 169
900 1
732 1
348 1
344 1
164 1
136 1
132 1
124 1
116 28
112 1
108 2
104 3
100 3
96 4
88 2
84 2
80 1
72 2
60 1
56 2
52 5
48 2
36 3
32 3
28 2
24 2
16 3
12 2
8 4
4 179

CHỈNH SỬA: Tôi đã yêu cầu hỗ trợ khách hàng cho Redhat. Tôi e rằng tôi không thể nhận được bất kỳ câu trả lời nào vì RHEL6 đã được EOSed. Dù sao tôi sẽ đăng ở đây kết quả.

Một nửa bộ nhớ của máy chủ lưu trữ này nằm trong các trang riêng tư.Hầu hết đó là quá trình bạn xác định. Đã cam kết_AS tương đối thấp ở mức 14% MemTotal ngụ ý chưa có nhiều dữ liệu được sử dụng cho dữ liệu thực tế.

Hệ điều hành lười biếng. Linux sẽ không chạm vào tất cả 14 GB mà chương trình này yêu cầu. Thay vào đó, vì CPU x86 này hỗ trợ các trang 2 MB và 1 GB, nên Linux chỉ định một vài trang trong số đó cho quy trình này và giả vờ rằng chúng hoàn toàn bằng không. Lưu ý Bản đồ trực tiếp hiển thị nhiều trang phần cứng 1 GB. Quản trị viên có thể định cấu hình HugePages một cách rõ ràng, nhưng meminfo đó không hiển thị trong số những trang được định cấu hình.

Chỉ phân bổ này chiếm rất ít bộ nhớ vật lý, vì vậy Đã cam kết_AS bắt đầu thấp. Nếu và khi ứng dụng lấp đầy những dữ liệu này bằng dữ liệu thực, nó sẽ tăng lên.

Về quy hoạch dung lượng, hiện tại máy chủ này hiện có rất nhiều bộ nhớ. Bộ nhớ ẩn và bộ nhớ dùng chung được giới hạn ở một nửa, bộ nhớ đệm 36% để truy cập tệp nhanh và một vài GB trống và chưa sử dụng để đáp ứng nhu cầu cấp phát bộ nhớ ngay lập tức. Và tất nhiên Đã cam kết_AS xa dưới MemTotal

Mặc dù phân bổ bộ nhớ của ứng dụng phù hợp với kích thước của máy chủ lưu trữ, hãy tìm hiểu lý do tại sao nó lại có kích thước như vậy. Nếu đây là cơ sở dữ liệu trong bộ nhớ có kích thước để phát triển trong tương lai, thì điều đó có thể hợp lý. Hoặc có thể 32 GB là VM cỡ trung bình/máy chủ vật lý cỡ nhỏ của bạn, kích thước quá lớn có thể dễ vận hành hơn.