2009-11-24 13 views
9

Web uygulamanız için üç memcache sunucusu kurduk.Memcache bağlantılarının sayısı asla düşmez, büyümeye devam ediyor

İki kişi, her biri 12'den fazla bağlantıyı korurken, on binlerce okuma ve yazma işlemi gerçekleştiriyor (memcache-top'a göre).

Yönetimsel istemci oturumu verilerini (PHPs built in memcache session handler kullanarak) ve bazı rasgele uygulama verilerini depolamaktan sorumlu üçüncü bir memcache sunucumuz var. Bazı sebeplerden dolayı bu kutudaki bağlantı sayısı asla azalmaz, sadece zamanla artar. Örneğin, son zamanlarda sunucuyu yeniden başlattık ve bir saat sonra memcache-top kayıtları ~ 300 bağlantı.

Kod tabanı, kalıcı bağlantılar ve dinamik bağlantılar karışımı kullanır, ancak bağlantıların asla ölmediği durumu yeniden oluşturmak için basit bir örnek oluşturamadım.

memcache-top v0.6 (default port: 11211, color: on, refresh: 3 seconds) 

INSTANCE   USAGE HIT % CONN TIME EVICT/s READ/s WRITE/s 
memcache1:11211 15.7% 83.5% 10 1.2ms  0.0 24.9K 34.5K 
memcache2:11211 15.8% 81.3% 10 1.0ms  0.0 19.1K 31.6K 
memcache3:11211 0.1% 0.0% 354 1.1ms  0.0  4  321 

AVERAGE: 10.5% 55.0% 124 1.1ms 0.0 14.7K 22.1K 

TOTAL: 0.6GB/ 6.0GB 374 3.2ms 0.0 44.0K 66.4K 

Benim soru yani: Bu neden memcache örneğin bağlantıları asla ölmez yok sen memcache-top görebileceğiniz gibi bu üçüncü Memcache'ı sunucu aslında web uygulamasının en az aktif bölümünü barındırıyor?

+1

Q1. Bu "sorunlu" 3 sunucu bir BSD olurken, bu 2 "iyi" sunucu - Linux mu? S2. Tüm 3 memcach için CPU kullanımı% nedir? – chronos

cevap

4

PHP'deki kalıcı bağlantılar, her apache çalışan işlemi için bir bağlantı ayırır. Apache kurulumu ~ 354 işçi işlemine izin veriyor mu?

1

session.gc_probability ve session.gc_divisor ayarınız nedir? Bazı Linux dağıtımları bu değerlerin üzerine yazılır ve oturumları silmek için bir cronjob eklenir. Sorununuz bu davranıştan kaynaklanabilir.

2

PHP5 kullanıyor musunuz? Büyük olasılıkla evet. İşte PHP session_set_save_handler documentation dan muhtemel bir tuzak var: PHP

yazma 5.0.5 ve yakın işleyicileri nesneleri istisnalar kullanılamaz atamaz bu nedenle nesne yıkımından sonra aradı ve edilmektedir. nesne yıkıcıları, oturumlarını kullanabilirler.

tavuk ve yumurta sorununu çözmek için yıkıcıdan() session_write_close çağırmak mümkündür.

Bu değişiklikten önce memcache oturum işleyicisi yeniden ziyaret edilmediğinden ne kadar bahse girersiniz? Bir çözüm ya da en azından tanılama olarak, kendi memcached oturumunuzu açık/kapalı/okuma/yazma ve işlevleri yok etmenizi (nesne değil) yazmanızı, bunları session_set_save_handler ile bağlamanızı ve yerleşik olanı kullanarak atlamanızı tavsiye ederim. En azından, o zaman internals giriş yapabileceksiniz.

+0

Özel oturum işleyicinizi günlüğe kaydetmek/hata ayıklamak için bir yan not olarak - Içeriğe temizlendikten sonra write() yöntemi gerçekleştiğinde ** file_put_contents() ** satırlarında bir şey kullanmanız gerekir. –

İlgili konular