2010-07-28 30 views
11

Tôi đã chơi với điều này trong một thời gian nhưng tôi không biết phải làm gì. Tôi đang sử dụng APC 3.1.3p1 trên CentOs 5 với PHP 5.2.5. APC hoạt động như cả bộ nhớ cache opcode và bộ nhớ cache của người dùng. Chủ yếu là máy chủ này chạy Drupal 6 trang web bằng cách sử dụng mô-đun CacheRouter để hỗ trợ bộ nhớ cache APC. Tôi đã chạy APC 3.0.19 trong một thời gian nhưng nó đã gây ra Apache để khóa lên thỉnh thoảng (một lỗi tài liệu trong phiên bản của APC) vì vậy đó là lý do tại sao tôi đang ở trên 3.1.3p1.Tại sao APC lại tăng "Tổng số bộ nhớ cache" cho Bộ nhớ cache của người dùng mặc dù nó có nhiều bộ nhớ khả dụng?

Tôi đã định cấu hình APC để có 512 MB bộ nhớ (mmap).

Các triệu chứng là một chút gián đoạn nhưng bắt đầu từ một bộ nhớ cache trống này thường là những gì tôi nhìn thấy:

  • Bộ nhớ cache dùng điền khá chậm. Mặc dù tỷ lệ chèn ban đầu là 20.000 lần/giây, bộ nhớ cache của người dùng sẽ chỉ báo cáo vài trăm, sau đó vài nghìn mục nhập và sẽ phát triển rất chậm. Tôi có thể có thể thuộc tính này để write_locking được trên nhưng chỉ muốn đề cập đến nó trong trường hợp đó là tầm quan trọng trong việc giải quyết vấn đề ở bàn tay. Sau vài giờ, nó đạt mức cân bằng khoảng 30k mục.

  • Phân mảnh sớm và phát triển nhanh chóng. Trong vòng 10 giờ hoặc lâu hơn tôi thường bị phân mảnh 100%.

  • Mức sử dụng bộ nhớ cache tổng thể (opcode + user) ổn định khoảng 240MB. Nó hầu như không bao giờ vượt lên trên mức đó. Sau một ngày hoặc lâu hơn, tôi sẽ bắt đầu nhìn thấy việc tăng số lượng bộ nhớ cache của người dùng (UCCFC).

Tại thời điểm viết bài này, UCCFC của tôi ở mức 62358 và đang phát triển mặc dù APC báo cáo 280MB miễn phí. Tôi có một user_ttl của 7200, nhưng tôi cũng đã chơi với thiết lập nó 0 hoặc các số tiền khác và nó có ít hoặc không có hiệu lực về vấn đề này.

Tôi nghi ngờ vấn đề có liên quan đến phân mảnh. Ngay bây giờ máy chủ của tôi đang báo cáo "Phân mảnh: 100.00% (280.0 MByte trong số 280.0 MByte trong 24740 đoạn)" và 280 MB chỉ xảy ra là số lượng APC không gian trống đang báo cáo; một sự trùng hợp, tôi nghĩ vậy. Thật không may, tôi đã tìm thấy ít thông tin quý giá trong tài liệu hoặc ở nơi khác để chỉ ra những gì "phân mảnh" thực sự có nghĩa là trong thế giới APC, và có vẻ như hầu như không có gì bạn có thể làm để tránh nó.

Có ai có thể làm sáng tỏ vấn đề này không?

+0

Bạn đã thử tăng dung lượng bộ nhớ dùng chung chưa? –

+0

Cảm ơn bạn đã phản hồi. Tôi đã chơi với các thiết lập khá một chút, mặc dù tôi chưa bao giờ thiết lập nó với hơn 512MB. Thật thú vị, khi tôi cấu hình nó với 256MB, sử dụng bộ nhớ thường nằm trong phạm vi 220MB để lại khoảng 30MB miễn phí. Nhưng tổng số bộ nhớ cache của tôi thường bắt đầu tăng nhanh hơn nhiều so với khi nó được cấu hình với 512MB mặc dù việc sử dụng bộ nhớ thô là rất giống nhau. – Aaron

Trả lời

22

APC tính toán tỷ lệ phần trăm phân mảnh bằng cách sử dụng công thức sau:

(total_size_of_free_blocks_lt_5M/total_size_of_all_free_blocks) * 100 

* Lưu ý rằng nó chỉ đếm khối nhỏ hơn 5M như phân mảnh.

