LimitNPROC наспроти TasksMax: што брои една единица OpenVPN

Неуспешното стартување на OpenVPN честопати доаѓа како жалба за ресурси заедно со добронамерен предлог да се подигне некоја граница, а предлогот успева само во околу половина од случаите. Зад тие неуспеси стојат два неповрзани бројачи. Едниот е ограничување на јадрото на бројот на задачи што ги поседува вистински кориснички ID и се наследува кога процесот се извршува. Другиот е буџет на cgroup што менаџерот на услуги го применува на единица и на сето што таа разгранува. Читањето на ефективната вредност на секој од нив, за единицата што навистина работи, чини помалку од едно погодување.

Два бројачи, две прашања

LimitNPROC е RLIMIT_NPROC под име на systemd, а неговата сметководна единица е вистинскиот кориснички ID. Секој процес што го поседува тој корисник се брои во истиот вкупен збир, вклучително и работата што ја започнале други единици, сесија за најава или задача на планерот. Затоа оваа граница не е горна граница по услуга дури и кога е поставена внатре во единица на услуга, а услугата што разгранува помошник за секој клиент се натпреварува со сето друго што работи под таа сметка. Зафатена задача cron под истиот корисник може да ја турне единицата VPN преку линија што таа самата никогаш не ја преминала.

TasksMax има друг сопственик: контролерот pids на cgroup на единицата, кој брои задачи наместо процеси. Нишките се задачи, па демон што изгледа еднонишков но има базен на работници може да потроши буџет што на прв поглед изгледа далеку поголем од бројот на неговите процеси. EffectiveTasksMax известува што навистина дозволува хиерархијата на cgroup откако родителските сегменти го кажале своето.

Зошто исклучокот за root го менува одговорот

Јадрото не го применува RLIMIT_NPROC на процес што носи CAP_SYS_RESOURCE или CAP_SYS_ADMIN, поради што единица што работи како root без да се откаже од привилегиите е практично неограничена со тоа поставување. Овој единствен исклучок ги објаснува противречните совети што луѓето си ги разменуваат: подигањето на LimitNPROC ја поправа поставеноста што се откажала од привилегиите и не прави апсолутно ништо за онаа што останала привилегирана. Проверете го User= и дали демонот го менува идентитетот по стартувањето пред да и припишете заслуга или вина на таа поставка. Привилегирана единица што подоцна преминува на непривилегирана сметка повторно паѓа под границата во моментот на преминот, што ја прави временската линија на неуспехот исто така вредна за читање.

Фазата на неуспехот дополнително го стеснува. Одбивање за време на подготовката за извршување, грешка при разгранување што ја известува самиот демон и одбиено создавање задача во cgroup даваат различни линии во journal, и само на една од нив одговара поголем буџет.

Читајте ги ефективните вредности, не тие од лушпата

ulimit -u на интерактивна лушпа ја опишува таа лушпа. Не опишува што менаџерот на услуги ѝ предал на демонот и не кажува ништо за сметководството на cgroup. Запрашајте ја единицата наместо тоа, користејќи го името на примерокот што постои на домаќинот, а не пример од прирачник.

systemctl show [email protected] -p User -p LimitNPROC -p TasksCurrent -p TasksMax -p EffectiveTasksMax
cat /proc/$(systemctl show -p MainPID --value [email protected])/limits | grep -i processes

Внатре во контејнер одговорот бара уште две читања, бидејќи внатрешната вредност на infinity опишува само погледот на гостинот. Побарајте од сопственикот на домаќинот сопствениот таван на pids за контејнерот и потврдете дали внатрешниот менаџер на услуги воопшто може да го делегира тој контролер. Вгнездена единица не може да држи буџет што нејзиниот родителски cgroup никогаш не го дал.

Одмерете го обемот на поправката и докажете ја под оптоварување

Изберете број од работното оптоварување, а не од текстот на грешката. Избројте ги процесите што демонот ги стартува по секој поврзан клиент или по секој повик на помошник, помножете со паралелизмот што распоредувањето треба да го поднесе, додајте резерва за административни сесии, па споредете ја таа бројка со двете ефективни вредности. Локалното препишување drop-in ја одржува промената прегледна и преживува надградби на пакети, додека уредувањето на испорачана датотека на единица ја крие измената додека следното ажурирање не ја замени. Запишете ја аритметиката до препишувањето, зашто на следниот човек што ќе ја подигне или спушти му требаат претпоставките, а не конечниот број.

Промените на буџетот се применуваат при извршување, па самото превчитување не го менува размерот на процесите што веќе работат. Рестартирајте ја единицата низ нејзиниот нормален животен циклус, прифатете го прекинот на сесијата и прочитајте ги бројачите повторно на новиот примерок.

sudo systemctl daemon-reload
sudo systemctl restart [email protected]
systemctl show [email protected] -p TasksCurrent -p EffectiveTasksMax
sudo journalctl -u [email protected] -b --no-pager | tail -n 20

Поправката ја докажува рестартирана единица чиј број на задачи стои под обата тавана додека го носи предвиденото оптоварување, заедно со journal што веќе не известува за исцрпување на задачи или разгранување во истата фаза. Чувајте ги бројките пред и потоа заедно со промената, за да започне следната истрага од мерење, а не од истиот совет. Ако бројот сето уште го достигнува таванот, аритметиката била погрешна, а не границата случајно премала, и таа разлика вреди да се знае пред следниот рестарт.