Perintah `drush cc all` membutuhkan waktu terlalu lama, apa yang bisa saya lakukan?

Di situs saya drush cc allmembutuhkan waktu lebih dari 4 menit untuk menjalankan. Situs db adalah beberapa GB. Namun, saya tidak dapat melihat alasan yang jelas mengapa ini memakan waktu terlalu lama. Apa yang bisa saya lakukan untuk menemukan leher botol?

Menghapus cache itu sendiri tidak memakan waktu lama, karena itu hanya memotong tabel cache. Apa yang paling memakan waktu adalah membangun kembali registri cache setelah itu. Biasanya ini adalah registry tema yang memindai semua kait baru dan semua folder Drupal Anda untuk file template baru, sistem yang memindai file untuk modul baru dan file kelas, dan yang serupa.

Anda selalu dapat menghapus cache spesifik dengan menentukan drush cc theme-registryatau lainnya.

Sangat disarankan agar Anda menggunakan mekanisme caching PHP (mis. OPCache, XCache, dll.) Untuk mempercepat pemrosesan. Dan cache berbasis memori untuk menggantikan penggunaan yang berat pada tabel SQL (misalnya memcached atau redis), jadi membersihkan cache tidak akan memakan waktu, hanya dengan membersihkan cache (misalnya echo flush_all > /dev/tcp/127.0.0.1/11211dalam Bash).

Atau Anda selalu dapat menghapus cache secara manual , misalnya dengan:

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

Debugging

Untuk memeriksa apa yang paling memakan waktu khusus, Anda perlu men - debug / profil itu (misalnya XDebug, XHProf, phpdbg, dtrace).

Pada OS X / Unix, ini dapat dicapai dengan dtrace(setelah menjalankan 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); }'

Di Linux, gunakan strace, mis

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

Untuk mencari beberapa hal tertentu, coba tambahkan misalnya: strace ... 2>&1 | grep -C5 UPDATE.

Jika Anda memiliki basis data yang sangat besar, dan sistem Anda berjalan dengan baik ketika Anda tidak melakukan cache yang jelas, kemungkinan Anda tidak memiliki cukup memori untuk sepenuhnya mendukung pengaturan Anda.

Jika situs Anda berjalan pada kotak Linux, jalankan 'top' (dari shell Anda) dan tekan shift-M untuk mengurutkan daftar proses berdasarkan memori yang digunakan. Kemudian, jalankan operasi penghapus cache dari terminal lain. Anda akan melihat mysql dan apache naik ke bagian atas daftar. Anda akan dapat melihat berapa persentase total memori yang digunakan oleh masing-masing proses ini, dan berapa banyak RAM gratis yang digunakan. Jika Anda memiliki ruang virtual dalam jumlah besar, tetapi semua RAM fisik Anda telah habis, operasi ini dapat menyebabkan kehabisan memori VM, yang dapat menurunkan waktu eksekusi hingga sebagian kecil dari biasanya.

Suatu kali, saya menjalankan situs Drupal mid-traffic pada kotak tanpa memori yang cukup untuk mendukung pengaturan. Ketika saya menjalankan cache-clear pada situs lalu lintas rendah yang tidak terkait, cache membangun kembali mendorong sistem melewati batasnya, dan semuanya terkunci. Jadi, perilaku sistem total penting di sini; inilah mengapa alat sederhana seperti 'top' adalah tempat yang praktis untuk memulai.

Saya akan tidak setuju (agak) dengan @ greg_1_anderson di sini.

Jika sistem tidak mogok sepenuhnya selama cc all, maka saya tidak berpikir Anda memiliki masalah memori umum. Ketika server LAMP kehabisan memori, itu akan menekan swap. Server aktif yang memukul swap akan menyebabkan longsoran kejahatan. Proses httpd akan mulai menumpuk karena perlambatan sistem (swap membuat sistem berjalan sangat lambat), yang akan menyebabkan lebih banyak swap digunakan, dll. Di situs tempat saya melihat ini terjadi, saya akan melihat proses pemuatan mencapai 100, dan satu ton proses httpd aktif.

Jika sistem Anda pada akhirnya kembali, maka saya pikir Anda kurang baik. drush cc allakan menghasilkan banyak akses basis data, jadi saya pikir ini menunjukkan lebih banyak masalah. Saran saya adalah menjalankan mysqltuner di situs. Jika Anda memiliki basis data multi-GB, tebakan saya adalah ukuran Anda innodb_buffer_pool_sizebahkan dari jarak jauh tidak memadai, dan instance MySQL Anda meronta-ronta. Saya juga akan menyelidiki backend cache alternatif untuk mencoba menjaga agar jejak basis data lebih kecil.

Bisa jadi lingkungan hosting web Anda. Apakah Anda mengacu pada pengaturan lokal, atau sesuatu hosting di shared hosting atau VPS / server?

• lingkungan hosting - jika Anda menggunakan hosting web bersama, jumlah memori yang dapat digunakan Drupal / drush akan terbatas, lihat: https://drupal.org/node/207036
• waktu eksekusi maks - perlu ditingkatkan

Ini bukan solusi lengkap, hanya satu alat lagi untuk membantu mengidentifikasi sumber keterlambatan Anda.

Selain menggunakan topuntuk memantau proses, Anda mungkin menemukan hasil mytopinformatif. (Jawaban lain di atas menganggap MySQL tetapi jika Anda menggunakan DB backend lain, Anda harus menukar mytop dengan alat yang setara.)

mytopcukup jalankan MySQL SHOW FULL PROCESSLISTdalam satu lingkaran, dan menunjukkan kepada Anda pertanyaan mana yang sedang dieksekusi (sehingga membutuhkan banyak waktu). Jika cache bersih membutuhkan waktu lama untuk membersihkan tabel ini atau itu, Anda akan melihat apa yang menahan semuanya di sini. Jika Anda tidak memiliki akses untuk menginstal mytop, lakukan saja versi kasar di shell Anda -

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

Jika penundaan itu tidak berasal dari permintaan MySQL, maka alat ini setidaknya dapat mengkonfirmasi untuk Anda.

Saya menemukan posting blog berjudul Mempercepat Cache Kliring pada Drupal 7 sangat membantu dalam mempersempit bagian proses cache yang jelas memperlambat segalanya. Masalah yang ditunjukkan dalam modul fitur dan modul entitas api memengaruhi situs saya, tetapi proses yang dirinci dalam pos juga membantu saya melacak masalah yang kami temui dalam modul inti dan breakup Drupal .

Butuh beberapa waktu untuk menyelesaikan prosesnya, tetapi ini membantu saya mengurangi cache dari beberapa menit menjadi kurang dari satu menit.