Sử dụng bộ nhớ cache răng cao bất thường

34

Vấn đề

Một máy CentOS có kernel 2.6.32 và RAM vật lý 128 GB đã gặp sự cố vài ngày trước. Quản trị viên hệ thống có trách nhiệm nói với tôi rằng ứng dụng PHP-FPM đã không đáp ứng kịp thời các yêu cầu do hoán đổi và vì thấy freerằng hầu như không còn bộ nhớ, anh ta đã chọn khởi động lại máy.

Tôi biết rằng bộ nhớ trống có thể là một khái niệm khó hiểu trên Linux và khởi động lại có lẽ là điều sai lầm. Tuy nhiên, quản trị viên được đề cập đổ lỗi cho ứng dụng PHP (mà tôi chịu trách nhiệm) và từ chối điều tra thêm.

Những gì tôi có thể tự mình tìm ra là:

Trước khi khởi động lại, bộ nhớ trống (bao gồm bộ đệm và bộ đệm) chỉ còn vài trăm MB.
Trước khi khởi động lại, /proc/meminfođã báo cáo mức sử dụng bộ nhớ Slab khoảng 90 GB (có, GB).
Sau khi khởi động lại, bộ nhớ trống là 119 GB, giảm xuống còn khoảng 100 GB trong vòng một giờ, khi các nhân viên PHP-FPM (khoảng 600 người trong số họ) đã hoạt động trở lại, mỗi người trong số họ hiển thị từ 30 đến 40 MB trong Cột RES ở trên cùng (đã được cách này trong nhiều tháng và hoàn toàn hợp lý dựa trên bản chất của ứng dụng PHP). Không có gì khác trong danh sách quá trình tiêu thụ một lượng RAM bất thường hoặc đáng chú ý.
Sau khi khởi động lại, bộ nhớ Slab khoảng 300 MB

Nếu đã theo dõi hệ thống kể từ đó, và đáng chú ý nhất là bộ nhớ Slab đang tăng theo đường thẳng với tốc độ khoảng 5 GB mỗi ngày. Bộ nhớ trống như được báo cáo bởi freevà /proc/meminfogiảm ở cùng một tỷ lệ. Tấm hiện tại là 46 GB. Theo slabtophầu hết nó được sử dụng cho dentrycác mục:

Bộ nhớ trống:

free -m
             total       used       free     shared    buffers     cached
Mem:        129048      76435      52612          0        144       7675
-/+ buffers/cache:      68615      60432
Swap:         8191          0       8191

Meminfo:

cat /proc/meminfo
MemTotal:       132145324 kB
MemFree:        53620068 kB
Buffers:          147760 kB
Cached:          8239072 kB
SwapCached:            0 kB
Active:         20300940 kB
Inactive:        6512716 kB
Active(anon):   18408460 kB
Inactive(anon):    24736 kB
Active(file):    1892480 kB
Inactive(file):  6487980 kB
Unevictable:        8608 kB
Mlocked:            8608 kB
SwapTotal:       8388600 kB
SwapFree:        8388600 kB
Dirty:             11416 kB
Writeback:             0 kB
AnonPages:      18436224 kB
Mapped:            94536 kB
Shmem:              6364 kB
Slab:           46240380 kB
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB
KernelStack:        9336 kB
PageTables:       457516 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    72364108 kB
Committed_AS:   22305444 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      480164 kB
VmallocChunk:   34290830848 kB
HardwareCorrupted:     0 kB
AnonHugePages:  12216320 kB
HugePages_Total:    2048
HugePages_Free:     2048
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5604 kB
DirectMap2M:     2078720 kB
DirectMap1G:    132120576 kB

Mặt phẳng:

slabtop --once
Active / Total Objects (% used)    : 225920064 / 226193412 (99.9%)
 Active / Total Slabs (% used)      : 11556364 / 11556415 (100.0%)
 Active / Total Caches (% used)     : 110 / 194 (56.7%)
 Active / Total Size (% used)       : 43278793.73K / 43315465.42K (99.9%)
 Minimum / Average / Maximum Object : 0.02K / 0.19K / 4096.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
