Ik werd hier gek van.
Ik kreeg het volgende bericht:
Allowed memory size of 262144 bytes exhausted (tried to allocate 24576 bytes)
TODO LIJST
Controleer phpinfo(), zoek de juiste php.ini-route en bewerk deze.
Wijzig memory_limit in
memory_limit = 128M
Zorg ervoor dat de waarde memory_limit verandert met phpinfo() met als resultaat:
memory_limit 128MB 128MB
Controleer .htaccess en toegevoegd (niet nodig)
php_value memory_limit 128M
En ook om het via php te wijzigen zoals (vóór de foutregel):
ini_set('memory_limit','128M');
Er staat overal dat het geheugen is ingesteld op 128M, maar krijg je die foutmelding nog steeds?
De fout zit in de Swift-bibliotheek (bibliotheek voor het verzenden van e-mails), in abstractSmtpTransport.php, dus het is niet de bedoeling dat mijn code int werkt.
Enig idee???
Bewerken: Ja, de vorige was klaar met het herstarten van apache.
BEWERK 2:
@patrick, voegde dat toe, maar er werd niets herhaald
Geprobeerd met lagere waarde, 28M int elk bestand, herstart apache, zelfde fout (phpinfo toonde nieuwe waarde)
geprobeerd met -1, opnieuw opstarten en dezelfde fout.
EDIT 3: is het niet raar dat het toegestane geheugen groter is dan het toegewezen geheugen? (ondanks het feit dat de toegestane geheugengrootte ver onder het werkelijk toegestane geheugen ligt)
Antwoord 1, autoriteit 100%
Ik zie dat mijn probleem een beetje anders is dan het jouwe, maar ik zal dit antwoord posten voor het geval iemand anders er iets aan heeft. Ik gebruikte MBals afkorting in plaats van Mbij het definiëren van mijn memory_limit, en php negeerde het stilzwijgend. Ik veranderde het in een geheel getal (in bytes) en het probleem was opgelost.
Mijn php.ini is als volgt gewijzigd: memory_limit = 512MBnaar memory_limit = 536870912. Dit loste mijn probleem op. Hoop dat het helpt bij iemand anders! Je kunt de steno van php hierlezen.
Veel succes!
Bewerken
Zoals Yaodong aangeeft, kun je net zo gemakkelijk de juiste steno, “M”, gebruiken in plaats van bytewaarden. Ik heb de mijne veranderd in byte-waarden voor foutopsporingsdoeleinden en heb toen niet de moeite genomen om het terug te veranderen.
Antwoord 2, autoriteit 7%
De waarde van 262.144 bytes is de sleutel tot de diagnose. Je zult dit magische getal overal in PHP-vragen zien verschijnen. Waarom? Want dat is de waarde die PHP krijgt als geheugenlimiet als je probeert de limiet bij te werken met een waarde die het niet kan gebruiken. Een lege tekenreeks levert deze geheugenlimiet op, evenals een onjuiste eenheidsnotatie zoals ‘128MB’ in plaats van de juiste ‘128M’.
262.144 bytes is precies 256 Kibibytes. Waarom PHP naar die waarde draait als het in de war raakt, is mij een raadsel.
is het niet raar dat het toegestane geheugen groter is dan het toegewezen geheugen?
Het getoonde toegewezen bedrag is slechts de meest recente toewijzingspoging, degene die in strijd was met de geheugenlimiet. Zie Toegestane geheugengrootte in PHP bij het toewijzen van minder.
Antwoord 3
Kijk of dit antwoord je kan helpen. Vooral het feit dat CLI ini anders kan zijn dan wanneer het script door een browser wordt uitgevoerd.
Toegestane geheugengrootte van X bytes uitgeput
Antwoord 4
In mijn geval hielpen Mof Gniet, dus ik heb toegewezen geheugen geconverteerd naar bytes met: https://www.gbmb.org/mb-to-bytes
4096M = 4294967296
php.ini:
memory_limit = 4294967296
Antwoord 5
Ik probeerde de limiet van WordPress voor media-uploads te verhogen. Ik volgde het advies op van een blog die ik niet ga noemen om de limiet te verhogen van 64 MB naar 2 GB.
Ik heb het volgende gedaan:
Een (php.ini) bestand gemaakt in WP ADMIN met de volgende gehele getallen:
upload_max_filesize = 2000MB
post_max_size = 2100MV
memory_limit = 2300MB
Ik kreeg meteen deze foutmelding toen ik probeerde in te loggen op mijn WordPress-dashboard om te controleren of het werkte:
“Toegestane geheugengrootte van 262144 bytes uitgeput (geprobeerd om 24576 bytes toe te wijzen)”
De bovenstaande informatie in deze keten heeft me enorm geholpen.
(Stack doet dat meestal btw)
Ik heb het PHP.ini-bestand als volgt gewijzigd:
upload_max_filesize = 2000M
post_max_size = 2100M
memory_limit = 536870912M
Het belangrijkste verschil was dat je alleen M gebruikt, niet MB, en die geheugenlimiet hoog instelde.
Zodra ik het gewijzigde PHP.ini-bestand opsloeg, bewaarde ik het, ging opnieuw naar inloggen en het inlogscherm verscheen weer.
Ik ging naar binnen en controleerde media-uploads, ands bang:
Ik heb Apache nog niet opnieuw opgestart… maar alles ziet er goed uit.
Bedankt iedereen.
Antwoord 6
Ik heb hetzelfde probleem. Om het probleem op te lossen, moet je je PHP-versie updaten.
Antwoord 7
Had een soortgelijk probleem en het aanpassen van mijn wp-config.php-bestand hielp niet. De mijne was een multisite en de stappen die ik heb genomen om het op te lossen staan hieronder. Controleer dus of uw site een multisite is en dit kan helpen.
Log in op uw cPanel en controleer het softwaregedeelte. Klik op het pictogram “MultiplePHP INI Editor”. Selecteer op de pagina “PHP INI asic-instellingen configureren” de Home Directory of het specifieke domein in de vervolgkeuzelijst en bewerk deze.
Dit zijn de wijzigingen die ik in de mijne heb aangebracht:
memory_limit = 256M
upload_max_filesize = 12M
post_max_size = 13M
file_uploads = On
max_execution_time = 180
Sla uw wijzigingen op, wis het cachegeheugen van uw browser voordat u controleert of de fout is verdwenen.
Antwoord 8
In mijn geval was dat omdat ik een andere map had met daarin xampp en al zijn bestanden (htdocs, php enz.). Zoals ik Xampp twee keer in verschillende mappen heb geïnstalleerd en om de een of andere reden de configuraties van de andere van invloed waren op mijn huidige xampp-map en dus moest ik ook de geheugengrootte in het php.ini-bestand van de andere map wijzigen.
Antwoord 9
Als het gebeurt wanneer u een pakket probeert te installeren via Composer, gebruik dan gewoon dit commando
COMPOSER_MEMORY_LIMIT=-1 componist vereist nameofpackage