Có nên chạy 2 cron chuẩn không?

Câu hỏi của tôi được đưa ra, nên có nhiều magron cron: run -vvv process luôn luôn chạy và nhấn MySql liên tục.

Tôi đang thiết lập Magento 2.2.1 thông qua Google Cloud và tôi có 3 công việc định kỳ tiêu chuẩn được cài đặt sẵn thông qua cài đặt Magento 1 lần nhấp của Google.

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/update/cron.php 2>&1

*/1 * * * * /opt/bitnami/php/bin/php /opt/bitnami/apps/magento/htdocs/bin/magento setup:cron:run -vvv 2>&1

Nhìn vào top -c luôn có 2 tiến trình php.bin đang chạy, nó liên tục tấn công MySql và khiến nó sử dụng khoảng 50% - 70% CPU mọi lúc. Dưới đây là một ảnh chụp nhanh về những gì nó thường trông như thế nào.

 PID USER      PR  NI    VIRT    RES    SHR  S   %CPU   %MEM 
19327 mysql     20   0 3872884 332876  19172 S  60.8  3.4 332:42.45 /opt/bitnami/mysql/bin/mysqld.bin --defaults-file=/opt/bitnami/mysql/my.cnf --basedir=/opt/bitnami+
26458 bitnami   20   0  679516 476444  64492 S  24.6  4.9   0:24.85 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv
26415 bitnami   20   0  677532 475672  64588 R  23.6  4.9   1:36.11 /opt/bitnami/php/bin/php.bin /opt/bitnami/apps/magento/htdocs/bin/magento cron:run -vvv

Tôi cũng đã thay đổi các crons để chạy cứ sau 5 phút, thay vì mặc định mỗi phút nhưng hành vi vẫn giữ nguyên.

Thay đổi mới nhất của tôi là luân phiên cứ sau 7 phút và 8 phút với 2 cron: chạy các công việc bắt đầu cách nhau 3 và 4 phút, và với đó chỉ có 1 cron công việc đang chạy cùng lúc với 30% - 40% CPU từ MySQL.

Trang web của tôi cũng không có lưu lượng truy cập ngay bây giờ vì tôi chưa khởi chạy nó. Hành vi này có bình thường từ Magento không vì không có gì xảy ra với trang web? Tôi để nó ngồi trong 12 giờ mà không làm gì cả và khi tôi nhìn lên trên thì cron vẫn đang chạy và đập vào MySQL.

CẬP NHẬT: Bây giờ rõ ràng vấn đề chỉ là cron đầu tiên: quá trình chạy đang gây ra vấn đề. Tôi đã thay đổi các mục thứ 2 và thứ 3 trở lại sau mỗi phút và để lại mục đầu tiên sau 8 phút và chỉ có một cron chạy duy nhất: quy trình chạy tại một thời điểm. Từ nhận xét bên dưới, đây có thể là một vấn đề với cài đặt Bitnami Magento, nhưng đây là trải nghiệm đầu tiên của tôi với Magento vì vậy tôi không biết đây có phải là hành vi được mong đợi hay không (tôi thực sự hy vọng là không).

— người viết mã
nguồn

Tôi đang gặp vấn đề tương tự, với cài đặt Bitnami. Đến bây giờ, tôi không thể hiểu tại sao, nhưng khi tôi nhìn vào việc sử dụng CPU trong bảng điều khiển của GCE, tôi có thể thấy rằng nó đã bắt đầu với một vài phần trăm của CPU khoảng 30 ngày trước. Bây giờ, tôi đã tối đa hóa nó và đã thêm 4 x RAM và 4 x số vCPU để giữ cho máy chủ tồn tại. Thay vì hàng đầu, tôi đã sử dụng htop. Với nó tôi thấy rằng tôi đã có hơn mười dòng với magento cron:run -vvv. Một số đã được sống trong vài phút. Tôi sẽ cố gắng tìm hiểu tại sao cron không chạy như mong đợi.

— dùng5198077

Tôi nhận được hành vi tương tự khi tôi có cron đặt mặc định cứ sau 1 phút. Tôi đã thay đổi nó để chạy cứ sau 7 và 8 phút như tôi đã mô tả trong câu hỏi của mình và nó chỉ sinh ra 1 quá trình, nhưng có vẻ như nó vẫn hoạt động quá nhiều. Âm thanh như có thể là một vấn đề magento bitnami có thể.

— Codemaller

Có, thay đổi cứ sau 7 phút làm cho máy chủ của tôi hài lòng. Đã sử dụng từ 300% + mức sử dụng cpu và 8 GB RAM xuống còn 40% (đối với một trong những trả phí của MySQL) và 1,7 GB RAM. Sẽ điều tra làm thế nào tôi có thể bật đăng nhập đầy đủ của Cron.

