Bộ nhớ đã sử dụng trên Solaris 10


10

Thêm một câu hỏi về bộ nhớ trên Solaris 10.

Một đầu cho tôi thấy rằng tôi có bộ nhớ trống 672 MB:

130 processes: 126 sleeping, 2 zombie, 2 on cpu
CPU states: 95.1% idle,  3.9% user,  1.0% kernel,  0.0% iowait,  0.0% swap
Memory: 16G phys mem, 672M free mem, 2048M total swap, 2023M free swap

Một vmstat cho tôi thấy như vậy:

kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr rm s0 s1 s2   in   sy   cs us sy id
0 0 0 564744 687896  3  13  0  0  0  0  0  0  0  0  0  354  667  752  1  1 98

Nhưng khi tôi thực hiện kích thước prstat -a -s, tôi nhận được điều này:

NPROC USERNAME  SWAP   RSS MEMORY      TIME  CPU
   45 orbixadm 1449M 1592M   9.7%   4:46:53 0.4%
   48 root      146M  160M   1.0%   8:09:49 1.2%
    3 user1      46M  204M   1.2%   0:00:45 0.0%
    9 webservd   46M   14M   0.1%   0:00:00 0.0%
    5 ctxsrvr    28M   32M   0.2%   4:54:51 0.0%
   11 user2      23M   34M   0.2%   0:00:37 0.2%
    4 user3    4840K   11M   0.1%   0:00:01 0.0%
    1 smmsp    1456K 4552K   0.0%   0:00:24 0.0%
    2 daemon   2128K 6224K   0.0%   0:06:32 0.0%
    1 user4    1232K 3608K   0.0%   0:00:00 0.0%
    1 nagios    376K 2472K   0.0%   0:15:18 0.0%

và như bạn có thể thấy, tổng giá trị RSS không đạt tới 15GB bộ nhớ và ngay cả khi tôi thêm các giá trị SWAP vào nó.

Vì vậy, câu hỏi của tôi là: tôi tin lệnh nào?

Nếu top và vmstat cho tôi kết quả tốt, bộ nhớ 15GB đã sử dụng của tôi ở đâu? Nếu không, tại sao họ chỉ cho tôi điều đó?

Chỉnh sửa: kết quả cho lệnh: % echo ::memstat | mdb -k

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                    1687138             13180   82%
Anon                       137110              1071    7%
Exec and libs               47107               368    2%
Page cache                  95277               744    5%
Free (cachelist)            22248               173    1%
Free (freelist)             69592               543    3%

Total                     2058472             16081
Physical                  2055442             16058

Chỉnh sửa 2:

Ok, bây giờ tôi có thể thấy bộ nhớ được sử dụng bởi bộ đệm ARC.
Nhưng với một số thử nghiệm mới, bây giờ tôi có:

2066 MB used( prstat -Zecho :: memstat | mdb -k result)
1193 MB free( kết quả trên cùng )
8859 MB ARC cache( kstat zfs :: arcstats: kết quả kích thước )

Điều này cho chúng ta ít nhiều 12 GBbộ nhớ, trong khi hệ thống của tôi có 16 GB.
Có lẽ tôi đã bỏ lỡ một cái gì đó khác, nhưng cái khác ở 4 GBđâu?


Vui lòng thêm kstat zfs::arcstats:sizeđầu ra cho câu hỏi của bạn.
jlliagre

Câu trả lời:


12

ZFS có khả năng sử dụng hầu hết bộ nhớ của bạn làm bộ đệm ARC. Nếu bạn muốn biết RAM của bạn được sử dụng như thế nào, hãy chạy lệnh này với quyền root:

# echo ::memstat | mdb -k

Trên Solaris 10 10/09 và mới hơn, phần này hiển thị như sau:

Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                      60569               236   16%
ZFS File Data               53270               208   14%
Anon                        41305               161   11%
Exec and libs                5891                23    2%
Page cache                   1190                 4    0%
Free (cachelist)             7006                27    2%
Free (freelist)            212607               830   56%

Total                      381838              1491

Như bạn thấy, có một dòng cho biết bao nhiêu RAM được sử dụng để lưu trữ dữ liệu tệp ZFS. Thật không may, bạn đang chạy bản phát hành Solaris 10 cũ hơn nên memstat không hiển thị thống kê ZFS này một cách riêng biệt. Nó được bao gồm trong bộ nhớ Kernel được sử dụng gây nhầm lẫn. Một hạt nhân không nên sử dụng 13 GB RAM trong các trường hợp bình thường.

Dù sao, vẫn có một cách để hiển thị kích thước ARC đầy đủ trên máy chủ của bạn.

Chỉ cần chạy lệnh này:

# kstat zfs::arcstats:size
module: zfs                             instance: 0
name:   arcstats                        class:    misc
        size                            273469024

Nó cho thấy rằng trên máy của tôi, hiện có 273 MB RAM được sử dụng để xử lý bộ đệm ZFS ARC. memstat cho thấy rằng từ 273 MB này, 208 MB được sử dụng làm bộ đệm tệp. Tối đa 208 MB RAM có thể được phát hành tự động theo yêu cầu nếu các ứng dụng cần nó.

