Fatal error: Out of memory - Optimierung der php.ini und my.cnf

1. Was hast du gemacht, als die Meldung auftrat?
2. Wie lautet die Meldung komplett?

Und, meine Herren. Von so viel Power träume ich! ;) 192MB RAM und 500 Sekunden fürs Script. Einzig deine POST- und Upload-Size könnten mit 34 und 26MB auffallen. Wobei auch das reichlich ist.

Das kannst du auf nem 386er machen, dann überlegst du dir vllt. nochmal in dem Zusammenhang das Wort Power zu nutzen :D

Und wer wartet 500 Sekunden bis die Seite geladen wird? Wenn das mal nötig ist, ist das auch nicht eben ein Zeichen von Power. Mit 192 MB PHP Memory Limit wird ja auch nix schneller - zum Glück aber auch nicht langsamer.

Power ist aber was anderes ;)

---

Aber mal zum Thema: Was möchtest du denn mit einem vServer mit 256 MB? Nun stell dir vor, dein Drupal braucht dann gerade mal sagen wir 90 MB. Meinst du MySQL, Apache, Kernel, Mailserver, die übrigen vielen kleinen Helferlein , etc. quetschen sich alle in den Rest rein? Im Grunde fährst du so ein System stets auf Anschlag und bei jedem Besucher und jedem neuen Modul musst du zittern, ob die Karre nicht gleich anfängt zu swappen.

Viel interessanter fände ich die Frage nach der Ausgabe von phpinfo(). Viele konfigurieren sich nämlich den Wolf in entweder nicht der richtigen Konfigurationsdatei, oder aber vergessen den Dienst zu reloaden.

Naja, vermeiden lässt sich die Fehlermeldung nur dadurch, dass auch tatsächlich immer mind. genausoviel RAM zur Verfügung steht, wie gebraucht wird. Das heisst in erster Linie mal dein memory_limit anzuheben. Wobei 192 MB allerdings leicht übertrieben sein dürften. Wenn du tatsächlich soviel brauchst, hast du entweder zuviele Module installiert oder solltest auf einen dickeren Server wechseln.

Wäre also zunächst einmal interessant, welche Module du in Verwendung hast und wie dein Traffic aussieht. Wenn du, sagen wir mal 10 Besucher gleichzeitig zu Stoßzeiten hast und deren Anfragen jenseits von 5 Sekunden bis zur vollständigen Abarbeitung brauchen, dann kann es dir durchaus passieren, dass dir das RAM ausgeht, weil besagte Besucher halt Resourcen blockieren (10 Besucher mal angenommene 30 MB pro Apache Prozess macht schnell 300MB komplett und wenn grad nur die zugesicherten 256 MB zur Verfügung stehen, siehts halt düster aus).

Vielleicht hilft dir auch dieser Blogpost über Drupal am Limit etwas weiter.

Ach was. Na dann ruf ich mal meinen Hoster an, ob er noch nen 386er für mich rumzustehen hat.

Zu eng geblickt. Stell dir vor, du hast eine Anwendung, die Daten via FTP bezieht, die jenseits der 10MB liegen. Davon mehrere mit einem Mal und knackst die 500 Sekunden im Nu. Und das ist nur EIN Beispiel... PHP ist nicht nur für Webseiten da... :D

Nein schneller nicht, aber deine Anwendung bricht nicht ab, wenns mal zur Sache geht. Wie beim Thread-Ersteller im Übrigen. Ich habe auch nicht gewertet, ob 192 MB zu viel seien. Wenn er die hat, kann er sich doch glücklich schätzen, auch wenn er sie mit Drupal wahrscheinlich nicht brauchen wird. Ich brauchte 192 bisher nicht. 128 aber wohl. Aber auch die 192 werden wahrscheinlich irgendwann kommen.

Nope. q.e.d.

Erst lesen, dann denken, dann posten. Danke.

Es gibt genug Hoster, die ihre Karren zum Anschlag vollhauen um möglichst viel Geld mit möglichst wenig Hardware zu verdienen, bzw. bei vermeintlich gleicher Gleistung noch ein Paar Cent günstiger als der Rest zu sein. Ich kann in eine Dual-Core Maschine je nach Board auch 8 - 16 GB RAM reinhauen und dann passen dort doch gleich wieviele VPS á 256 MB RAM drauf? Vllt. hat der Autor auch Glück und es ist ein Dual Quadcore mit 1 GB RAM und nur 2-4 VPS? Aber wissen wir es? Nö.

Was bitte hat PHP mit einem FTP-Upload zu tun? ;-)

Ob es beim Thread-Ersteller ursächlich am php_memory_limit liegt, ob seine Einstellung überhaupt aktiv ist, das ist zum jetzigen Zeitpunkt noch gar nicht klar. Da der Gute selbst sagt von Server-Administration noch nicht viel Ahnung zu haben, sollte man hier das Spektrum möglicher Fehlerquellen auch entsprechend weitläufig halten. Foren sind voll von Beiträgen, wo Admins vermeintlich ihren Postfix, Apache, MySQL, wahtever umkonfiguriert haben und vergessen haben den Service neu zu laden / neu zu starten.