— dùng5198077

Ngoài ra -vvv là ghi nhật ký chi tiết tối đa để arg có thể được gỡ bỏ khỏi crontab.

— Codemaller

Tôi đã xem xét biểu đồ hoạt động của đĩa (I / O). Khi máy chủ có vẻ "hoạt động", các thao tác đọc gần bằng 0, trong khi ghi khá cao. Điều gì xảy ra khi máy chủ ngừng hoạt động (hoặc dừng đáp ứng) là các hoạt động đọc vượt qua ghi. So sánh bản cài đặt Magento Bitnami 2.2.0 không lành mạnh của tôi với một BItnami khác (tôi nghĩ vẫn còn trên 2.1.6 hoặc 2.1.8), việc đọc / ghi ở mức rất thấp, dưới 2, trong khi đối với mức không quá khỏe mạnh (nhưng hiện đang làm việc) các lần đọc dưới 2 nhưng viết thường vượt quá 1000! : O

— user5198077

Cung cấp ít nhất một công việc tạm thời xung quanh vấn đề này, để tránh làm hỏng máy chủ MySQL của bạn. Vấn đề Git mô tả vấn đề

Ít nhất một phần của vấn đề đi xuống bảng cron_schedule. Tôi khuyên bạn nên làm một select count(*) from cron_schedule;và nếu điều đó trả về hơn vài trăm, thì bạn có vấn đề. Đối với tôi, truy vấn đó đã trả về 208.046 trên một máy chủ chỉ chạy được vài tuần.

Nếu bạn gặp sự cố thì hãy chạy truy vấn này để xóa mọi thứ trong bảng đó, ngoại trừ các hàng gần đây delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Sau đó chạy lại truy vấn đếm và nó sẽ thấp hơn waaaay. Của tôi đã đi từ 208k đến 252.

Sau khi chạy truy vấn đó, tôi đặt cả 3 crons tiêu chuẩn trở lại tiêu chuẩn một lần mỗi phút và giống như phép thuật, cả 3 đều chạy gần như ngay lập tức. Trở lại bình thường như xa như tôi có thể nói.

Trong vấn đề github, một người dùng khác đề nghị thêm truy vấn đó vào crontab để ngăn bảng phát triển lại.

0 * * * * <path_to_mysql_bin_dir>/mysql <magento_db_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)"

Phản hồi cuối cùng từ nhóm Magento về vấn đề này là vào tháng 9 nói rằng họ không thể tái tạo vấn đề, nhưng một số người dùng đã theo dõi nói rằng họ gặp phải điều tương tự, bao gồm cả bản thân tôi. Vì vậy, hy vọng họ khắc phục điều này để hack này có thể được gỡ bỏ.

EDIT: Để sử dụng lệnh đó trên crontab, bạn cần chuyển thông tin đăng nhập của mình cho MySQL theo một cách nào đó. Xem bình luận của tôi dưới đây nếu bạn đang sử dụng máy ảo hoặc máy chủ chuyên dụng và muốn đưa người dùng / vượt qua của mình lên crontab, nếu không, bạn sẽ cần phải thiết lập tệp thông tin đăng nhập MySQL. Và bạn có thể sử dụng which mysqlđể tìm đường dẫn đến thư mục nhị phân mysql của bạn.

— người viết mã
nguồn

Câu trả lời của bạn đã làm việc cho tôi, nhưng thêm vào crontab, với mysql magento-db -e "query", trong đó magento-db là tên cơ sở dữ liệu (trong trường hợp của tôi, đó là bitnami_magento), nó cũng hoạt động khi có mật khẩu cho cơ sở dữ liệu? Tôi thường nhập cơ sở dữ liệu như thế mysql -u somename -pvà sau đó nhập mật khẩu nhanh chóng.

— dùng5198077

Sử dụng công cụ tìm kiếm ưa thích của bạn sẽ dễ dàng tìm thấy một vài giải pháp cho điều đó; Tôi đã bỏ phần đó cho thông tin người dùng / thông qua nhưng tôi sẽ đăng nó, sau khi tôi từ chối trách nhiệm: Đừng làm điều này trên dịch vụ lưu trữ được chia sẻ bởi vì những thứ khác sẽ hiển thị với những người khác với top -c, trong số những thứ khác. Trong trường hợp đó, hãy tìm cách sử dụng tệp thông tin đăng nhập MySQL, .mycnf hoặc đại loại như thế. Đây là những gì tôi có

*/15 * * * * <path_to_mysql_binary_dir>/mysql -u<sql_user> -p'<sql_user_pass>' <database_name> -e "delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour)";

— Codemaller