221416340 221416039   3%    0.19K 11070817       20  44283268K dentry                 
1123443 1122739  99%    0.41K 124827        9    499308K fuse_request           
1122320 1122180  99%    0.75K 224464        5    897856K fuse_inode             
761539 754272  99%    0.20K  40081       19    160324K vm_area_struct         
437858 223259  50%    0.10K  11834       37     47336K buffer_head            
353353 347519  98%    0.05K   4589       77     18356K anon_vma_chain         
325090 324190  99%    0.06K   5510       59     22040K size-64                
146272 145422  99%    0.03K   1306      112      5224K size-32                
137625 137614  99%    1.02K  45875        3    183500K nfs_inode_cache        
128800 118407  91%    0.04K   1400       92      5600K anon_vma               
 59101  46853  79%    0.55K   8443        7     33772K radix_tree_node        
 52620  52009  98%    0.12K   1754       30      7016K size-128               
 19359  19253  99%    0.14K    717       27      2868K sysfs_dir_cache        
 10240   7746  75%    0.19K    512       20      2048K filp

Áp lực bộ đệm VFS:

cat /proc/sys/vm/vfs_cache_pressure
125

Swappiness:

cat /proc/sys/vm/swappiness
0

Tôi biết rằng bộ nhớ không sử dụng là bộ nhớ bị lãng phí, vì vậy đây không nhất thiết là một điều xấu (đặc biệt là khi 44 GB được hiển thị là SReclaimable). Tuy nhiên, rõ ràng máy gặp sự cố dù sao và tôi sợ điều tương tự sẽ xảy ra một lần nữa sau vài ngày khi Slab vượt quá 90 GB.

Câu hỏi

Tôi có những câu hỏi sau:

Tôi có đúng không khi nghĩ rằng bộ nhớ Slab luôn là RAM vật lý và con số đã bị trừ khỏi giá trị MemFree?
Là một số lượng lớn các mục nha khoa bình thường? Ứng dụng PHP có quyền truy cập vào khoảng 1,5 M tệp, tuy nhiên hầu hết trong số chúng là tài liệu lưu trữ và hoàn toàn không được truy cập cho lưu lượng truy cập web thông thường.
Điều gì có thể là một lời giải thích cho thực tế là số lượng các nút được lưu trong bộ nhớ cache thấp hơn nhiều so với số lượng các bộ đệm được lưu trong bộ nhớ cache, nếu chúng không liên quan bằng cách nào đó?
Nếu hệ thống gặp sự cố về bộ nhớ, liệu kernel có tự động giải phóng một số vết lõm không? Điều gì có thể là một lý do mà điều này không xảy ra?
Có cách nào để "nhìn vào" bộ đệm của bộ răng để xem tất cả bộ nhớ này là gì (tức là các đường dẫn đang được lưu trong bộ nhớ cache) là gì? Có lẽ điều này chỉ ra một số loại rò rỉ bộ nhớ, vòng lặp symlink hoặc thực sự là một cái gì đó mà ứng dụng PHP đang làm sai.
Mã ứng dụng PHP cũng như tất cả các tệp tài sản được gắn kết thông qua hệ thống tệp mạng GlusterFS, điều đó có liên quan gì không?

Xin lưu ý rằng tôi không thể điều tra với quyền root, chỉ với tư cách là người dùng thông thường và quản trị viên từ chối trợ giúp. Anh ta thậm chí sẽ không chạy echo 2 > /proc/sys/vm/drop_cachesthử nghiệm điển hình để xem liệu bộ nhớ Slab có thực sự có thể lấy lại được không.

Bất kỳ hiểu biết nào về những gì có thể xảy ra và làm thế nào tôi có thể điều tra thêm nữa sẽ được đánh giá rất cao.

Cập nhật

Một số thông tin chẩn đoán thêm:

Gắn kết:

