Một cái gì đó ăn tất cả bộ nhớ (Tôi nghi ngờ rò rỉ bộ nhớ trên một số ứng dụng). Làm thế nào để phát hiện những gì?

16

Tôi có máy chủ chạy gói liquidsoap + icecast và trang web đơn giản (httpd + mysqld). Không có gì đặc biệt. Khách truy cập khoảng 2000+ mỗi ngày, trung bình có khoảng 50 người trực tuyến.

Máy chủ có RAM 8GB. Thời gian trôi qua, lượng bộ nhớ trống liên tục giảm, mặc dù không có gì mới được bắt đầu trên máy chủ và không có người dùng mới. Tại một số điểm, nó bắt đầu trao đổi, tải trên máy chủ tăng lên và nó không phản hồi. Thông thường những gì tôi làm chỉ là khởi động lại máy chủ ...

Những gì có thể được thực hiện để phát hiện chính xác những gì rò rỉ bộ nhớ? Tôi sử dụng hàng đầu để theo dõi việc sử dụng tài nguyên, nhưng theo như tôi thấy thì nó không cho thấy gì hữu ích:

nhập mô tả hình ảnh ở đây

Có cách nào để tìm ra những gì sử dụng nhiều bộ nhớ? hoặc những gì bắt đầu để trao đổi vào đĩa nặng? Bất kỳ cách nào để giải phóng bộ nhớ mà không cần khởi động lại máy chủ?

— jayarjo
nguồn

Bất kỳ lý do nào khiến bạn không thử khởi động lại một số dịch vụ (apache, liquidsoap) thay vì máy chủ?

— jamespo

Ban đầu tôi trả lời cho việc sử dụng bộ nhớ bình thường. Tôi đã cập nhật với một bộ công cụ có thể giúp xác định vấn đề.

— BillThor

@jamespo, thực sự tôi đã thử nó, nhưng nó không có tác dụng, vì vậy khởi động lại là điều duy nhất tôi biết có thể giúp đỡ.

— jayarjo

Bộ nhớ đệm 4027092k sẽ giải thích việc sử dụng bộ nhớ, phải không? Hiện tại tôi đang xử lý một vấn đề tương tự ở nơi khác và cho đến nay tôi đã tìm ra cách truyền bộ nhớ có thể được điều chỉnh với các thông số sau: vfs_cache_pressure vm.denty_ratio vm.dundred_background_ratio Đây không phải là một sửa chữa hoàn chỉnh và bất kỳ phản hồi nào Chào mừng bạn nhất. Tôi hy vọng đó là một hướng đi đúng đắn.

16

Chạy toptrong chế độ hàng loạt để báo cáo kích thước bộ nhớ theo định kỳ có thể được sử dụng để xem ai đang sử dụng bộ nhớ khi mọi thứ đi về phía nam. Chạy sartrong chế độ hàng loạt sẽ cung cấp một số chẩn đoán tốt về sử dụng bộ nhớ và I / O liên quan. Chạy muninđể giám sát hệ thống sẽ cung cấp cho bạn một biểu đồ với chi tiết tốt về bộ nhớ đang được sử dụng để làm gì. Điều này có thể giúp rất nhiều.

Bạn có thể sử dụng giới hạn.conf để giới hạn kích thước lõi tối đa của chương trình. Đặt đúng, điều này sẽ giết bất kỳ chương trình nào bị rò rỉ bộ nhớ. Điều này hoạt động với mô-đun pam_limits. Giới hạn cũng có thể được thiết lập với ulimitslệnh.

Bạn đang chạy một vài chương trình có thể sử dụng một lượng lớn bộ nhớ. Một số điều bạn có thể nhìn vào bao gồm.

