Lühidalt: memory_limit määrab, kui palju mälu üks PHP päring tohib hõivata; vaikimisi on 128M. Tavatöös seate lõpliku, rakendusele sobiva väärtuse ja lukustate selle käsuga php_admin_value. Kuni PHP2Shelli pole paigatud, soovitab php.net ajutiselt memory_limit=-1, mitte üle kirjutatavana ja kombineerituna piiriga konteineri või cgroup'i kaudu, mitte RLIMIT_AS või RLIMIT_DATA kaudu. Pärast uuendust kehtib taas lõplik väärtus.
Rutiinne säte, millest äkki sai turvateema
Aastaid oli memory_limit arendajate häälestusnupp. Kui veebisait teatab „Allowed memory size exhausted“, tõstetakse väärtust ja probleem on lahendatud. PHP2Shelliga on sellest saanud turvaküsimus ning php.net'i soovitus tundub esmapilgul paradoksaalne: üleminekuks peaks PHP enda mälupiir sootuks ära kaduma.
Taust on CVE-2026-109618. PHP projekti andmetel võib mälupuuduse olek PHP katkestada, kui päringuandmed on vaid osaliselt lähtestatud. Päringu koristamine võib siis käsitleda kehtetuid andmeid kehtivatena. Tehnilised üksikasjad on lehel CVE-2026-109618, mis juhtub mälupuuduse korral PHP sees, selgitab memory_limit ja Out-of-Memory. Haldajale loeb küsimus: milline väärtus kehtib millal ja kus see peab olema?
Mida memory_limit tavatöös annab
PHP käsiraamatu järgi piirab memory_limit mälu, mida skript tohib hõivata, ja kaitseb nii serverit halvasti kirjutatud koodi eest. Vaikimisi on 128M, -1 tähendab piirita. Lühikirjaviisid nagu 256M või 1G on lubatud.
Kaks omadust on turvalisuse jaoks olulised. Esiteks saab väärtust muuta kõikjal, ka töö ajal käsuga ini_set(). Paljud CMS-id ja poed tõstavad seda ise, näiteks importide või pilditöötluse jaoks. Kes tahab väärtuse peale sundida, peab selle seadma käsuga php_admin_value; käsiraamatu järgi ei saa nii seatud väärtusi ini_set() abil üle kirjutada. Teiseks soovitab käsiraamat, et memory_limit oleks suurem kui post_max_size.
Milline väärtus sobib, sõltub rakendusest. Pilk vealogisse näitab, kas esineb teateid ammendunud mälu kohta ja millistel päringutel. Hästi on end õigustanud väärtuse määramine veebisaidi kaupa oma FPM-poolis: heldem importidega poele, napim lihtsale ettevõtte veebisaidile. Üldiselt väga kõrge väärtus kõigile veebisaitidele kingib kaitsetoime ära, sest siis võib üksik vigane või kuritarvitatud päring palju mälu siduda.
PHP 8.5-st alates on lisaks max_memory_limit. Seda sätet saab seada ainult käivitamisel ja see piirab, kui kõrgele memory_limit üldse seada tohib. Kõrgemad väärtused kärbitakse hoiatusega. Vaikimisi -1 tähendab ülempiiri puudumist.
memory_limit pärast PHP2Shelli: php.net'i üleminekumeede
Serverite jaoks, mis pole veel uuendatud versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 või kinnitatud tagasiportimisele, nimetab php.net 21.10.2026 turvateates järgmisi samme. Need vähendavad üksikute ründeteede riski, kuid ei muuda paigaldust php.net'i järgi turvaliseks:
- Seadke
memory_limit=-1, võimalikult nii, et rakendused ei saa väärtust üle kirjutada, näiteks käsugaphp_admin_valueFPM-poolis või Apache'i konfiguratsioonis. - Kontrollige, et lõplikku piiri ei seata kuskil taas, ei teises poolis, kataloogikonfiguratsioonis ega rakenduses.
- Seadke mälupiir konteineri või cgroup'i kaudu, kättesaadavuse kaitseks, võimalikult nii, et ületamisel lõpetatakse ainult mõjutatud töölisprotsess.
- Ärge kasutage
RLIMIT_ASegaRLIMIT_DATA. Need piirid võivad php.net'i järgi esile kutsuda just haavatava vea mälu nõudmisel.
php.net selgitab selle juures, et -1 eemaldab PHP mälupiirini jõudmise sihipärase esilekutsumise võimaluse, kuid madalamal tasandil tekkiv mäluviga võib haavatava teeni siiski jõuda. Kõigi üleminekumeetmete ülevaade on lehel Kiirmeetmed, kui te ei saa veel paikama hakata.
; FPM-pool, nt /etc/php/8.3/fpm/pool.d/www.conf (ainult uuenduseni)
php_admin_value[memory_limit] = -1
# Kus kõikjal memory_limit seatakse (ainult lugemine)
grep -rn 'memory_limit' /etc/php/ /etc/apache2/ 2>/dev/null
grep -rn --include='*.php' -E "ini_set\s*\(\s*['\"]memory_limit" /var/www | head -20
grep -rn --include='.user.ini' 'memory_limit' /var/www
Kuidas seada FPM-teenuse cgroup'i piir, kirjeldab Mälupiiride seadmine systemd ja cgroup'idega. Ilma selle välise piirita võib üksik päring viia kogu serveri mälupuudusse.
Taaskäivitage pärast iga muudatust kõik PHP töölised. Töötav töölisprotsess säilitab oma vanad väärtused.
Mis kehtib pärast uuendust
Parandatud versioonidega on PHP käsiraamatu järgi muutunud ka memory_limit'i käitumine. Alates versioonidest 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 on see pehme piir: mälunõue, mis seda ületab, tohib enamasti enne vea tekitamist veel lõpule jõuda. Uus säte memory_hard_limit_percent määrab kõva piiri, mida iial ei ületata.
| Säte | Väärtus | Mõju käsiraamatu järgi |
|---|---|---|
memory_hard_limit_percent seadmata või -1 |
vaikeväärtus | kõva piir kaks korda kõrgem kui memory_limit kuni 1G, sellest kõrgemal memory_limit pluss 1G |
memory_hard_limit_percent = 150 |
näide | memory_limit=128M korral kõva piir 192M |
memory_limit = -1 |
piirita | siis ei ole ka kõva piiri |
Käsiraamat nimetab ühe praktilise kontrollpunkti: kui memory_hard_limit_percent ei tunta ära, on kasutatav PHP versioon mõjutatud ja tuleb uuendada. Distributsioonide tagasiportimiste puhul kontrollige seisu lisaks paketi muudatuslogi kaudu.
# Kas FPM-i binaarfail tunneb uut sätet? (kohandage versiooninumbrit)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
Pärast uuendust on memory_limit=-1 oma eesmärgi täitnud. Pöörduge tagasi lõpliku, rakendusele sobiva väärtuse juurde ja lukustage see käsuga php_admin_value. cgroup'i piir võib jääda täiendava kaitsekihina.
Kuidas PHP SOS konkreetselt aitab?
- Selgitame välja, kus teie serveris
memory_limitseatakse ja üle kirjutatakse, rakendused kaasa arvatud. - Rakendame php.net'i üleminekumeetmed õiges kohas ja lisame FPM-teenusele cgroup'i piiri.
- PHP paigateenuse kaudu viime PHP parandatud seisu ja taaskäivitame kõik töölised.
- Seejärel seame taas sobiva lõpliku väärtuse ja dokumenteerime sätted.
Korduma kippuvad küsimused
Mis on memory_limit'i vaikeväärtus?
PHP käsiraamatu järgi 128M. Väärtus piirab, kui palju mälu üksik skript tohib hõivata. Seda saab muuta failis php.ini, serverikonfiguratsioonis, FPM-poolis ja töö ajal käsuga ini_set(), kui see pole php_admin_value'ga lukustatud.
Miks soovitab php.net PHP2Shelli puhul memory_limit=-1?
Üks aukudest, CVE-2026-109618, on seotud olekuga mälupuuduse korral. php.net'i järgi eemaldab memory_limit=-1 PHP mälupiirini jõudmise sihipärase esilekutsumise võimaluse, kuid mitte iga mäluviga. Meede ei ole täielik kaitse ja see tuleb ühendada mälupiiriga konteineri või cgroup'i kaudu.
Kas tohin piiri selle asemel ulimit'iga seada?
Ei. php.net soovitab otsesõnu RLIMIT_AS-i või RLIMIT_DATA-t asendusena mitte kasutada, sest need piirid võivad esile kutsuda just haavatava vea mälu nõudmisel. Soovitatav on piir konteineri või cgroup'i kaudu.
Mis kehtib pärast uuendust parandatud PHP versioonile?
Käsiraamatu järgi on memory_limit parandatud versioonides pehme piir, mida täiendab kõva piir memory_hard_limit_percent kaudu. Üleminekumeede väärtusega -1 on siis oma eesmärgi täitnud ja taas peaks kehtima lõplik, rakendusele sobiv väärtus.