Bây giờ hãy xem xét quá trình sử dụng bộ nhớ. Nếu bạn sử dụng tùy chọn -Z với prstat, nó sẽ hiển thị tóm tắt cho mỗi vùng theo thống kê trên mỗi quy trình. Ở đây, khu vực toàn cầu (và duy nhất) đang sử dụng 185 MB RAM. Điều này sẽ (đại khái) khớp với tổng của tất cả các cột rss quy trình.

# prstat -Z
PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
   741 noaccess  129M  113M sleep   59    0   0:00:35 1,4% java/18
   973 root     5148K  832K run     29    0   0:00:00 0,4% script/1
   972 root     5072K  900K sleep   59    0   0:00:00 0,2% script/1
   998 root     7148K 2812K cpu0    49    0   0:00:00 0,1% prstat/1
   974 root     3456K  968K sleep   49    0   0:00:00 0,1% ksh/1
     5 root        0K    0K sleep   99  -20   0:00:01 0,1% zpool-rpool/37
   241 root     5400K 1608K sleep   59    0   0:00:00 0,0% VBoxService/5
    77 root     7620K 2356K sleep   59    0   0:00:00 0,0% devfsadm/7
   969 root     3372K  936K sleep   59    0   0:00:00 0,0% script/1
   126 root     9664K 2844K sleep   59    0   0:00:00 0,0% nscd/31
   480 root     9420K 2036K sleep   59    0   0:00:00 0,0% sendmail/1
    11 root     9164K 7860K sleep   59    0   0:00:29 0,0% svc.configd/17
     1 root     2504K 1432K sleep   59    0   0:00:00 0,0% init/1
   413 root       15M 9644K sleep   59    0   0:00:00 0,0% fmd/19
   377 root     6536K 2848K sleep   59    0   0:00:02 0,0% inetd/4
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
     0       48  177M  185M    12%   0:01:24 2,5% global

185 MB này tương ứng với tổng của hai dòng trong đầu ra memstat: "Anon" là RAM được các ứng dụng sử dụng để lưu trữ dữ liệu và "Exec và libs" là các ứng dụng và mã thư viện của chúng.


Cũng cảm ơn phản hồi của bạn, kết quả của lệnh không thực sự chi tiết, nhưng cần phải xem RAM đang sử dụng cái gì.
Jeremy C.

Bạn có thể thêm đầu ra của nó bằng cách cập nhật câu hỏi của bạn? Nhân tiện, câu trả lời bạn chấp nhận thực sự hơi không chính xác vì các trang chưa được ánh xạ được Solaris báo cáo là RAM miễn phí, không phải là vấn đề mà bạn đang phàn nàn.
jlliagre

Câu hỏi được chỉnh sửa với kết quả lệnh. Bạn nói đúng câu hỏi của tôi không hoàn toàn được trả lời. Ít nhất chúng ta có thể thấy rằng bộ nhớ trống giống với topvmstat so với :: memstat . Nhưng có một ý nghĩa để chi tiết những gì được sử dụng bởi mỗi quá trình?
Jeremy C.

Bạn đang sử dụng bản cập nhật Solaris 10 nào (cat / etc / release) và bạn có đang sử dụng ZFS không?
jlliagre

đó là Solaris 10 5/09 và vâng, tôi sử dụng ZFS
Jeremy C.

4

Bộ nhớ được lấp đầy với các trang dữ liệu chưa được ánh xạ đọc từ đĩa. Nó được giữ trong bộ nhớ vì những tệp đó có thể được đọc lại và giữ dữ liệu trong bộ nhớ sẽ lưu đĩa đọc. Bộ nhớ trống là lãng phí mãi mãi, vì vậy máy tính cố gắng giữ càng ít càng tốt.

Ví dụ, giả sử bạn chạy một chương trình. Chương trình chấm dứt. Chương trình vẫn còn trong bộ nhớ, nhưng những trang bộ nhớ đó không được sử dụng bởi bất kỳ quy trình nào vì chương trình không chạy. Nếu hệ thống không chịu áp lực bộ nhớ, các trang sẽ được giữ trong bộ nhớ. Nếu chương trình chạy lại, điều này sẽ tiết kiệm công sức làm cho nó miễn phí chỉ để phân bổ thêm bộ nhớ cho chương trình và sau đó đọc lại. Và nếu các trang là cần thiết cho một cái gì đó khác, thì nó vẫn là một chiến thắng cho hệ thống bởi vì việc di chuyển một trang bộ nhớ trực tiếp từ sử dụng sang trang khác dễ dàng hơn là làm cho nó miễn phí chỉ để sử dụng lại.

Bộ nhớ không phải là một nguồn tài nguyên có thể hiểu được. Nếu bạn để lại 1GB miễn phí trong một giờ, mọi thứ bạn có thể làm với dữ liệu đó sẽ bị mất vĩnh viễn.


Cảm ơn vì câu trả lời này cũng được giải thích. Bây giờ tôi đã hiểu tại sao tất cả các máy chủ Solaris của tôi đều sử dụng ít nhất 90% RAM.
Jeremy C.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.