Squidin todellisen tiedostokuvauksen rajan selvittäminen
Lue käynnissä olevan proxyn prosessirajat ennen kuin muutat PAM-asetuksia tai kopioit kiinteän nofile-arvon kapasiteettiohjeesta.
Tutki käynnissä olevaa daemonia ennen kuin luot kirjautumiskuoren ulimit -n-arvoon. Asennuksessa, joka käyttää squid.service, aloita näin:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLue /proc/PID/limits todellisella prosessitunnuksella. Moniprosessisessa käyttöönotossa tarkista myös kyseinen työntekijä. Kokoonpanoon tallennettu arvo ei todista, että tämä prosessi peri sen.
| Ohjaus | Laajuus |
|---|---|
Kuori ulimit ja PAM limits.conf | Kuoren jälkeläiset tai istunnot, jotka todella käyttävät PAM-asetusta |
systemd LimitNOFILE= | Prosessit, jotka käynnistettiin kyseisen palvelun resurssikäytännön alla |
Squid max_filedescriptors, kun tuettu | Sovelluksen raja käyttöjärjestelmän rajoitusten sisällä |
Järjestelmäpalvelu ei ota PAM-muutoksia käyttöön vain siksi, että ylläpitäjä muutti tiedostoa. Käytä palvelukohtaista drop-inia, kun sen systemd-rajan muuttaminen on tarkoituksenmukaista. Squid dokumentoi, että max_filedescriptors vaatii uudelleenkäynnistyksen muuttuakseen; jos se jätetään asettamatta, käyttöjärjestelmän pehmeä raja peritään.
Mitoita raja kuvausten, älä käyttäjien mukaan. Asiakkaat voivat pitää useita socketeja, ja myös lähtevät yhteydet, lokit ja apuputket kuluttavat kuvauksia. Rajan nostaminen sallii suuremman kulutuksen ilman, että heti varataan kiinteä määrä RAM-muistia jokaista mahdollista kuvausta kohti. Mikään vanha muisti-per-socket-arvio tai 65,535 eivät ole yleinen kapasiteettivaatimus tai Linuxin yläraja.
Palvelumuutoksen jälkeen vertaa uuden prosessin rajoja aiottuihin arvoihin. Jos virheitä esiintyy selvästi niiden alapuolella, tutki resurssia, joka todella ehtyy.