Ubuntu'nun PHP oturumları için çöp toplama cron işinin çalışması 25 dakika sürüyor, neden?

Ubuntu, eski PHP oturumlarını arayan ve silen bir cron işi ayarladı:

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] \
   && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir \
   fuser -s {} 2> /dev/null \; -delete

Benim sorunum, bu işlemin çok sayıda disk GÇ ile çalışması çok uzun sürüyor. İşte CPU kullanım grafiğim:

Temizleme çalışması deniz mavisi sivri uçlarıyla temsil edilir. Dönemin başında, PHP'nin temizleme işleri varsayılan 09 ve 39 dakika zamanlanmıştı. Saat 15:00 'da 39 dakikalık süreyi cron'dan kaldırdım, bu yüzden iki kat büyüklüğünde bir temizlik işi sık sık yarı işliyor (piklerin iki katı genişliğinde ve yarı sık sık olduğunu görebilirsiniz).

İşte IO zamanı için karşılık gelen grafikler:

Ve disk işlemleri:

Yaklaşık 14.000 oturumun aktif olduğu zirvede, temizlemenin tam olarak 25 dakika sürdüğü, görünüşe göre CPU'nun bir çekirdeğinin% 100'ünü ve tüm dönem boyunca disk IO'sunun% 100'ü gibi göründüğü görülebilir. Neden bu kadar kaynak yoğun? Bir lsseans dizinin /var/lib/php5saniyenin sadece bir kısmını alır. Öyleyse eski oturumları kesmek neden tam 25 dakika sürüyor? Bunu hızlandırmak için yapabileceğim bir şey var mı?

Bu aygıtın dosya sistemi şu anda ext4'tür ve Ubuntu Precise 12.04 64-bit üzerinde çalışmaktadır.

DÜZENLEME: Yükün olağandışı "kaynaştırıcı" işleminden kaynaklandığından şüpheleniyorum rm. Kaynaştırıcı kullanımını kaldıracağım ve ne olacağını göreceğim.

