Too Many Open Files ve Cannot Assign Requested Address: Proxy Eşzamanlılığında İki Sayaç

İki hata, iki sayaç: dosya tanımlayıcı mı, kaynak port mu?

Linux man sayfasına göre EMFILE hatası “Too many open files” metniyle gelir ve çoğunlukla RLIMIT_NOFILE sınırının aşılmasından kaynaklanır; bu sınır bir sürecin açabileceği en büyük dosya tanımlayıcı numarasını belirler ve her TCP soketi bir tanımlayıcıdır. Kardeşi ENFILE “Too many open files in system” der ve sistem genelindeki fs.file-max sınırına çarpıldığını gösterir. İkisi de bağlantı açma anında, connect çağrısından önce, soket oluşturulurken patlar; yani hata proxy’ye ulaşmadan sizin makinenizde doğar.

EADDRNOTAVAIL ise “Address not available” metniyle gelir ve connect man sayfası nedenini açıkça yazar: soket geçici bir porta bağlanmaya çalışırken geçici port aralığındaki bütün portların kullanımda olduğu görülmüştür. Python bunu OSError 99, Node EADDRNOTAVAIL, Go “cannot assign requested address” olarak gösterir. Bu hata da makinenizde doğar; proxy sunucusunun bir şey reddetmesiyle ilgisi yoktur. İki hata aynı anda görülebilir ama nedenleri farklıdır ve çözümleri de farklıdır: dosya tanımlayıcı sınırı açık soket sayısına, port sınırı ise açık artı yeni kapanmış soket sayısına bakar.

Tanımlayıcı sınırını yükseltmek port hatasını çözmez, hatta açık bağlantı sayısı artınca port hatasını öne çeker. Tersine port aralığını genişletmek tanımlayıcı hatasına dokunmaz. Hangi sayacın dolduğunu bilmeden sysctl değiştirmek, iki hatayı sırayla görmekle sonuçlanır. Thread ve eşzamanlı bağlantı planının nasıl kurulacağı ayrı bir rehberde anlatılır; burada yalnız sınırın kendisi vardır.

Tek proxy uç noktası dörtlüyü neden daraltır?

Bir TCP bağlantısı dört değerle tanımlanır: kaynak IP, kaynak port, hedef IP, hedef port. Doğrudan hedefe giden scraper’da hedef IP her sitede değişir ve kaynak port alanı her hedef için ayrı ayrı kullanılır. Proxy üzerinden giden scraper’da ise bütün bağlantılar aynı hedef IP ve hedef porta, yani proxy uç noktasına açılır. Hedefi bin farklı site olan iş, işletim sistemi gözünde tek hedefe açılan bin bağlantıdır ve dörtlüde değişen tek değer kaynak porttur.

Çekirdek belgesine göre Linux’ta geçici port aralığı varsayılan olarak 32768 ile 60999 arasıdır; aradaki fark 28.232 porttur. Aynı proxy uç noktasına aynı anda açık tutulabilecek bağlantı sayısının tavanı budur. Tavana yalnız açık bağlantılar değil, yeni kapanmış ve TIME_WAIT durumunda bekleyen bağlantılar da sayılır; bağlantıyı aktif kapatan taraf olduğunuzda port o süre boyunca aynı hedef için yeniden kullanılamaz. Linux’ta TIME_WAIT süresi çekirdekte sabittir ve sysctl ile değişmez; yaygın bilinen değer 60 saniyedir.

TIME_WAIT 60 saniye ve 28.232 port varsayımıyla, her istek için yeni bağlantı açıp kapatan bir scraper tek proxy uç noktasına saniyede en çok yaklaşık 470 yeni bağlantı açabilir; üstüne çıktığında EADDRNOTAVAIL başlar. Windows’ta Microsoft belgesine göre dinamik port aralığı 49152 ile 65535 arasıdır ve TcpTimedWaitDelay varsayılanı 120 saniyedir; aynı hesap saniyede yaklaşık 136 yeni bağlantıya iner. Bu tavan hedefin tempo sınırından bağımsızdır; hedef saniyede bin isteğe izin verse de sizin makineniz tek uç noktaya bu hızda yeni bağlantı açamaz.

Rotating gateway kullanan ekipler bu daralmayı en sık yaşar, çünkü ürün gereği tek adres vardır. Static IP listesiyle çalışan ekiplerde her proxy IP’si ayrı bir hedef olduğundan port alanı IP başına ayrı sayılır; bunun ürün tarafı aşağıda anlatılır. Zaman aşımı değerleri de hesaba girer: uzun okuma zaman aşımı bağlantıyı daha uzun açık tutar ve tavana daha erken ulaştırır; değer seçimi zaman aşımı rehberindedir.

Teşhis: hangi sayaç doluyor? Beş komut