Các ứng dụng được lập trình kém chạy dưới apache2có thể rò rỉ bộ nhớ. Bạn sẽ thấy kích thước bộ nhớ tăng lên khi điều này xảy ra. Bạn có thể điều chỉnh apache2 để tái chế trẻ em sau một số lần sử dụng nhất định bằng cách đặt MaxRequestsPerChildthành 100 hoặc hơn. Nếu điều này giải quyết vấn đề, thì bạn cần giải quyết rò rỉ. Tôi sẽ xem cái này trước.
MySQL có thể cố gắng tải dữ liệu vào bộ nhớ. Nếu bạn có nhiều dữ liệu trong bộ nhớ, điều này có thể gây ra một số sự cố, nhưng không nên kịch tính như bạn đang thấy.
Nếu bạn có một tmpfshệ thống tệp lớn được gắn, thì bạn có thể bị rò rỉ bộ nhớ nếu các tệp không bị xóa khi sử dụng. Các tập tin lớn sống lâu cũng có thể là một vấn đề.
Nếu sự cố xảy ra vào khoảng cùng thời gian trong ngày, bạn có thể có một chương trình theo lịch trình bị rò rỉ bộ nhớ.
Nếu bạn có một chương trình phân bổ bộ nhớ dùng chung, nhưng không giải phóng nó trước khi thoát, bạn sẽ bị rò rỉ bộ nhớ tương đối vô hình. Nếu bộ nhớ chia sẻ bị khóa trong bộ nhớ, thì nó có thể buộc phải tráo đổi. Số lượng bộ nhớ chia sẻ có sẵn thường tương đối hạn chế.
Gói liquidsoap + icecast có thể gặp phải các vấn đề về bộ đệm sử dụng bộ nhớ. Tôi chưa sử dụng kết hợp này, vì vậy tôi không chắc nó sẽ xuất hiện như thế nào.

Sử dụng bộ nhớ bình thường: Bộ nhớ trống không phải là thứ bạn muốn nhiều. Nếu hệ thống của bạn đã hoạt động trong một thời gian dài và có nhiều bộ nhớ trống thì có gì đó không ổn. Mỗi khi bạn đọc hoặc viết một tập tin, các khối sẽ đi vào bộ đệm. Điều này sẽ làm giảm bộ nhớ miễn phí của bạn, và là một điều tốt. Hệ thống sẽ giữ đủ không gian trống để bắt đầu một vài chương trình mà không cần tìm bộ nhớ ở nơi khác. Vì nhiều chương trình chạy nhanh, bộ nhớ của chúng sẽ được đưa trở lại nhóm miễn phí khi chúng ngừng chạy.

Khi bạn đọc một tệp trong bộ đệm bộ đệm, không cần truy cập đĩa và việc đọc được giải quyết từ bộ đệm bộ đệm. Người viết sử dụng một cơ chế tương tự. Nếu hệ thống của bạn cần bộ nhớ, bộ đệm bộ đệm là một trong những nơi đầu tiên được sử dụng. Hầu hết các bộ đệm có thể được phát hành ngay lập tức.

Nếu bạn bị rò rỉ bộ nhớ, bạn sẽ thấy bộ nhớ trống và cả bộ đệm bắt đầu co lại. Đây vẫn không phải là một vấn đề nghiêm trọng, vì bộ nhớ bị rò rỉ cuối cùng sẽ được chuyển sang không gian trao đổi. Hệ thống của bạn vẫn sẽ chạy tốt cho đến khi bạn lấp đầy không gian hoán đổi và rút xuống không gian trống còn lại để các chương trình điểm không thể bắt đầu. Điển hình là một lượng nhỏ không gian hoán đổi có thể được sử dụng.

— BillThor
nguồn

Vấn đề trong trường hợp của tôi là hơi lạ. Ngay cả khi tải rất lớn và máy chủ hoán đổi rất nhiều, vẫn có rất nhiều bộ nhớ trống (như tôi đã hiểu sau khi tôi đọc về bộ đệm và bộ đệm). top không hiển thị bất kỳ quá trình ăn cắp bộ nhớ ngày càng tăng. Nhưng tải tăng lên và tại một số điểm máy chủ trở nên không sử dụng được: | Cảm ơn đã phản ứng chi tiết.

— jayarjo

2

@jayarjo: Munin và sar sẽ giúp phát hiện những gì đang diễn ra. Nếu bạn có nhiều bộ nhớ trống, bạn không nên trao đổi. Bạn có thể có một vấn đề I / O khác nhau. sarsẽ giúp xác định chính xác phân vùng nào có I / O và có thể giúp khám phá vấn đề.

— BillThor

+1 cho lời khuyên MaxRequestsPerChild

— jamespo

11

Bạn có thể sử dụng lệnh này để xem 10 ứng dụng hàng đầu liên quan đến việc sử dụng RAM:

ps -A --sort -rss -o comm,pmem | head -n 11

Đôi khi lệnh này giúp bạn nếu nhiều quy trình phụ đã được tạo:

ps auxf

Bằng cách này bạn có thể thấy các quá trình thuộc về nhau.

— Raffael Luthiger
nguồn

Đây là những lệnh tiện dụng, cảm ơn tôi sẽ lưu ý chúng cho tương lai. Nhưng vấn đề là luôn có các quy trình giống nhau ở trên cùng (bạn có thể thấy chúng trong ảnh chụp màn hình đính kèm) - apache, mysql, liquidsoap, icecast. Và họ sử dụng (hoặc ít nhất là được hiển thị để sử dụng) cùng một lượng bộ nhớ (thực sự không đáng kể), ngay cả khi máy chủ sắp hết tải: |

— jayarjo

@jayarjo: Số lượng quá trình thay đổi? Bạn có nhiều quá trình hơn? Và nó là một máy chủ vật lý hay một máy chủ ảo?

— Raffael Luthiger

Tôi đã không nhận thấy bất kỳ thay đổi trong số lượng các quy trình. Về cơ bản khi tôi làm hàng đầu, trong khi máy chủ sắp hết tải tôi thấy một hình ảnh rất giống với những gì tôi đã đính kèm trong câu hỏi ban đầu, ngoại trừ tải rất lớn: | Máy chủ là vật lý.

— jayarjo

2

Cố gắng lấy thêm thông tin với "vmstat" (ví dụ: vmstat -s). Hoặc với công cụ đã được đề cập "sar". Bạn có thể có một hệ thống tập tin dựa trên RAM? Sau đó, có lẽ "iuler" cũng có thể cung cấp thêm thông tin.

— Raffael Luthiger

1

Tôi đã nghi ngờ liệu trường "pmem" (% MEM) trong pshoặc topđầu ra là điều đúng đắn để xem xét nếu cố gắng phát hiện rò rỉ bộ nhớ: Đây có phải chỉ là tỷ lệ phần trăm của bộ nhớ vật lý mà quá trình hiện đang sử dụng không? Nhưng các phần khác của bộ nhớ được sử dụng (bao gồm rò rỉ) có thể bị tráo đổi. Có lẽ "kích thước" hoặc "vsize" sẽ phù hợp hơn để đo kích thước của một quy trình? Ví dụ: ps -A --sort -size -o comm,size | head -n 11hoặcps -A --sort -vsize -o comm,vsize | head -n 11

— imz - Ivan Zakharyaschev

8

Không có gì thực sự sử dụng bộ nhớ đó trong các ứng dụng.

Bạn cần khấu trừ giá trị 'được lưu trong bộ nhớ cache đại diện cho bộ đệm trang để có ý tưởng tốt hơn về mức độ sử dụng bộ nhớ thực của bạn về mặt sử dụng chương trình.

Về cơ bản đây là quản lý bộ nhớ tốt và đây là lý tưởng những gì bạn muốn.

Xem liên kết tại đây để biết thêm thông tin: http://www.linuxHRyram.com/

— Matthew Ife
nguồn

có tìm thấy liên kết và đọc về bộ đệm và bộ nhớ cache, nhưng theo như tôi có thể nhận được từ những gì tôi đọc, chúng không thể gây ra sự hoán đổi, phải không?

— jayarjo

@jayarjo Tôi nghĩ để hiểu những gì xảy ra ở đó chúng ta sẽ cần số liệu thống kê chứng minh vấn đề sau đó. Các số bạn đã cung cấp không hiển thị trao đổi hoặc sử dụng nhiều bộ nhớ thực.

— Matthew Ife

1

Tôi không phải là một chuyên gia về điều này thực sự, nhưng xà phòng lỏng + icecast có liên quan đến đa phương tiện. Khi hệ thống miễn phí, nó lưu trữ và / hoặc chiếm bộ nhớ để sử dụng trong tương lai. Và nếu lưu lượng truy cập tăng vào một thời điểm nhất định trong ngày / trong một khoảng thời gian, thì nó sẽ bắt đầu hoán đổi. Tại thời điểm này, nếu các yêu cầu (người dùng xem nội dung) tăng lên, thì tài nguyên cần thiết sẽ nhiều hơn 8GB ram.

— Yash
nguồn