cat /proc/self/mounts
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=66063000k,nr_inodes=16515750,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
/dev/mapper/sysvg-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0
tmpfs /phptmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
tmpfs /wsdltmp tmpfs rw,noatime,size=1048576k,nr_inodes=15728640,mode=777 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
cgroup /cgroup/cpuset cgroup rw,relatime,cpuset 0 0
cgroup /cgroup/cpu cgroup rw,relatime,cpu 0 0
cgroup /cgroup/cpuacct cgroup rw,relatime,cpuacct 0 0
cgroup /cgroup/memory cgroup rw,relatime,memory 0 0
cgroup /cgroup/devices cgroup rw,relatime,devices 0 0
cgroup /cgroup/freezer cgroup rw,relatime,freezer 0 0
cgroup /cgroup/net_cls cgroup rw,relatime,net_cls 0 0
cgroup /cgroup/blkio cgroup rw,relatime,blkio 0 0
/etc/glusterfs/glusterfs-www.vol /var/www fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
/etc/glusterfs/glusterfs-upload.vol /var/upload fuse.glusterfs rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
172.17.39.78:/www /data/www nfs rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78 0 0

Thông tin núi:

cat /proc/self/mountinfo
16 21 0:3 / /proc rw,relatime - proc proc rw
17 21 0:0 / /sys rw,relatime - sysfs sysfs rw
18 21 0:5 / /dev rw,relatime - devtmpfs devtmpfs rw,size=66063000k,nr_inodes=16515750,mode=755
19 18 0:11 / /dev/pts rw,relatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
20 18 0:16 / /dev/shm rw,relatime - tmpfs tmpfs rw
21 1 253:1 / / rw,relatime - ext4 /dev/mapper/sysvg-lv_root rw,barrier=1,data=ordered
22 16 0:15 / /proc/bus/usb rw,relatime - usbfs /proc/bus/usb rw
23 21 8:1 / /boot rw,relatime - ext4 /dev/sda1 rw,barrier=1,data=ordered
24 21 0:17 / /phptmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
25 21 0:18 / /wsdltmp rw,noatime - tmpfs tmpfs rw,size=1048576k,nr_inodes=15728640,mode=777
26 16 0:19 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc none rw
27 21 0:20 / /cgroup/cpuset rw,relatime - cgroup cgroup rw,cpuset
28 21 0:21 / /cgroup/cpu rw,relatime - cgroup cgroup rw,cpu
29 21 0:22 / /cgroup/cpuacct rw,relatime - cgroup cgroup rw,cpuacct
30 21 0:23 / /cgroup/memory rw,relatime - cgroup cgroup rw,memory
31 21 0:24 / /cgroup/devices rw,relatime - cgroup cgroup rw,devices
32 21 0:25 / /cgroup/freezer rw,relatime - cgroup cgroup rw,freezer
33 21 0:26 / /cgroup/net_cls rw,relatime - cgroup cgroup rw,net_cls
34 21 0:27 / /cgroup/blkio rw,relatime - cgroup cgroup rw,blkio
35 21 0:28 / /var/www rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-www.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
36 21 0:29 / /var/upload rw,relatime - fuse.glusterfs /etc/glusterfs/glusterfs-upload.vol rw,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072
37 21 0:30 / /var/lib/nfs/rpc_pipefs rw,relatime - rpc_pipefs sunrpc rw
39 21 0:31 / /data/www rw,relatime - nfs 172.17.39.78:/www rw,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=38467,timeo=600,retrans=2,sec=sys,mountaddr=172.17.39.78,mountvers=3,mountport=38465,mountproto=tcp,local_lock=none,addr=172.17.39.78

Cấu hình GlusterFS:

cat /etc/glusterfs/glusterfs-www.vol
volume remote1
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.71
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
    # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote2
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.72
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote3
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.73
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume remote4
  type protocol/client
  option transport-type tcp
  option remote-host 172.17.39.74
   option ping-timeout 10
   option transport.socket.nodelay on # undocumented option for speed
        # http://gluster.org/pipermail/gluster-users/2009-September/003158.html
  option remote-subvolume /data/www