Birinci komut sürecin tanımlayıcı sınırını gösterir: ulimit -n o kabuğun yumuşak sınırını verir, cat /proc/<pid>/limits ise çalışan sürecin gerçek sınırını “Max open files” satırında gösterir. systemd belgesine göre birim dosyalarının varsayılan sınırı DefaultLimitNOFILE ile 1024 yumuşak, 524288 sert olarak tanımlıdır; bir servis olarak çalışan scraper, kabukta gördüğünüzden farklı bir sınırla başlamış olabilir. İkinci komut kullanımı sayar: ls /proc/<pid>/fd | wc -l süreçteki açık tanımlayıcı sayısını verir; sınırın yüzde doksanına yaklaşıyorsa EMFILE kapıdadır.

Üçüncü komut port tarafını gösterir: ss -s bütün soketlerin durum özetini basar ve timewait sayısını ayrı verir. Dördüncü komut hedefe göre süzer: ss -tan state time-wait çıktısını proxy adresine göre süzüp satır sayarsanız tek uç noktaya karşı bekleyen port sayısını görürsünüz; bu sayı 28 bine yaklaşıyorsa port tavanındasınız. Beşinci komut aralığı doğrular: sysctl net.ipv4.ip_local_port_range mevcut aralığı, sysctl net.ipv4.tcp_tw_reuse ise TIME_WAIT yeniden kullanım ayarını gösterir; çekirdek belgesine göre tcp_tw_reuse varsayılanı 2’dir ve bu değer yeniden kullanımı yalnız loopback trafiği için açar.

Windows’ta karşılıklar şunlardır: netsh int ipv4 show dynamicport tcp dinamik aralığı gösterir, netstat -ano çıktısında TIME_WAIT satırlarını saymak port tarafını, Görev Yöneticisi ya da Get-Process çıktısındaki Handles sütunu tanımlayıcı tarafını verir. Konteynerde çalışıyorsanız sınır konteynerin kendi sınırıdır: Docker belgesine göre docker run --ulimit nofile=<yumuşak>:<sert> ile verilir, Compose’da ulimits altında nofile için soft ve hard anahtarlarıyla yazılır; ana makinedeki ulimit değeri konteynere geçmez.

Teşhis kaydı iki satırdan oluşur: hata anındaki açık tanımlayıcı sayısı ile sınırı, ve hata anındaki TIME_WAIT sayısı ile port aralığı genişliği. Hangisi sınıra yakınsa o sayaç dolmuştur. İkisi de uzaksa hata başka yerden geliyordur; örneğin proxy tarafı bağlantıyı reddediyor ve istemci kütüphanesi bunu yanlış bir mesajla sarıyordur.

Birinci çözüm: bağlantıyı yeniden kullanın

En etkili çözüm yeni bağlantı açmamaktır. Proxy üzerinden HTTPS hedefe giden her istek bir CONNECT tüneli kurar; tünel açık kaldığı sürece aynı hedef sunucuya giden sonraki istekler aynı tünelden geçer ve ne tanımlayıcı ne port tüketir. Keep-alive’ı kapatan ya da her istek için yeni istemci nesnesi oluşturan kod, bu kazancı sıfırlar. Kütüphanelerin varsayılanları belgelerine göre şöyledir: httpx’te Limits ile max_connections 100 ve max_keepalive_connections 20; aiohttp’de TCPConnector limit 100; Node http.Agent’ta maxSockets sınırsız, keepAlive kapalı, maxFreeSockets 256; undici Pool’da connections null, yani sınırsız; libcurl multi arayüzünde CURLMOPT_MAX_TOTAL_CONNECTIONS 0, yani sınırsız.

Bu listeden iki ders çıkar. Birincisi, sınırsız varsayılanlı istemcilerde (Node Agent, undici, libcurl multi) tavanı siz koymazsanız kütüphane koymaz ve ilk dolan sayaç işletim sisteminin sayacı olur; maxSockets, connections ya da CURLMOPT_MAX_TOTAL_CONNECTIONS değerini eşzamanlılık planınıza göre açıkça verin. İkincisi, keep-alive varsayılan olarak kapalı olan Node http.Agent’ta keepAlive true verilmeden her istek yeni bağlantı demektir; tek proxy uç noktasına karşı en hızlı port tüketen kurgu budur.

Yeniden kullanımın bir sınırı vardır: tünel hedef sunucuya özeldir. Bin farklı siteyi tarıyorsanız bin ayrı tünel gerekir ve havuz sınırı kaç tünelin aynı anda açık kalacağını belirler; havuz dolunca en eski boş tünel kapanır ve kapanan her tünel bir TIME_WAIT bırakır. Hedef sayısı çok, hedef başına istek az olan işlerde bu yüzden yeniden kullanım tek başına yetmez ve ikinci ya da üçüncü katmana geçilir. Bağlantının kapanmasını proxy ya da hedef başlatıyorsa TIME_WAIT onlarda kalır, sizde kalmaz; istemcinin kapatması ise portu sizde kilitler.

İkinci çözüm: sınırları bilinçli yükseltin

