Việc sử dụng bộ nhớ được báo cáo bởi guppy khác với lệnh ps

Question

Tôi đang định cấu hình máy chủ bị xoắn của mình. Nó sử dụng nhiều bộ nhớ hơn tôi mong đợi. Việc sử dụng bộ nhớ của nó tăng theo thời gian.

ps -o pid,rss,vsz,sz,size,command 
    PID RSS VSZ SZ SZ COMMAND 
7697 70856 102176 25544 88320 twistd -y broadcast.tac 

Như bạn có thể nhìn thấy nó tốn 102.176 KBs, cụ thể là, 99,78125 MBS. Và tôi sử dụng guppy từ một cửa cống xoắn để xem hồ sơ sử dụng bộ nhớ.

>>> hp.heap() 
Partition of a set of 120537 objects. Total size = 10096636 bytes. 
Index Count %  Size % Cumulative % Kind (class/dict of class) 
    0 61145 51 5309736 53 5309736 53 str 
    1 27139 23 1031596 10 6341332 63 tuple 
    2 2138 2 541328 5 6882660 68 dict (no owner) 
    3 7190 6 488920 5 7371580 73 types.CodeType 
    4 325 0 436264 4 7807844 77 dict of module 
    5 7272 6 407232 4 8215076 81 function 
    6 574 0 305776 3 8520852 84 dict of class 
    7 605 1 263432 3 8784284 87 type 
    8 602 0 237200 2 9021484 89 dict of type 
    9 303 0 157560 2 9179044 91 dict of zope.interface.interface.Method 
<384 more rows. Type e.g. '_.more' to view.> 

Hum ... Có vẻ như đã xảy ra sự cố. Guppy cho thấy tổng mức sử dụng bộ nhớ là 10096636 byte, cụ thể là 9859.996 KBs hoặc 9.628 MBs.

Đó là một sự khác biệt rất lớn. Có gì sai kết quả lạ này? Tôi đang làm gì sai?

Cập nhật: Tôi đã viết kịch bản theo dõi đêm qua. Nó ghi lại việc sử dụng bộ nhớ và số lượng người dùng trực tuyến. Nó là một máy chủ radio, vì vậy bạn có thể thấy có radio và tổng số người nghe. Đây là hình tôi tạo bởi matplotlib. alt text http://static.ez2learn.com/temp/mem_figure.svg

Điều gì đó thật lạ. Đôi khi việc sử dụng bộ nhớ được in bởi ps rất thấp, như thế này

2010-01-15 00:46:05,139 INFO 4 4 17904 36732 9183 25944 
2010-01-15 00:47:03,967 INFO 4 4 17916 36732 9183 25944 
2010-01-15 00:48:04,373 INFO 4 4 17916 36732 9183 25944 
2010-01-15 00:49:04,379 INFO 4 4 17916 36732 9183 25944 
2010-01-15 00:50:02,989 INFO 4 4 3700 5256 1314 2260 

Lý do giá trị siêu thấp của việc sử dụng bộ nhớ là gì? Và những gì hơn nữa, thậm chí không có radio trực tuyến, không có người nghe, việc sử dụng bộ nhớ vẫn còn cao.

Answer 1

có thể do trao đổi/phòng bộ nhớ, dựa trên định nghĩa ps của:

RSS: resident set size, the non-swapped physical memory 
    that a task has used (in kiloBytes). 

VSZ: virtual memory usage of entire process. 
    vm_lib + vm_exe + vm_data + vm_stack 

nó có thể là một chút bối rối, 4 số liệu kích thước khác nhau có thể được nhìn thấy với:

# ps -eo pid,vsz,rss,sz,size,cmd|egrep python 

PID VSZ RSS SZ SZ CMD 
23801 4920 2896 1230 1100 python 

kích thước ảo bao gồm bộ nhớ được dành riêng cho quy trình và không được sử dụng, kích thước của tất cả thư viện được tải, trang được hoán đổi và các khối đã được giải phóng bởi quy trình của bạn, vì vậy nó có thể lớn hơn nhiều so với kích thước của tất cả các đối tượng trong python.

một số công cụ bổ sung để điều tra hiệu suất bộ nhớ:

• Heapy (một phần của Guppy, mà bạn đang sử dụng): http://guppy-pe.sourceforge.net/

• Python Memory Validator http://www.softwareverify.com/python/memory/index.html

• PySizer http://pysizer.8325.org/

hướng dẫn tốt về theo dõi xuống rò rỉ bộ nhớ trong python sử dụng pdb và objgraph:

http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks

Answer 2

Như đã chỉ ra ở trên kích thước RSS là gì bạn quan tâm nhất ở đây.Kích thước "ảo" bao gồm các thư viện được ánh xạ, mà bạn có thể không muốn đếm.

Đã lâu rồi kể từ khi tôi sử dụng tính năng heapy, nhưng tôi khá chắc chắn rằng số liệu thống kê mà nó in không bao gồm phí được thêm vào bởi chính bản thân heapy. Chi phí này có thể khá đáng kể (tôi đã thấy một quá trình RSS 100MB phát triển thêm một tá hoặc hơn MB, xem http://www.pkgcore.org/trac/pkgcore/doc/dev-notes/heapy.rst).

Nhưng trong trường hợp của bạn, tôi nghi ngờ vấn đề là bạn đang sử dụng một số thư viện C hoặc bị rò rỉ hoặc sử dụng bộ nhớ theo cách mà heapy không theo dõi. Heapy là nhận thức của bộ nhớ được sử dụng trực tiếp bởi các đối tượng python, nhưng nếu những đối tượng bọc C đối tượng được phân bổ riêng biệt heapy không phải là bình thường nhận thức của bộ nhớ đó cả. Bạn có thể thêm hỗ trợ heapy vào các ràng buộc của bạn (nhưng nếu bạn không kiểm soát các ràng buộc bạn sử dụng rõ ràng là một rắc rối, và thậm chí nếu bạn kiểm soát các ràng buộc, bạn có thể không làm được điều này tùy thuộc vào thứ bạn đang gói).

Nếu có rò rỉ ở cấp độ C, heapy cũng sẽ mất dấu vết của bộ nhớ đó (kích thước RSS sẽ tăng lên nhưng kích thước báo cáo của heapy sẽ giữ nguyên). Valgrind có lẽ là đặt cược tốt nhất của bạn để theo dõi chúng, giống như trong các ứng dụng C khác.

Cuối cùng: phân mảnh bộ nhớ thường sẽ làm cho việc sử dụng bộ nhớ của bạn (như đã thấy ở trên cùng) tăng lên nhưng không giảm (nhiều). Điều này thường không phải là vấn đề với daemon, vì quá trình này sẽ sử dụng lại bộ nhớ này, nó không được phát hành lại cho hệ điều hành, vì vậy các giá trị ở trên không quay trở lại. Nếu sử dụng bộ nhớ (như được thấy ở đầu) tăng lên nhiều hoặc ít tuyến tính với số lượng người dùng (kết nối), không quay trở lại, nhưng cũng không tiếp tục phát triển mãi mãi cho đến khi bạn đạt số lượng người dùng tối đa mới, có thể phân mảnh đổ lỗi.

Answer 3

Đây không phải là câu trả lời hoàn chỉnh, nhưng từ cửa cống của bạn, tôi cũng khuyên bạn nên chạy gc.collect() trước khi tìm bằng ps hoặc trên cùng. guppy sẽ hiển thị vùng phân bổ, nhưng không làm bất cứ điều gì để chủ động các đối tượng miễn phí không còn được cấp phát nữa.