end-volume

volume replicate1
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote1 remote2
end-volume

volume replicate2
  type cluster/replicate
   option lookup-unhashed off    # off will reduce cpu usage, and network
   option local-volume-name 'hostname'
  subvolumes remote3 remote4
end-volume

volume distribute
  type cluster/distribute
  subvolumes replicate1 replicate2
end-volume

volume iocache
  type performance/io-cache
   option cache-size 8192MB        # default is 32MB
   subvolumes distribute
end-volume

volume writeback
  type performance/write-behind
  option cache-size 1024MB
  option window-size 1MB
  subvolumes iocache
end-volume

### Add io-threads for parallel requisitions
volume iothreads
  type performance/io-threads
  option thread-count 64 # default is 16
  subvolumes writeback
end-volume

volume ra
  type performance/read-ahead
  option page-size 2MB
  option page-count 16
  option force-atime-update no
  subvolumes iothreads
end-volume

linux centos memory

— Wolfgang Stengel
nguồn

Vui lòng cung cấp đầu ra cat /proc/self/mountsvà (có thể khá dài) cat /proc/self/mountinfo.

— Matthew Ife

@MIfe Tôi đã cập nhật câu hỏi, cả hai đầu ra đều được nối thêm.

— Wolfgang Stengel 14/12/13

Cảm giác của tôi ở đây có lẽ là để làm với bộ nhớ đệm nha khoa NFS. Không quan tâm bạn có thể chạy cat /etc/nfsmount.conf. Ngoài ra, bạn có bất kỳ thư mục có chứa nhiều tập tin trong thư mục ngay lập tức của nó?

— Matthew Ife

1

Chà, vì vfs_cache_pressure> 100, kernel nên lấy lại bộ nhớ cache của bộ nhớ cache. Đây có thể dễ dàng là một lỗi, 2.6.32 là kernel khá cũ, ngay cả với các bản vá backport RedHat. BTW, phiên bản kernel chính xác là gì?

— poige

2

(Sysadmin của bạn nghe có vẻ khủng khiếp . Nó cho chúng ta một tên xấu)

— ewwhite

14

Tôi có đúng không khi nghĩ rằng bộ nhớ Slab luôn là RAM vật lý và con số đã bị trừ khỏi giá trị MemFree?

Vâng.

Là một số lượng lớn các mục nha khoa bình thường? Ứng dụng PHP có quyền truy cập vào khoảng 1,5 M tệp, tuy nhiên hầu hết trong số chúng là tài liệu lưu trữ và hoàn toàn không được truy cập cho lưu lượng truy cập web thông thường.

Có, nếu hệ thống không chịu áp lực bộ nhớ. Nó phải sử dụng bộ nhớ cho một cái gì đó và có thể trong mô hình sử dụng cụ thể của bạn, đây là cách tốt nhất để sử dụng bộ nhớ đó.

Điều gì có thể là một lời giải thích cho thực tế là số lượng các nút được lưu trong bộ nhớ cache thấp hơn nhiều so với số lượng các bộ đệm được lưu trong bộ nhớ cache, nếu chúng không liên quan bằng cách nào đó?

Rất nhiều hoạt động thư mục sẽ là lời giải thích có khả năng nhất.

Nếu hệ thống gặp sự cố về bộ nhớ, liệu kernel có tự động giải phóng một số vết lõm không? Điều gì có thể là một lý do mà điều này không xảy ra?

Nó nên, và tôi không thể nghĩ ra bất kỳ lý do nào. Tôi không tin rằng đây là những gì thực sự đã đi sai. Tôi thực sự khuyên bạn nên nâng cấp kernel của mình hoặc tăng vfs_cache_pressure hơn nữa.

Có cách nào để "nhìn vào" bộ đệm của bộ răng để xem tất cả bộ nhớ này là gì (tức là các đường dẫn đang được lưu trong bộ nhớ cache) là gì? Có lẽ điều này chỉ ra một số loại rò rỉ bộ nhớ, vòng lặp symlink hoặc thực sự là một cái gì đó mà ứng dụng PHP đang làm sai.