tôi sẽ dịch trường hợp cụ thể của bạn vào đồng bằng tiếng Anh:

Phân mảnh: 100.00% (280,0 MByte ra khỏi 280,0 MByte trong 24.740 mảnh vỡ)

Điều này có nghĩa rằng các 280M của các khối miễn phí của bạn tất cả trong số đó ít hơn 5 triệu.Nếu bạn chia không gian trống của mình cho số mảnh bạn sẽ thấy rằng điều này tương đương với kích thước phân đoạn trung bình ~ 11,6K. Điều này có nghĩa là nếu bạn cố gắng lưu trữ một mục lớn hơn tất cả các khối có sẵn, nó sẽ không phù hợp và một trong hai điều sẽ xảy ra, dựa trên số apc.user_ttlconfiguration setting. Nếu TTL được đặt thành 0, toàn bộ bộ nhớ cache của người dùng của bạn bị xóa và mục được chèn vào. Nếu TTL được đặt lớn hơn 0 thì nó sẽ xóa các mục đã hết hạn và chèn mục. Trong cả hai trường hợp này, tổng số bộ nhớ cache được tăng lên. Có sự gia tăng này nhiều như trong trường hợp của bạn là một chỉ báo rằng bạn có thể là doing it wrong.

Dưới đây là hình ảnh đơn giản về những gì phân mảnh đang làm cho bộ nhớ cache của bạn theo thời gian. Nó đại diện cho một kích thước bộ nhớ cache 32 Byte đơn giản, mỗi khối là 1B.

 
[--------------------------------] (starts empty) 
[A-------------------------------] (1B stored) 
[ABB-----------------------------] (2B stored) 
[ABBCCCC-------------------------] (4B stored) 
... (time elapses) 
[A--CCCC-EEE--GGGGGG-III--KKKLLLL] 

Vì vậy, bây giờ nếu bạn muốn lưu trữ mục M, đó là kích thước 4B, bạn có thể không, bởi vì các khối có sẵn lớn nhất là 2B. Điều này kích hoạt tăng tổng số bộ nhớ cache, và tuôn ra toàn bộ hoặc một phần dựa trên user_ttl được giải thích chi tiết ở trên.

Bây giờ câu hỏi là: Điều này có tệ trong trường hợp của bạn không?

Tôi nghĩ có thể là vậy. 100% bộ nhớ cache phân mảnh không phải là xấu trong và của chính nó. Nó không phải là không phổ biến để thấy rằng trên bất kỳ máy chủ sản xuất đang chạy. Tuy nhiên, để xem nó ở 100% với rằng nhiều không gian trống là dấu hiệu cho thấy có điều gì đó không ổn.

  • Bạn có thể đang lưu vào bộ nhớ cache quá nhiều; chỉ vì bộ nhớ cache không có nghĩa là bạn nên bỏ mọi thứ vào đó.
  • Bạn có thể lưu vào bộ nhớ đệm quá ngắn TTL (đối với mục nhập), TTL thấp nghĩa là các khối không miễn phí được giải phóng thường xuyên hơn.
  • Cũng có thể bạn có một số mặt hàng thực sự lớn mà bạn đang cố gắng lưu trữ. Ở phân mảnh 100%, đảm bảo rằng bất kỳ mục nào> = 5M sẽ không vừa. Với kích thước khối miễn phí trung bình 11,6K của bạn, ngày càng có nhiều khả năng một mục nhất định sẽ không vừa với kích thước của nó tăng quá 11,6K.

Bạn có thể muốn thử sắp xếp bộ nhớ cache của người dùng theo kích thước và xem mục nhập lớn nhất của bạn là gì và TTL của họ là gì. Có lẽ chúng có thể tăng lên? Nó không thực sự có thể đưa ra một chẩn đoán chính xác mà không được khuỷu tay sâu trong ứng dụng của bạn (s) và các mẫu sử dụng, nhưng tất cả các thông tin này nên đặt bạn đi đúng hướng. Nó khá có thể là nó không phải là vấn đề và bạn chỉ có thể cho APC làm công việc của nó một cách lặng lẽ.

+0

Tôi chỉ muốn theo dõi. Chúng tôi chuyển sang APC 3.1.4 và hiệu suất phân mảnh của nó được cải thiện đáng kể. Chúng tôi hiện đang nhận được hành vi nhiều hơn nữa phù hợp với những gì chúng tôi mong đợi. – Aaron

Các vấn đề liên quan