Руковање WireGuard-а се још увек завршава, peer још увек показује скорашњу крајњу тачку, а ипак нова SSH сесија кроз релеј иза њега виси без банера. Та комбинација указује даље од тунела, ка процесу који прихвата socket. Релеј као socat стоји на путу апликације са сопственим буџетом дескриптора, сопственом децом и сопственим наслеђеним ограничењима. Шетња испод почиње код клијента и зауставља се на првој компоненти која не може да отвори још један socket.

Пратите путању пре него што промените број

Пратите један неуспешан захтев уместо да расуђујете о целом тунелу. Клијент пише у тунел, VPN демон дешифрује и усмерава, а релеј прихвата на другој страни. Сваки корак троши дескрипторе, а онај који обично нестане је последњи.

Почните са захтевом који можете да репродукујете и измерите његово време. Ако се TCP руковање заврши, али банер апликације не стигне, релеј је узео socket и затим се заглавио у детету или на својој горњој нози. Ако се само руковање никада не заврши, узрок је усмеравање, firewall или стање слушаоца, а не плафон дескриптора. Забележите који од два облика сте приметили, јер указују на различите процесе.

Избројте и скокове који дуплирају посао. Слушалац који се грана предаје сваки прихваћени socket детету које чува своју копију, тако да је стварни збир својство целог стабла, не само родитеља.

Прочитајте ограничење које је релеј наследио

Једино ограничење које је важно припада процесу који ради, а поставило га је оно што је тај процес покренуло. Уписивање ulimit -n у shell описује shell. Питајте менаџера услуга шта је применио, затим потврдите на PID.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

Датотека limits штампа меки и тврди плафон онако како их процес види. Ниска мека вредност испод дарежљиве тврде значи да је демону дозвољено да подигне сопствени плафон, а неки то раде при покретању; једнаке ниске вредности значе да је извор unit датотека.

Drop-in датотеке се учитавају лексикографским редом и касније побеђују, тако да је systemctl cat vpn-relay.service ауторитативни приказ онога што важи. Уређивање датотеке коју менаџер никада не чита најчешћи је разлог зашто подигнут број нема ефекта.

Одвојите стабилну паралелност од задржаног стања

Два процеса могу да ударе у исти плафон из неповезаних разлога, а лекови се разликују. Потражња која прати корисне паралелне сесије је питање капацитета. Раст који се наставља после краја посла је цурење или скуп сесија које нико није затворио.

Мерите у мировању, на уобичајеном врху и поново неколико минута после престанка оптерећења. Бројање отворених уноса са ls /proc/PID/fd | wc -l према меком ограничењу показује разлику, а број један или два испод плафона је тврдо заустављање, не спор пут.

Када број одбија да падне, гледајте стања socket-а, не укупне збирове. Дескриптори који седе у CLOSE_WAIT значе да је peer затворио, а ваша страна никада није, што је дефект животног циклуса апликације који веће ограничење само одлаже. Ограничите и модел деце: релеј који се грана без плафона за паралелну децу исцрпљује дескрипторе, процесне слотове и меморију заједно.

Проверите нову вредност на живом процесу

После уређивања unit-а поново учитајте менаџер и рестартујте услугу, јер само поновно учитавање никада не замењује ограничења која је процес у раду већ наследио. Проверите на процесу који заиста служи саобраћај.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

Линија awk враћа нови пар; ако и даље показује стари, drop-in који сте уредили није онај који се учитава. Број ss је ваша провера оптерећења, зато отворите очекивани број сесија и гледајте како расте. Број који наставља да расте после затварања тих сесија значи да ограничење никада није било цео проблем.

Једна напомена иде уз свако велико повећање. Апликације које анкетирају са select() не могу да надгледају дескрипторе изнад FD_SETSIZE, што је 1024 у типичним градњама, тако да плафон подигнут изнад тога може да произведе отказе који изгледају неповезано. Референца за извршавање systemd-а носи исто упозорење за услуге које покреће.

Држите рестарт далеко од доступности тунела

Рестартовање релеја одбацује његове активне сесије, а то је одвојен догађај од пада VPN-а. Поређајте промену тако да тунел остане горе док релеј циклузира, и упозорите свакога чија дуга сесија то пресеца.

Враћање је претходна unit датотека плус још један рестарт, и та датотека остаје на месту док нова вредност не преживи радни дан. Затим затворите петљу захтевом који првобитно није успео: једна нова SSH сесија кроз релеј, један пренос довољно дуг да буде важан, и број дескриптора који се враћа на ниво мировања.

Повезани чланци