Den Server neu gestartet.

Fatal error: Out of memory (allocated xxxxxxx) (tried to allocate xxxxxx bytes) usw. ist seitedem nicht mehr aufgetreten.

Ich habe eine Menge von Modulen installiert, die meiner Meinung nach aber alle notwendig zum Betrieb der Seite sind.

Soweit funktioniert alles, was ich wollte.

Würde es denn was bringen, wenn ich einen anderen vServer mit mehr Leistung nehme

Ich habe derzeit einen vServer S von "prosite.de" und würde unter Umständen bis zum vServer L Upgraden.
Oder hättet Ihr andere Alternativen, auf denen recht umfangreiche Drupal-Seiten laufen würden?

MfG
Crashy

Mal ganz ernsthaft: Wieviel Hilfe erwartest du eigentlich, wenn man dir jede Information einzeln aus der Nase ziehen muss? Man kommt sich hier ein bisschen vor wie ein Automechaniker, dem der Kunde sagt: "Die Karre läuft langsam" und der dann langsam rausfinden muss, dass der Kofferraum voller Wackersteine gepackt wurde, ein Quietscheentchen unter dem Gaspedal liegt und ein Wohnwagen hinten dran hängt.

Wie bitteschön erwartest du, dass irgendjemand eine Leistungsabschätzung machen kann, wenn du nichtmal angibst, welche Module du installiert hast?

Ich sagte doch gar nichts von Upload?! Aber hier: http://www.php.net/ftp oder auch hiermit http://www.php.net/curl ...

Zur Sache: Crashy, ich meinte nicht, was du danach gemacht hast, sondern was du getan hast, was dein Memory-Problem ausgelöst haben könnte. :D

Hallo,

hier mal alle aktivierten Module:

Advanced Navigation Pack
Advanced Book Blocks
Jquery Menu

CCK
Content
Content Copy
Content Permissions
Content Taxonomy
Content Taxonomy Autocomplete
Content Taxonomy Options
Content Taxonomy Tree
Content Templates
Fieldgroup
FileField
Image FUpload (CCK)
ImageField
Link
Node Reference
Number
Option Widgets
Text
User Reference

Chaos Tool Suite
Chaos tools
Page Manager
Views Content panes

Content Profile
Content Profile
Content Profile User Registration

Kern - Optional
Aggregator
Book
Comment
Contact
Locale
Menu
Path
PHP filter
Poll
Profile
Search
Statistics
Taxonomy
Throttle
Tracker
Trigger
Update Status
Upload

Datum / Zeit
Calendar
Calendar iCal
Calendar Popup
Date
Date API
Date Locale
Date Popup
Date Repeat API
Date Timezone
Date Tools

Image Cache
Image API GD2
Image Cache
Image Cache UI

E-Mail
Block user messages
Private messages
Privatemsg filter

Sonstige
Tab Tamer
Views Node Taxonomy Filter
'me' Aliases
Advanced Profile Kit
Advanced User Management
Author Pane
Automatic Nodetitles
FCKeditor
Frequently Asked Questiosn
Image FUpload
IMCE
Lightbox2
Paging
Pathauto
Quick Tabs
Taxonomy Manager
Taxonomy redirect
Token
Webform

Panels
Mini Panels
Panel Nodes
Panels

Spam Kotrolle
Captcha

Taxonomy
Cumulus
Tagadelic

Taxonomy Image
Taxonomy Image
Taxonomy Image Blocks
Taxonomy Image Link Alter
Taxonomy Image Node Display

Taxonomy Menü
Taxonomy Menu
Taxonomy Menu Custom Path
Taxonomy Menu Hierarchy
Taxonomy Menu Vocabulary Path

User Interface
Calendar Block

User Relatiosnships
UR-API
UR-Blocks
UR-Panels Visibility
UR-UI
UR-Views

Benutzeroberfläche
External Links
jQuery UI

Ansichten
Bonus: Panels
Media RSS
Tagadelic Views
Views
Views UI

Bewertung
Fivestar
Voting API

MfG
Crashy

Ich habe n bissl mit Caching Modulen rumexperimentiert. Die habe ich mittlerweile aber alle schon wieder deaktiviert.

Also auf das Core Upload Modul kannst (und solltest du) schonmal verzichten, wenn du CCK FileField einsetzt. Das Core Profile Modul brauchst du vermutlich ebenfalls nicht, wenn du Advanced Profile Kit einsetzt. Views UI kannst du im laufendem Betrieb ebenfalls deaktivieren.

Vermutlich lässt sich noch einiges reissen, wenn du APC (Advanced PHP Cache) installierst. Der beschleunigt die Seitenerstellung durchaus um einiges und sorgt damit dafür, dass RAM früher wieder für andere Prozesse zur Verfügung steht.

Mit Panels und Views solltest du allgemein sparsam umgehen. Das sind die schlimmsten Resourcenfresser überhaupt.