Tanımlayıcı sınırı üç katmanda yükseltilir. Kabuk için ulimit -n <değer> yalnız o oturumu etkiler ve sert sınırın üstüne çıkamaz. Kalıcı ayar limits.conf dosyasında nofile satırıyla, systemd servislerinde birim dosyasının LimitNOFILE alanıyla yapılır. Üst tavan fs.nr_open’dır; çekirdek belgesine göre varsayılanı 1048576’dır ve bir süreç bunun üstüne çıkamaz. Python’da sınırı resource.getrlimit(resource.RLIMIT_NOFILE) ile okuyup setrlimit ile sert sınıra kadar yükseltmek, betiğin kendi başlangıcında yapılabilen en pratik düzeltmedir.

Port tarafında iki ayar vardır. net.ipv4.ip_local_port_range aralığı genişletilebilir; alt sınırı 1024’e kadar indirmek aralığı iki kattan fazla büyütür, ama o aralıkta dinleyen servisleriniz varsa çakışma olur; çekirdek belgesine göre net.ipv4.ip_local_reserved_ports ile belirli portlar aralıktan ayrılır. İkinci ayar net.ipv4.tcp_tw_reuse’dur: 1 verildiğinde çekirdek, protokol açısından güvenli olduğunda TIME_WAIT soketlerini yeni giden bağlantılar için yeniden kullanır; varsayılan 2 bunu yalnız loopback için yapar. Bu ayar giden bağlantılar içindir ve tek proxy uç noktası senaryosunda doğrudan işe yarar.

Windows’ta aralık netsh int ipv4 set dynamicport tcp start=<başlangıç> num=<adet> komutuyla değiştirilir; Microsoft belgesine göre başlangıç en az 1025, adet en az 255 olmalıdır. TcpTimedWaitDelay kayıt defterinden düşürülebilir; belge aralığı 2 ile 300 saniye olarak verir ve 30 saniyeyi örnek önerilen değer olarak gösterir. Sınır yükseltmenin bedeli bellek ve istikrardır: on binlerce açık soket çekirdek belleği tüketir ve proxy tarafına aynı anda açılan bağlantı sayısı, ürün için belirlenmiş sınırı aşarsa 407 ya da zaman aşımı dalgası başlar; sınırı bilmiyorsanız destekten sorun, katalogdan okumayın.

Üçüncü çözüm: uç nokta sayısını artırın

Dörtlüdeki hedef IP ya da hedef port değişirse kaynak port alanı yeniden açılır. Static datacenter IP listesinde her IP ayrı bir hedeftir: on proxy IP’sine dağıtılan bağlantılar on ayrı port alanı kullanır ve tek uç noktanın 28 binlik tavanı on katına çıkar. Kataloğa göre static IPv4 datacenter paketleri 100, 250, 500 ve 1.000 adet olarak 15, 25, 45 ve 80 USD’dir; port alanı açısından yüz adet, pratikte ulaşılamayacak bir tavan demektir. Rotating IPv4 datacenter ise tek gateway adresiyle çalışır ve GB bazlıdır, kataloğa göre 10 GB 6 USD; tek uç nokta olduğu için bu üründe birinci ve ikinci katman öne çıkar.

Port bazlı ürünlerde hedef port değişir: kataloğa göre rotating IPv6 datacenter paketleri 1, 5 ve 10 port olarak aylık 29, 80 ve 175 USD’dir ve her port ayrı bir uç noktadır. On port, aynı IP’de on ayrı dörtlü alanı demektir; bağlantıları portlara eşit dağıtan bir havuz kurgusu tek porta yığılmaktan daha geniş port alanı verir. Hedefin IPv6 adresi olup olmadığı ayrı bir sorudur ve IPv6 hedef uyumu rehberinde ele alınır.

Bu katman sizin makinenizin sınırını genişletir; hedef sitenin tempo sınırını değiştirmez. Daha çok uç nokta hedefe daha çok istek gönderme izni vermez; hedefin 429 ya da engel kararı hedefin kendi ölçüsüne göredir ve yeniden deneme ile tempo düşürme ayrı bir konudur. Uç nokta sayısını artırmanın amacı, işletim sistemi sayacının hedeften önce dolmasını önlemektir.

Belirti, neden, çözüm: altı satırlık özet

Hata EMFILE ve açık tanımlayıcı sayısı sınıra yakın: havuz sınırı yok ya da çok yüksek; önce istemci havuzuna üst sınır koyun, sonra LimitNOFILE yükseltin. Hata ENFILE: sistem geneli sınır; aynı makinede başka süreçler de soket tüketiyordur, fs.file-max ve süreç dağılımına bakın. Hata EADDRNOTAVAIL ve TIME_WAIT sayısı 28 bine yakın: her istekte yeni bağlantı; keep-alive açın, havuz sınırı verin, tcp_tw_reuse 1 yapın, aralığı genişletin.

Hata EADDRNOTAVAIL ama TIME_WAIT düşük: aralık daraltılmış ya da ayrılmış portlar çok; ip_local_port_range ve ip_local_reserved_ports değerlerini kontrol edin. Hatalar konteynerde var, ana makinede yok: ulimit konteynere geçmemiş; --ulimit nofile ya da Compose ulimits verin. İki sayaç da uzak ama bağlantı reddediliyor: sınır proxy tarafında; eşzamanlılığı düşürüp destekten ürün sınırını sorun.