Lệnh drush cc all` mất quá nhiều thời gian, tôi có thể làm gì?

Trên một trang web của tôi drush cc allmất hơn 4 phút để chạy. Trang web db là một vài GB. Tuy nhiên, tôi không thể thấy một lý do rõ ràng là tại sao nó lại mất quá nhiều thời gian. Tôi có thể làm gì để xác định vị trí cổ chai?

Việc tự xóa bộ nhớ cache không mất nhiều thời gian, vì nó chỉ cắt bớt các bảng bộ đệm. Điều cần nhiều thời gian nhất là xây dựng lại registry registry sau đó. Thông thường, đó là sổ đăng ký chủ đề quét tất cả các hook mới và tất cả các thư mục Drupal của bạn cho các tệp mẫu mới, hệ thống quét các tệp cho các mô-đun và tệp lớp mới, và tương tự.

Bạn luôn có thể xóa bộ nhớ cache cụ thể bằng cách chỉ định drush cc theme-registryhoặc bất kỳ khác.

Chúng tôi khuyên bạn nên sử dụng cơ chế bộ đệm của PHP (ví dụ: OPCache, XCache, v.v.) để tăng tốc độ xử lý. Và bộ nhớ cache cơ sở bộ nhớ để thay thế việc sử dụng nhiều trên các bảng SQL (ví dụ: memcached hoặc redis), vì vậy việc xóa bộ đệm sẽ không mất thời gian, chỉ bằng cách xóa bộ đệm (ví dụ như echo flush_all > /dev/tcp/127.0.0.1/11211trong Bash).

Ngoài ra, bạn luôn có thể xóa bộ nhớ cache theo cách thủ công , ví dụ:

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v

Gỡ lỗi

Để kiểm tra những gì mất thời gian cụ thể nhất, bạn cần gỡ lỗi / hồ sơ nó (ví dụ XDebug, XHProf, phpdbg, dtrace).

Trên OS X / Unix, điều này có thể đạt được bằng cách dtrace(sau khi chạy drush):

sudo dtrace -qn 'php*:::function-entry { printf("%Y: PHP function-entry:\t%s%s%s() in %s:%d\n", walltimestamp, copyinstr(arg3), copyinstr(arg4), copyinstr(arg0), basename(copyinstr(arg1)), (int)arg2); }'

Trên Linux, sử dụng strace, vd

strace -e trace=sendto,recvfrom -s1000 -p $(pgrep php)

Để tìm kiếm một số điều cụ thể, hãy thử thêm ví dụ : strace ... 2>&1 | grep -C5 UPDATE.

Nếu bạn có một cơ sở dữ liệu thực sự lớn và hệ thống của bạn đang hoạt động tốt khi bạn không xóa bộ nhớ cache, có khả năng là bạn không có đủ bộ nhớ để hỗ trợ đầy đủ cho thiết lập của mình.

Nếu trang web của bạn đang chạy trên hộp Linux, hãy chạy 'top' (từ trình bao của bạn) và nhấn shift-M để sắp xếp danh sách quy trình theo bộ nhớ được sử dụng. Sau đó, chạy hoạt động xóa bộ nhớ cache của bạn từ một thiết bị đầu cuối khác. Bạn sẽ thấy mysql và apache tăng lên đầu danh sách. Bạn sẽ có thể xem bao nhiêu phần trăm tổng bộ nhớ mà mỗi quá trình này đang sử dụng và bao nhiêu RAM miễn phí được sử dụng. Nếu bạn có một lượng không gian ảo lớn, nhưng tất cả RAM vật lý của bạn đã cạn kiệt, thao tác này có thể khiến bộ nhớ VM bị hỏng, điều này có thể khiến thời gian thực hiện của bạn giảm xuống một phần nhỏ so với bình thường.

Một lần, tôi đang chạy một trang web Drupal lưu lượng trung bình trên một hộp với bộ nhớ đủ để hỗ trợ thiết lập. Khi tôi chạy xóa bộ nhớ cache trên một trang web có lưu lượng truy cập thấp không liên quan, việc xây dựng lại bộ đệm đã đẩy hệ thống vượt quá giới hạn của nó và tất cả mọi thứ đều bị khóa. Vì vậy, toàn bộ hành vi hệ thống là quan trọng ở đây; đây là lý do tại sao các công cụ đơn giản như 'top' là một nơi thuận tiện để bắt đầu.

Tôi sẽ không đồng ý (phần nào) với @ greg_1_anderson tại đây.

Nếu hệ thống không bị sập hoàn toàn trong thời gian a cc all, thì tôi không nghĩ bạn có vấn đề về bộ nhớ chung. Khi một máy chủ LAMP hết bộ nhớ, nó sẽ chạm vào trao đổi. Một máy chủ hoạt động nhấn trao đổi sẽ gây ra tình trạng xấu. Các quy trình httpd sẽ bắt đầu chồng lên do sự cố hệ thống (trao đổi làm cho hệ thống chạy rất chậm), điều này sẽ khiến nhiều trao đổi được sử dụng, v.v. Trên các trang web mà tôi đã thấy điều này xảy ra, tôi sẽ thấy quá trình tải đạt 100, và một tấn các quá trình httpd hoạt động.

Nếu hệ thống của bạn cuối cùng trở lại, thì tôi nghĩ bạn đang điều chỉnh kém. drush cc allsẽ dẫn đến rất nhiều truy cập cơ sở dữ liệu, vì vậy tôi nghĩ rằng nó đang hiển thị vấn đề nhiều hơn. Đề nghị của tôi sẽ là chạy mysqltuner trên trang web. Nếu bạn có một cơ sở dữ liệu nhiều GB, tôi đoán là bạn innodb_buffer_pool_sizethậm chí không có kích thước từ xa đúng cách và ví dụ MySQL của bạn đang bị phá hủy. Tôi cũng sẽ điều tra một phụ trợ bộ đệm thay thế để cố gắng giữ cho dấu chân cơ sở dữ liệu nhỏ hơn.

Nó có thể là môi trường lưu trữ web của bạn. Bạn đang đề cập đến một thiết lập cục bộ, hoặc một cái gì đó lưu trữ trên lưu trữ được chia sẻ hoặc VPS / máy chủ?

• môi trường lưu trữ - nếu bạn đang sử dụng lưu trữ web được chia sẻ, dung lượng bộ nhớ Drupal / drush có thể sử dụng sẽ bị giới hạn, hãy xem: https://drupal.org/node/207036
• thời gian thực hiện tối đa - cần phải tăng lên

Đây không phải là một giải pháp hoàn chỉnh, chỉ là một công cụ nữa để giúp xác định nguồn gốc của sự chậm trễ của bạn.

Cũng như sử dụng topđể giám sát các quá trình, bạn có thể tìm thấy đầu ra của mytopthông tin. (Các câu trả lời khác ở trên giả định MySQL nhưng nếu bạn đang sử dụng một phụ trợ DB khác, bạn sẽ cần trao đổi mytop cho một công cụ tương đương.)

mytopchỉ cần thực thi MySQL SHOW FULL PROCESSLISTtrong một vòng lặp và cho bạn thấy các truy vấn nào đang được thực hiện (vì vậy sẽ mất rất nhiều thời gian). Nếu xóa bộ nhớ cache mất nhiều thời gian để dọn sạch bảng này hoặc bảng kia, bạn sẽ thấy chính xác những gì đang giữ mọi thứ ở đây. Nếu bạn không có quyền truy cập để cài đặt mytop, chỉ cần thực hiện một phiên bản thô trong vỏ của bạn -

while true; do mysql -e 'SHOW FULL PROCESSLIST' && sleep 5 && clear ; done

Nếu sự chậm trễ không xuất phát từ các truy vấn MySQL, thì công cụ này ít nhất có thể xác nhận điều đó cho bạn.

Tôi tìm thấy một bài đăng trên blog có tên Speed ​​Up Cache Clearing trên Drupal 7 rất hữu ích trong việc thu hẹp chính xác phần nào của quá trình xóa bộ nhớ cache đang làm mọi thứ chậm lại. Các vấn đề mà nó xác định chính xác trong mô-đun tính năng và mô-đun api thực thể đã ảnh hưởng đến trang web của tôi, nhưng quá trình chi tiết trong bài viết cũng giúp tôi theo dõi các vấn đề chúng tôi gặp phải trong mô-đun Drupal và điểm dừng .

Phải mất một chút thời gian để xử lý quá trình, nhưng nó đã giúp tôi giảm bớt việc xóa bộ nhớ cache từ nhiều phút xuống dưới một phút.