Tôi không tin là có. Tôi sẽ tìm bất kỳ thư mục nào với số lượng lớn các mục hoặc cấu trúc thư mục rất sâu được tìm kiếm hoặc duyệt qua.

Mã ứng dụng PHP cũng như tất cả các tệp tài sản được gắn kết thông qua hệ thống tệp mạng GlusterFS, điều đó có liên quan gì không?

Chắc chắn nó có thể là một vấn đề hệ thống tập tin. Ví dụ, một lỗi hệ thống tập tin khiến răng không được phát hành, là một khả năng.

— David Schwartz
nguồn

Cảm ơn bạn đã trả lời câu hỏi của tôi cá nhân. Áp lực bộ đệm cuối cùng đã tăng hơn nữa và tăng bộ nhớ cache của nha khoa đã dừng lại.

— Wolfgang Stengel

Tôi chưa thể theo dõi chương trình chịu trách nhiệm. Nếu tôi tìm hiểu thêm, tôi sẽ báo cáo lại cho bất kỳ ai khác có vấn đề này.

— Wolfgang Stengel

1

Cảm ơn! Thư mục lớn (0,25 triệu tệp) hoàn toàn là nguyên nhân gây ra sự cố trong trường hợp của tôi, bất cứ khi nào một thứ gì đó tương tác với nó 2GB ram sẽ biến mất vào bộ đệm.

— Một số Linux Nerd

20

Giải pháp khẳng định

Cho bất cứ ai có thể gặp vấn đề tương tự. Những người trung tâm dữ liệu cuối cùng đã tìm ra nó ngày hôm nay. Thủ phạm là một thư viện NSS (Dịch vụ bảo mật mạng) đi kèm với Libcurl. Một bản nâng cấp lên phiên bản mới nhất đã giải quyết được vấn đề.

Một báo cáo lỗi mô tả chi tiết ở đây:

https://ormszilla.redhat.com/show_orms.cgi?format=mult Môn & id = 1044666

Rõ ràng, để xác định xem một số đường dẫn là cục bộ hoặc trên một ổ đĩa mạng, NSS đã tìm kiếm một tệp chưa tồn tại và đo thời gian cần thiết để hệ thống tệp báo cáo lại! Nếu bạn có số lượng yêu cầu Curl đủ lớn và đủ bộ nhớ, các yêu cầu này đều được lưu trữ và xếp chồng lên nhau.

— Wolfgang Stengel
nguồn

15

Tôi đã gặp vấn đề chính xác này, và trong khi Wolfgang nói đúng về nguyên nhân, thì vẫn còn thiếu một số chi tiết quan trọng.

Vấn đề này ảnh hưởng đến các yêu cầu SSL được thực hiện với curl hoặc libcurl hoặc bất kỳ phần mềm nào khác sử dụng mozilla NSS để kết nối an toàn. Yêu cầu không an toàn không kích hoạt vấn đề.
Vấn đề không yêu cầu curl đồng thời. Sự tích lũy của nha khoa sẽ xảy ra miễn là các cuộc gọi curl thường xuyên đủ để vượt qua các nỗ lực của hệ điều hành để lấy lại RAM.
phiên bản mới hơn của NSS, 3.16.0, không bao gồm bản sửa lỗi này. tuy nhiên, bạn không nhận được bản sửa lỗi miễn phí bằng cách nâng cấp NSS và bạn không phải nâng cấp tất cả NSS. bạn chỉ phải nâng cấp nss-softokn (có phụ thuộc bắt buộc vào nss-utils) ở mức tối thiểu. và để có được lợi ích, bạn cần đặt biến môi trường NSS_SDB_USE_CACHE cho quy trình đang sử dụng libcurl. sự hiện diện của biến môi trường đó là những gì cho phép kiểm tra tệp không tồn tại tốn kém.

FWIW, tôi đã viết một mục blog với một chút thông tin / thông tin chi tiết, trong trường hợp bất cứ ai cần nó.

