`drush cc all` komutu çok uzun sürüyor, ne yapabilirim?

Benim bir sitede drush cc allçalıştırmak için 4 dakikadan fazla sürer. Db sitesi birkaç GB'dir. Ancak neden bu kadar uzun sürdüğüne dair net bir neden göremiyorum. Şişe boynunu bulmak için ne yapabilirim?

Kendini temizleme önbelleği uzun zaman almaz çünkü önbellek tablolarını kısaltır. En çok zaman alan önbellek kayıt defterini yeniden oluşturmaktır. Genellikle tüm yeni kancaları ve tüm Drupal klasörlerinizi yeni şablon dosyaları için tarayan tema kayıt defteri, yeni modüller ve sınıf dosyaları için dosyaları tarayan sistem vb.

Belirli bir önbelleği belirterek drush cc theme-registryveya başka birini kullanarak her zaman temizleyebilirsiniz .

İşlemeyi hızlandırmak için PHP önbellek mekanizmasını (örn. OPCache, XCache, vb.) Kullanmanız önemle tavsiye edilir. Ve SQL tablolarındaki (örneğin, memcached veya redis) yoğun kullanım yerine bellek tabanlı önbellek, bu nedenle önbelleği temizlemek, yalnızca önbelleği temizleyerek (örneğin echo flush_all > /dev/tcp/127.0.0.1/11211Bash) zaman almaz .

Alternatif olarak önbelleği her zaman manuel olarak silebilirsiniz , örneğin:

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

Hata ayıklama

Özellikle en çok neyin sürdüğünü kontrol etmek için hata ayıklama / profil oluşturma (örn. XDebug, XHProf, phpdbg, dtrace).

OS X / Unix'te, bu dtrace(çalıştırdıktan sonra drush) ile elde edilebilir :

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); }'

Linux'ta strace, örn.

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

Bazı özel şeyler aramak için, örneğin eklemeyi deneyin: strace ... 2>&1 | grep -C5 UPDATE.

Gerçekten büyük bir veritabanınız varsa ve temiz bir önbellek yapmadığınızda sisteminiz iyi çalışıyorsa, kurulumunuzu tam olarak desteklemek için yeterli belleğiniz olmayabilir.

Siteniz bir Linux kutusunda çalışıyorsa, 'top' komutunu çalıştırın (kabuğunuzdan) ve işlem listesini kullanılan belleğe göre sıralamak için shift-M tuşlarına basın. Ardından, önbellek temizleme işleminizi başka bir terminalden çalıştırın. Mysql ve apache'nin listenin başına yükseldiğini görmelisiniz. Bu işlemlerin her birinin toplam belleğin yüzde kaçını kullandığını ve ne kadar boş RAM kullanıldığını görebilirsiniz. Çok fazla sanal alanınız varsa, ancak tüm fiziksel RAM'iniz tükenmişse, bu işlem VM belleğinin çökmesine neden olabilir ve bu da yürütme sürenizi normalde olduğundan çok daha düşük bir süreye indirebilir.

Bir keresinde, kurulumu desteklemek için yeterli belleğe sahip olmayan bir kutuda orta trafikte bir Drupal sitesi çalıştırıyordum. İlişkisiz bir düşük trafikli sitede önbelleği temizlediğimde, önbellek yeniden oluşturma sistemi sınırını aştı ve hepsi kilitli. Dolayısıyla, toplam sistem davranışı burada önemlidir; bu yüzden 'top' gibi basit araçlar başlamak için kullanışlı bir yerdir.

Burada @ greg_1_anderson ile (biraz) katılmıyorum.

Sistem a sırasında tamamen çökmüyorsa cc all, genel bir bellek sorununuz olduğunu düşünmüyorum. Bir LAMP sunucusunun belleği dolduğunda, takas olur. Değiştirmeye isabet eden etkin bir sunucu, kötü durumlara neden olur. httpd süreçleri sistem yavaşlaması nedeniyle yığılmaya başlayacaktır (takas bir sistemin çok yavaş çalışmasına neden olur), bu da daha fazla takasın kullanılmasına neden olacaktır, vb. ve bir ton aktif httpd işlemi.

Sisteminiz sonunda geri gelirse, kötü ayarlandığınızı düşünüyorum. drush cc allveritabanı erişim bir sürü sonuçlanacak, bu yüzden sorunu daha fazla gösteriyor düşünüyorum. Benim önerim sitede mysqltuner çalıştırmak olacaktır . Çok GB'lı bir veritabanınız varsa, tahminim , innodb_buffer_pool_sizeuzaktan düzgün bir şekilde boyutlandırılmamış olması ve MySQL örneğinizin daralmasıdır. Ayrıca veritabanı ayak izini daha küçük tutmak için alternatif bir önbellek arka ucunu araştırmak istiyorum.

Web barındırma ortamı olabilir. Yerel bir kuruluma mı yoksa paylaşılan barındırmada veya bir VPS / sunucuda barındırılan bir şeye mi başvuruyorsunuz?

• barındırma ortamı - paylaşılan web barındırma kullanıyorsanız, Drupal / drush'ın kullanabileceği bellek miktarı sınırlı olacaktır: https://drupal.org/node/207036
• maksimum yürütme süresi - artırılması gerekiyor

Bu tam bir çözüm değil, gecikmelerinizin kaynağını belirlemeye yardımcı olacak sadece bir araç daha.

topİşlemleri izlemek için kullanmanın yanı sıra , mytopbilgilendirici çıktı da bulabilirsiniz . (Yukarıdaki diğer yanıtlar MySQL olduğunu varsayar, ancak başka bir DB arka ucu kullanıyorsanız, eşdeğer bir araç için mytop'u değiştirmeniz gerekir.)

mytopMySQL'i SHOW FULL PROCESSLISTbir döngüde yürütür ve hangi sorguların yürütüldüğünü gösterir (bu da çok zaman alır). Önbellek temizliği bu tabloyu veya bu tabloyu temizlemek uzun zaman alıyorsa, burada ne olduğunu tam olarak göreceksiniz. Yükleme erişiminiz mytopyoksa, kabuğunuzda ham bir sürüm yapın -

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

Gecikme MySQL sorgularından kaynaklanmıyorsa, bu araç en azından sizin için doğrulayabilir.

Önbellek temizleme işleminin hangi kısmının işleri yavaşlattığını tam olarak daraltmak için Drupal 7'de Önbellek Temizlemeyi Hızlandırma başlıklı bir blog yazısı buldum . Sorunlar o saptar özellikleri modülü ve varlık API modülü sitemde etkileyen, ancak post ayrıntılı süreci de beni biz karşılaşmadan edildi sorunları izini yardımcı Drupal çekirdek ve kırılma noktaları modülü .

Süreç üzerinde çalışmak biraz zaman alıyor, ancak önbellek temizleme sayısını birkaç dakikadan bir dakika altına indirmeme yardımcı oldu.