Haruskah 2 dari cron standar selalu berjalan?

Pertanyaan saya turun ke, haruskah beberapa magento cron: menjalankan proses -vvv selalu berjalan dan memukul MySql terus-menerus.

Saya sedang menyiapkan Magento 2.2.1 melalui Google Cloud dan saya memiliki 3 pekerjaan cron standar yang telah dipra-setup melalui pemasangan Magento 1 kali klik 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

Melihat -c atas selalu ada 2 proses php.bin berjalan, yang memukul MySql terus-menerus dan menyebabkannya menggunakan sekitar 50% - 70% CPU sepanjang waktu. Ini adalah snapshot dari apa yang biasanya terlihat.

 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

Saya juga mengubah crons untuk berjalan setiap 5 menit, bukannya default setiap menit tetapi perilaku tetap sama.

Perubahan terbaru saya berganti setiap 7 menit dan 8 menit dengan 2 cron: jalankan pekerjaan mulai terpisah 3 dan 4 menit, dan dengan itu hanya 1 pekerjaan cron yang berjalan pada satu waktu dengan 30% - 40% CPU dari MySQL.

Situs saya juga tidak memiliki traffic saat ini karena saya belum meluncurkannya. Apakah perilaku ini normal dari Magento karena tidak ada yang terjadi dengan situs ini? Saya membiarkannya selama 12 jam tanpa melakukan apa-apa dan ketika saya melihat di atas cron masih berjalan dan memalu MySQL.

UPDATE: Sekarang jelas masalahnya hanya cron pertama: jalankan proses yang menyebabkan masalah. Saya mengubah item ke-2 dan ke-3 kembali ke setiap menit dan meninggalkan yang pertama pada 8 menit dan hanya ada satu cron yang berjalan: jalankan proses pada suatu waktu. Dari komentar di bawah ini bisa menjadi masalah dengan instalasi Bitnami Magento, tapi ini adalah pengalaman pertama saya dengan Magento jadi saya tidak tahu apakah ini perilaku yang diharapkan (saya benar-benar berharap tidak).

— pembuat kode
sumber

Saya mengalami masalah serupa, dengan instalasi Bitnami. Sampai sekarang, saya tidak dapat mencari tahu mengapa, tetapi ketika saya melihat pemanfaatan CPU di dashboard GCE, saya dapat melihat bahwa itu dimulai pada beberapa persentase CPU sekitar hampir 30 hari yang lalu. Sekarang, saya memaksimalkannya dan telah menambahkan 4 x RAM dan 4 x jumlah vCPU untuk menjaga server tetap hidup. Alih-alih atas, saya menggunakan htop. Dengan itu saya melihat bahwa saya punya lebih dari sepuluh jalur dengan magento cron:run -vvv. Beberapa telah diputar selama beberapa menit. Saya akan mencoba mencari tahu mengapa cron tidak berjalan seperti yang diharapkan.

— user5198077

Saya mendapatkan perilaku yang sama ketika saya mengatur cron default setiap 1 menit. Saya mengubahnya untuk berjalan setiap 7 dan 8 menit seperti yang saya jelaskan dalam pertanyaan saya dan hanya memunculkan 1 proses, tetapi sepertinya masih terlalu banyak. Mungkin terdengar seperti masalah bitnami magento.

— codesmaller

Ya, berganti setiap 7 menit membuat server saya senang. Pergi dari pemanfaatan 300% + cpu dan 8 GB RAM hingga 40% (untuk satu pembayaran MySQL) dan 1,7 GB RAM. Akan menyelidiki bagaimana saya dapat mengaktifkan logging Cron penuh.

— user5198077

Juga -vvv adalah logging verbose maksimum sehingga arg dapat dihapus dari crontab.

— codesmaller

Saya telah melihat pada grafik Operasi Disk (I / O). Ketika server tampaknya "bekerja", operasi baca mendekati nol, sedangkan penulisan cukup tinggi. Apa yang terjadi ketika server turun (atau berhenti merespons) adalah bahwa operasi baca melewati penulisan. Membandingkan instalasi Magento Bitnami 2.2.0 saya yang tidak sehat dengan BItnami lain (saya pikir masih pada 2.1.6 atau 2.1.8), baca / tulis berada pada level yang sangat rendah, kurang dari 2, sedangkan untuk yang tidak begitu sehat (tetapi sekarang bekerja) bacaan di bawah 2 tetapi menulis sering melampaui 1000! : O

— user5198077

Memberikan setidaknya penyelesaian sementara untuk masalah ini, untuk menghindari memalu server MySQL Anda. Masalah Git yang menjelaskan masalah tersebut

Setidaknya sebagian dari masalah sampai ke tabel cron_schedule. Saya akan merekomendasikan melakukan select count(*) from cron_schedule;dan jika itu mengembalikan lebih dari beberapa ratus, maka Anda memiliki masalah. Bagi saya, permintaan itu mengembalikan 208.046 pada server yang telah berjalan hanya beberapa minggu.

Jika Anda memiliki masalah, jalankan kueri ini untuk menghapus semua yang ada di tabel itu, kecuali baris terbaru delete from cron_schedule where scheduled_at < date_sub(now(), interval 1 hour);

Kemudian jalankan kueri hitung lagi dan harus lebih rendah lagi. Milik saya berubah dari 208k menjadi 252.

Setelah menjalankan kueri itu, saya mengatur semua 3 crons standar kembali ke standar sekali per menit, dan seperti sulap mereka semua 3 berjalan hampir secara instan. Kembali normal sejauh yang saya tahu.

Dalam masalah github, pengguna lain menyarankan menambahkan kueri itu ke crontab untuk mencegah tabel tumbuh lagi.

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

Tanggapan terakhir dari tim Magento tentang masalah ini adalah pada bulan September mengatakan bahwa mereka tidak dapat mereproduksi masalah, tetapi sejumlah pengguna telah menindaklanjuti dengan mengatakan mereka mengalami hal yang sama, termasuk saya. Jadi semoga mereka memperbaikinya sehingga peretasan ini bisa dihapus.

EDIT: Untuk menggunakan perintah itu pada crontab Anda harus memberikan kredensial Anda ke MySQL dengan beberapa cara. Lihat komentar saya di bawah ini jika Anda menggunakan VM atau server khusus dan ingin menempatkan pengguna / umpan Anda pada crontab, jika tidak, Anda harus menyiapkan file kredensial MySQL. Dan Anda dapat menggunakan which mysqluntuk menemukan path ke direktori biner mysql Anda.

— pembuat kode
sumber

Jawaban Anda berhasil untuk saya, tetapi menambahkan di crontab, dengan mysql magento-db -e "query", di mana magento-db adalah nama basis data (dalam kasus saya, ini adalah bitnami_magento), apakah itu juga berfungsi ketika ada kata sandi untuk basis data? Saya biasanya memasukkan database seperti mysql -u somename -pdan kemudian memasukkan kata sandi di prompt.

— user5198077

Menggunakan mesin pencari pilihan Anda, akan mudah untuk menemukan solusi pasangan untuk itu; Saya meninggalkan bagian itu untuk info pengguna / pass tetapi saya akan mempostingnya, setelah saya memberikan penafian: Jangan lakukan ini di shared hosting karena itu akan terlihat oleh orang lain dengan top -c, antara lain. Dalam hal ini cari cara menggunakan file kredensial MySQL, .mycnf atau sesuatu seperti itu. Inilah yang saya miliki

*/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)";

— codesmaller