— J. Paulding
nguồn

Cảm ơn về một bài đăng blog hay, nhưng tôi muốn đề cập rằng nss-softokn vẫn chưa được cập nhật lên phiên bản 3.16 trên CentOS / RHEL. Nó có thể sẽ được sửa trong phiên bản 6.6.

— Strahinja Kustudic

1

Cảm ơn đã lưu ý. Có lẽ Amazon đã vượt lên trước cái này (thậm chí có thể theo yêu cầu của chúng tôi?) Cho các repos được quản lý của họ. Trên các phiên bản cũ hơn (3.14-3.15), bạn vẫn nhận được một nửa lợi ích bằng cách đặt các biến môi trường phù hợp. Nếu bạn có bí quyết, bạn có thể xây dựng v3.16 trực tiếp. Mặt khác, tăng áp lực bộ đệm và thực hiện cú đánh CPU liên quan có thể là lựa chọn tốt nhất của bạn cho hiệu suất đáng tin cậy.

— J. Paulding

3

Điều này được cố định trong Centos 6.6 với nss-softokn-3.14.3-17

— Strahinja Kustudic

1

Để rõ ràng cho những người đang tìm kiếm một sửa chữa nhanh chóng: bạn phải cập nhật cả nss-softokenRPM và đặt NSS_SDB_USE_CACHE=YESvar env để có các cuộc gọi https dừng lại làm ngập bộ nhớ cache của bạn.

— Steve Kehlet

4

Xem https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm1/broken-out/vfs-shrinkage-tuning.patch

Có những con số cho thấy bạn có thể mong đợi một số bộ nhớ nha khoa đáng chú ý lấy lại khi vfs_cache_pressure được đặt ở mức cao hơn 100. Vì vậy, 125 có thể quá thấp để xảy ra trong trường hợp của bạn.

— sẵn sàng
nguồn

Từ tất cả những gì tôi đã đọc, tăng vfs_cache_pressureở trên 100chỉ có ý nghĩa nếu bạn không có đủ RAM cho khối lượng công việc của mình. Trong trường hợp đó, có cách giá trị trên 100 (ví dụ 10000) sẽ giải phóng một số RAM. Điều đó sẽ dẫn đến IO tổng thể tồi tệ hơn, mặc dù.

— Mikko Rantalainen

3

Không thực sự là một lời giải thích cho câu trả lời của bạn, nhưng là một người dùng của hệ thống này, thông tin này bạn đã cung cấp:

cat /proc/meminfo
MemTotal:       132145324 kB
...
SReclaimable:   44561644 kB
SUnreclaim:      1678736 kB

Là đủ để nói với tôi rằng đây không phải là vấn đề của bạn và trách nhiệm của sysadmin là đưa ra một lời giải thích thỏa đáng.

Tôi không muốn âm thanh thô lỗ ở đây nhưng;

Bạn thiếu thông tin cụ thể về vai trò của máy chủ này.
Làm thế nào máy chủ được cho là ưu tiên tài nguyên nằm ngoài phạm vi của bạn.
Bạn không quen thuộc, hoặc có bất kỳ phần nào trong thiết kế và triển khai lưu trữ trên máy chủ này.
Bạn không thể cung cấp đầu ra hệ thống nhất định vì bạn không root.

Sysadmins của bạn có trách nhiệm biện minh hoặc giải quyết sự bất thường phân bổ phiến. Hoặc là bạn đã không cho chúng tôi một bức tranh hoàn chỉnh về toàn bộ câu chuyện dẫn bạn đến điều này (mà thật lòng tôi không quan tâm) hoặc sysadmin của bạn đang cư xử thiếu trách nhiệm và / hoặc không đủ năng lực trong cách anh ấy xem xét xử lý vấn đề này.

Hãy nói với anh ấy một số người lạ ngẫu nhiên trên internet nghĩ rằng anh ấy không thực hiện trách nhiệm của mình một cách nghiêm túc.

— Matthew Ife
nguồn