Kaldırılması fuseryardımcı olacaktır. Bu iş, bulunan fuserher oturum dosyası için 14k oturum içeren yoğun bir sistemde kolayca birkaç dakika sürebilecek bir komut çalıştırır (bir dosyanın şu anda açık olup olmadığını kontrol eder) . Bu bir Debian hatasıydı (Ubuntu Debian'a dayanmaktadır).

Memcached yerine oturum dosyaları için tmpfs (bellekteki bir dosya sistemi) kullanmayı deneyebilirsiniz. Memcached gibi bu yeniden başlatma oturumlarını geçersiz kılar (bu, bu dizini kapatma komut dosyasında bir yere yedekleyerek ve başlangıç ​​komut dosyasında geri yükleyerek çözülebilir), ancak kurulumu çok daha kolay olacaktır. Ama fusersorunla yardımcı olmaz .

Popüler bir web sitesine sahip olduğunuzu ve bu süre boyunca sanal bir makinede çalışmaya devam etmeyi yönettiğiniz için tebrikler.

Gerçekten günde iki milyon sayfa çekerek ediyorsanız, o zaman dosya sisteminde PHP oturumları bir LOT biriktirecek gidiyoruz ve hiçbir kullanmak ister konuyu silmek için uzun zaman almaya gidiyoruz fuserya rmveya elektrikli süpürge.

Bu noktada, oturumlarınızı depolamak için alternatif yollara bakmanızı tavsiye ederim:

• Seçeneklerden biri oturumları depolamaktırmemcached . Bu hızlı bir şekilde yanıp sönüyor, ancak sunucu çökerse veya yeniden başlatılırsa, tüm oturumlarınız kaybolur ve herkes oturumu kapatılır.
• Ayrıca oturumları bir veritabanında saklayabilirsiniz. Bu, memcached'den biraz daha yavaş olurdu, ancak veritabanı kalıcı olacaktır ve basit bir SQL sorgusu ile eski oturumları temizleyebilirsiniz. Ancak bunu uygulamak için özel bir oturum işleyicisi yazmanız gerekir .

Dolayısıyla, burada kullanıcılar tarafından önerilen Memcached ve veritabanı oturumu depolama seçenekleri, her biri kendi avantajları ve dezavantajları olan performansı artırmak için iyi seçimlerdir.

Ancak performans testi ile, bu oturum bakımının büyük performans maliyetinin neredeyse tamamen fusercron işindeki çağrıya bağlı olduğunu buldum . Eski oturumları kesmek rmyerine kullanılan Natty / Oneiric cron işine döndükten sonra performans grafikleri fuser, geçiş 2: 30'da gerçekleşir.

Ubuntu'nun PHP oturum temizliğinin neden olduğu periyodik performans düşüşünün neredeyse tamamen kaldırıldığını görebilirsiniz. Disk İşlemleri grafiğinde gösterilen sivri uçlar artık daha büyük boyuttadır ve bu grafiğin ölçebileceği kadar zayıftır ve önceki sunucu performansının 25 dakika boyunca önemli ölçüde düştüğü küçük, kısa bir kesintiyi gösterir. Ekstra CPU kullanımı tamamen ortadan kaldırılmıştır, bu artık IO'ya bağlı bir iştir.

(ilgisiz bir IO işi 05: 00'da ve CPU işi 7: 40'ta çalışır ve bu ikisi de bu grafiklerde kendi artışlarına neden olur)

Şu anda çalıştırdığım değiştirilmiş cron işi:

09 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && \
   [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 \
   -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 \
   | xargs -n 200 -r -0 rm

Oturumlar hakkında biraz araştırma yaparken bu yazıyla karşılaştım. Kabul edilen cevap çok iyi olsa da (ve füzer çağrısı bir süredir gc betiğinden kaldırılmışsa), başka birisinin benzer bir sorunla karşılaşması durumunda birkaç noktayı dikkate almaya değer olduğunu düşünüyorum.

Açıklanan senaryoda, OP ext4 kullanıyordu. Ext4'teki dizinler, bir htree veritabanı biçiminde dosya verilerini depolar - bu, birden fazla dosyayı tek bir dizinde birden çok dizinde dağıtmakla karşılaştırıldığında ihmal edilebilir bir etki olduğu anlamına gelir. Bu tüm dosya sistemleri için geçerli değildir. PHP'deki varsayılan işleyici, oturum dosyaları için birden çok alt dizin kullanmanıza izin verir (ancak denetim işleminin bu dizinlere yinelenip yinelenmediğini kontrol etmeniz gerektiğini unutmayın - yukarıdaki cron işi bunu yapmaz).

İşlemin maliyetinin büyük bir kısmı (kaynaştırıcıya çağrıyı kaldırdıktan sonra) henüz eski olmayan dosyalara bakmaktan kaynaklanır. (Örneğin) tek bir alt dizin seviyesi ve her bir alt dizinde (0 /, 1 /, ... d /, e /, f /) görünen 16 cron işinin kullanılması, ortaya çıkan yük darbelerini düzeltir.

Daha hızlı bir alt tabakaya sahip özel bir oturum işleyicisi kullanmak yardımcı olacaktır - ancak seçtiğiniz internette yayınlananların kalite aralığını bir kenara bırakarak (memcache, redis, mysql işleyici soketi ...) seçim yapabileceğiniz çok şey var. uygulamanız, altyapınız ve becerilerinizle ilgili gereksinimler, semantiklerin işlenmesinde (özellikle kilitleme) varsayılan işleyiciye kıyasla sık sık farklılıklar olduğunu unutmamak gerekir.

Bu tür bir trafik ile bir dis üzerinde oturumlar olmamalıdır. Memcache gibi bir şey kullanıyor olmalısınız. Yapmanız gereken tek şey kurulum php ve hiçbir kod değişikliği gerekli olacak. Örneğin bakınız

http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

Bu kadar uzun sürmesinin nedeni, hangilerinin silinebileceğini görmek için sıralaması gereken devasa dosya sayısından kaynaklanıyor. Memcache, kodunuzda ayarladığınız oturum uzunluğunuz göz önüne alındığında bunların süresini otomatik olarak doldurabilir.