Squid'in gerçek dosya tanımlayıcı sınırını bulmak
PAM ayarlarını değiştirmeden veya bir kapasite tarifindeki sabit nofile değerini kopyalamadan önce çalışan proxy'nin süreç sınırlarını okuyun.
Oturum açma kabuğunun ulimit -n değerine güvenmeden önce çalışan arka plan programını inceleyin. squid.service kullanan bir kurulum için şununla başlayın:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service/proc/PID/limits dosyasını gerçek süreç kimliğiyle okuyun. Çok süreçli bir dağıtımda ilgili çalışanı da denetleyin. Yapılandırmada saklanan bir değer, bu sürecin onu devraldığının kanıtı değildir.
| Denetim | Kapsam |
|---|---|
Kabuk ulimit ve PAM limits.conf | Kabuğun alt süreçleri veya PAM ayarını gerçekten kullanan oturumlar |
systemd LimitNOFILE= | O hizmetin kaynak ilkesi altında başlatılan süreçler |
Squid max_filedescriptors, desteklendiği yerde | İşletim sistemi kısıtları içindeki uygulama sınırı |
Bir sistem hizmeti, yönetici dosyayı değiştirdi diye PAM düzenlemelerini benimsemez. systemd sınırını değiştirmek uygun olduğunda hizmete özgü bir drop-in kullanın. Squid, max_filedescriptors değerinin değişmesi için yeniden başlatma gerektiğini belgeler; ayarlanmadan bırakılırsa işletim sisteminin yumuşak sınırı devralınır.
Sınırı kullanıcılara göre değil tanımlayıcılara göre ölçün. İstemciler birden çok soket tutabilir ve giden bağlantılar, günlükler ile yardımcı boru hatları da tanımlayıcı tüketir. Sınırı yükseltmek, olası her tanımlayıcı için hemen sabit miktarda RAM ayırmadan daha fazla tüketime izin verir. Ne eski soket başına bellek tahmini ne de 65,535 evrensel bir kapasite gereksinimi ya da Linux tavanıdır.
Hizmet değişikliğinden sonra yeni sürecin sınırlarını amaçlanan değerlerle karşılaştırın. Arızalar bunların çok altında oluşuyorsa gerçekte tükenen kaynağı araştırın.