Lần trước tôi cũng đập đầu vào tường trong khi gặp vấn đề về trí nhớ Drupal. Đây là kiến thức thu thập của tôi về chủ đề này:
1. Lượt xem (có thể) sử dụng nhiều bộ nhớ
Tôi yêu tôi một số Chế độ xem (và Bảng và CTools và mọi thứ merlinofchaos chạm vào bằng ngón tay mạnh mẽ, dũng mãnh của anh ấy), nhưng có thể tạo cấu hình với nhiều mối quan hệ sử dụng nhiều bộ nhớ. Nếu bạn tắt Chế độ xem của mình và vấn đề bộ nhớ sẽ biến mất, đó có thể là Chế độ xem được xây dựng kém gây ra sự cố.
Phải làm gì nếu đó là Chế độ xem và bạn thực sự cần Chế độ xem đó để hoạt động? Hãy thử đặt mã vào (Thông qua Trình xuất hàng loạt hoặc Tính năng; xem bên dưới. Tôi đã mã hóa chức năng giống như Chế độ xem để cải thiện hiệu suất với rất ít thành công) để bắt đầu. Một suy nghĩ khác là làm lại Chế độ xem theo một cách khác - nếu cuối cùng, những gì bạn nhận được là các thuật ngữ phân loại, hãy đảm bảo loại Chế độ xem là Chế độ phân loại khi tạo; không tạo Chế độ xem nội dung sử dụng các mối quan hệ để đạt được các điều khoản phân loại.
Cũng có thể đáng nói ở đây là các bảng được cho là sử dụng rất nhiều bộ nhớ - tôi chưa thực sự đánh giá nó nên không thể xác nhận điều này.
2. Chuyển công cụ từ cơ sở dữ liệu vào mã là một thực tiễn rất tốt
Tôi phải mất một số trang web Drupal để nhận ra điều này, nhưng giữ tất cả mọi thứ được tạo thông qua giao diện người dùng trong cơ sở dữ liệu (đặc biệt là cấu hình Chế độ xem và Bảng) là một thực tiễn tồi tệ nhất của Drupal. Tại sao? Nó tăng tải trên cơ sở dữ liệu và không thể kiểm soát phiên bản. Điểm đầu tiên đặc biệt có vấn đề về việc sử dụng bộ nhớ - thay vì chỉ tải nội dung từ Chế độ xem từ cơ sở dữ liệu, trang web cũng phải tự tải các thành phần xem. Điều này trở nên trầm trọng hơn bởi cách Drupal sử dụng các bảng: bằng cách trừu tượng hóa mọi thứ đến mức thứ n, mỗi bit chức năng của Drupal sử dụng một bảng mới, dẫn đến một số yêu cầu nối các bảng bajillion lại với nhau. Điều này mang lại cho người khoa học máy tính thoát vị (caveat: link là ngớ ngẩn), nhưng thực sự không thể tránh được với một phần mềm có tính mô-đun và thân thiện với người dùng như Drupal.
Giải pháp? Sử dụng Trình xuất hàng loạt (Bao gồm CTools) hoặc Tính năng để đóng gói các bit mã hiện đang lưu trữ trong cơ sở dữ liệu dưới dạng mã mô-đun.
3. Chủ đề cũng có thể ăn bộ nhớ
Chủ đề của bạn có nhiều tệp mẫu (Tức là, tệp trong themename / samples /) không? Nếu vậy, bộ nhớ được tiêu thụ mỗi khi một trong những tệp đó được tải. Nếu bạn đang tạo các mẫu cụ thể để ngăn chặn các bit của Drupal được hiển thị, hãy thử:
- Thay đổi quyền để bit không hiển thị cho các vai trò người dùng không phải quản trị viên cụ thể.
- Sử dụng CSS để ẩn các phần tử.
Sự lựa chọn đầu tiên rõ ràng là những gì bạn muốn làm cho những thứ ảnh hưởng đến bảo mật - bạn không muốn sử dụng CSS để ẩn nút "chỉnh sửa" đối với một số người dùng nhất định, chỉ để họ bỏ qua nó thông qua Fireorms hoặc bất cứ điều gì.
4. Đừng quá nhiệt tình với các mô-đun đóng góp
Mặc dù đôi khi một trang web cần rất nhiều mô-đun đóng góp, đừng quá nhiệt tình. Mỗi mô-đun được bật (lưu ý: đã bật. Các mô-đun bị vô hiệu hóa không sử dụng bất kỳ bộ nhớ nào) sử dụng bộ nhớ. Điều này là một chút rõ ràng, nhưng đáng chú ý bất kể.
5. VPS là (đôi khi) là một lời nói dối
Theo kinh nghiệm của tôi, một số công ty lưu trữ vô đạo đức thích thử đẩy các trang web Drupal lên máy chủ VPS - chúng đắt hơn và nó giải phóng không gian lưu trữ được chia sẻ cho các trang web WordPress ngày càng nhiều hơn. Tình hình trở nên tồi tệ hơn khi các webhost thường không quảng cáo (Hoặc thậm chí sẵn sàng cho bạn biết nếu được hỏi) giới hạn bộ nhớ trên dành cho lưu trữ chia sẻ.
Than ôi, thường là nếu một trang web không có lưu lượng truy cập lớn và vẫn bị sập, vấn đề có thể liên quan đến cấu hình của Drupal hơn bất kỳ điều gì khác. Đẩy người dùng vào VPS chỉ làm vấy bẩn vùng biển và thêm nhiều biến để xử lý (Đây có phải là cấu hình máy chủ web không? Cấu hình PHP? Cấu hình máy khách VPS? Cấu hình máy chủ VPS, thậm chí?).
6. Khi thất bại, sao chép vào localhost và đánh nó bằng gậy
Đây là một lý do lớn tại sao mọi người sử dụng phương pháp sản xuất dev-staging với kiểm soát phiên bản - khi tất cả các lỗi khác, bạn có thể thực hiện kết xuất DB, git sao chép trang web vào một máy chủ thử nghiệm cục bộ và sau đó làm rối tung trang web trên máy chủ thử nghiệm mà không lo lắng về việc thực sự phá vỡ bất cứ điều gì trên máy chủ sản xuất.
Đối với các vấn đề về bộ nhớ, điều này thường có nghĩa là vô hiệu hóa từng mô-đun cho đến khi một nguyên nhân gây ra sự cố được phơi bày. Nó cũng có thể chỉ ra các vấn đề liên quan đến webhost - nếu trang web chạy hoàn toàn tốt trên cài đặt cục bộ với bộ nhớ được đặt ở mức hợp lý như 128MB, thì bạn biết webhost của bạn đang bị bẻ khóa.
tl; dr
Quan điểm của tôi là đó là chain_menu_access gây ra vấn đề. Hãy thử vô hiệu hóa nó và xóa bộ nhớ cache, xem nó có hoạt động không.
Tôi cũng sẽ thêm vào câu trả lời này khi tôi nghĩ về những thứ khác để thử ...