1und1 Memory Limit

[c.romeni]

Hallo Zusammen,

ich habe Contao auf einem 1und1 Webspace installiert.
Ich habe die Paketverwaltung (Composer), Subcollumns und Avisota installiert.
Das ganze Setup habe ich Local gemacht, und die fertige Seite dort dann hochgeladen.
Jetzt wollte ich dort auch noch sticky backend footer installieren, bekomme aber einen Fehler:

Fatal error: Out of memory (allocated 60293120) (tried to allocate 4194304 bytes)

Klingt für mich eigentlich unlogisch, da er gerne 4mb zuweisen wollte, aber nur 60mb zur Verfügung hat??
Vielleicht verstehe ich die Meldung aber auch falsch...

Auf jeden Fall, kann ich mir nicht vorstellen, das die Installation von einer so kleinen Erweiterung wie dem Sticky Footer, dafür sorgen sollte, das out of memory erscheint?

Was kann ich jetzt tun, außer zum installieren von Erweiterung das ding immer erst lokal holen zu müssen?

[Spooky]

Also Subcolumns und Avisota hast du auch jeweils über den Composer installiert oder manuell? Du wolltest die sticky backend footer extension dann noch per Composer installieren und da läuft ihm der Speicher aus?

Unter Umständen werden bei der Installation der Sticky Backend Footer Extension auch noch andere Pakete aktualisiert, sodass deswegen der Speicher ausläuft. 60 MiB sind für die Verwendung von Contao mit Composer nicht gerade viel.

[tab]

Stimmt. Je nach Tageszeit kann ich bei manchen 1&1 shared hosting Paketen noch nicht mal den Composer selbst installieren, geschweige denn Avisota. Da ist dann schon bei 32MB Schluss. Die Meldung heißt auch nicht, daß noch 60MB frei sind, sondern dass bereits 60 MB allokiert sind und die benötigten weiteren 4 MB nicht mehr zur Verfügung stehen.

[c.romeni]

Ok, aber macht es dann Sinn ein Erweiterungssystem zu schaffen, das so viel speicher braucht, das es auf einem Shared Hoster nicht möglich ist Erweiterungen zu installieren??

Ich hatte alles zuerst lokal installiert, und dann auf 1und1 gezogen.
Dort dann Sticky versucht zu installieren.

[Spooky]

Tja.. notfalls musst du es weiterhin lokal machen und dann auf den Server deployen. (Aber Vorsicht: unter Windows gibt es da noch Bugs beim Updaten von Packages.)

[tril]

Ok, aber macht es dann Sinn ein Erweiterungssystem zu schaffen, das so viel speicher braucht, das es auf einem Shared Hoster nicht möglich ist Erweiterungen zu installieren??

Allein Avisota wird mit 64MB RAM seine Probleme bekommen. Ich würde jetzt einfach mal behaupten, deine Systemanforderungen entsprechen aktuell nicht deinem gewählten Hosting Paket. Das Problem tritt nicht durch sticky backend footer auf, sondern weil Composer immer ALLE Abhängigkeiten gegeneinander auflöst. Und da kicken dich einfach die komplexen Abhängigkeiten von Avisota raus. Avisota besteht allein aus ca. 35 Paketen inkl. den Abhängigkeiten.

Bzgl. deiner Frage ob dass Sinn macht oder nicht. Composer läuft auch unter 64MB RAM, allerdings nicht mit den großen Erweiterungen wie Avisota oder MetaModels.
Allerdings weiß ich dass Composer + Avisota auf einem Hosting Paket mit 128MB funktioniert, dass wurde hier im Forum schon berichtet.

Ich vermute auch mal, dass du noch ein altes Paket mit geringeren Werten hast. Laut 1und1 Hilfe liegt der Standard bei 90MB. Laut Hilfe kannst du das sogar über die php.ini manuell erhöhen.
https://hilfe-center.1und1.de/skript...n-a791899.html

Unter Strich: Die Paketverwaltung mit Composer läuft auf Shared Hostern, du solltest vielleicht nur mal dein Paket aktualisieren / an deine Bedürfnisse anpassen ^^

[tab]

Also ich habe für den Moment Installationen mit Composer in den alten "kleinen" shared hosting Paketen bei 1&1 auf Eis gelegt. Das heißt dann eben für diese Kunden, entweder einen ausreichend konfigurierten Webspace zur Verfügung zu stellen (Upgrade) oder auf Erweiterungen, die nur noch über Composer zu installieren sind, zu verzichten. Dass die Installation erst bei 64 MB ausstieg, war wohl sowieso nur der Uhrzeit zu verdanken. Immerhin tut sich ja mittlerweile ansatzweise was bei 1&1. Wo bei den alten Paketen noch stand "bis zu 128 MB RAM", steht heute zum gleichen Preis "bis zu 0,6 GB RAM". Ob das in der Praxis wirklich einen Unterschied macht wird man sehen müssen. Sollte eigentlich schon, sonst macht es ja keinen Sinn, zwischen bis zu 0,6 GB und bis zu 1,2 GB zu unterscheiden. 32 MB entspricht allerdings allen Versprechungen . Garantiertes RAM scheint es bei den aktuellen Tarifen erst ab "Unlimited Plus" zu geben. Da dann allerdings gleich 2 GB. Allerdings dann auch zu einem deutlich höheren Preis.

[lucina]

Es macht auf jeden Fall ohnehin keinen Sinn, beispielsweise Avisota auf einem Sharedhosting-Paket der drei Euro-Klasse einzusetzen, weil es im Regelfall gar nicht die Möglichkeiten bietet, den sicheren Versand von 20000 Mails anzustoßen. Alleine schon die Limitierungen im Sharedhosting bei 1 und 1 sorgen da für Versandzeiten von mehreren Tagen, während ein leistungsfähiger Webserver mal eben 500 Mails in der Minute an einen leistungsfähigen Mailserver rauslässt, der diesen Postberg dann binnen einer Viertelstunde auf den Weg bringen kann.

Insofern ist die Diskussion aus meiner Sicht müßig. Contao ist professionell, und für professionelle Anwendungen benötigt es auch die entsprechenden Ressourcen.

Ich habe hier ein System mit hochfrequentem Massenversand und freue mich über RAM im Gigabytebereich. Der Kunde freut sich darüber, Briefporto in Höhe von mehreren tausend Euro monatlich zu sparen und hat dann auch keinerlei Schwierigkeiten damit, dass die Infrastruktur im dreistelligen monatlichen Preisbereich ist.

[c.romeni]

Ich vermute auch mal, dass du noch ein altes Paket mit geringeren Werten hast. Laut 1und1 Hilfe liegt der Standard bei 90MB. Laut Hilfe kannst du das sogar über die php.ini manuell erhöhen.
https://hilfe-center.1und1.de/skript...n-a791899.html

Das Paket ist von vor ca. 3 Wochen, sollte also ganz aktuell sein. Spasseshalber habe ich auch mal 90 oder 128 in die php.ini gepackt, hat keinen unterschied gemacht.

Insofern ist die Diskussion aus meiner Sicht müßig. Contao ist professionell, und für professionelle Anwendungen benötigt es auch die entsprechenden Ressourcen.

Gebe ich dir nur Teilweise recht.
Denn manchmal sind Entwickler darauf angewiesen auf Hardware zu arbeiten, ob wir wollen oder nicht.
Aber: Ich gebe dir recht, Avisota ist hier einfach nicht die richtige Entscheidung gewesen, weshalb ich die Erweiterung wieder de-installiert habe.
Ich habe vorher noch nicht damit gearbeitet, deswegen bin ich davon ausgegangen, das es zwar ein komplexes System ist, aber nicht zu Überdimensioniert für meinen Bedarf. Ich habe mich getäuscht

Auch wenn mir damit nur Bedingt geholfen wurde (dickerer Webspace, Avisota deinstallieren, lokal arbeiten), frage ich trotzdem weiter:

Sollte es nicht möglich sein, nur eine ausgewählte Erweiterung zu installieren/updaten ohne das gleich ALLES überprüft wird?
Egal ob man Pro-User oder einfacher Fummler ist, der Subcolumns auf seiner Seite möchte...

[tril]

Das Paket ist von vor ca. 3 Wochen, sollte also ganz aktuell sein. Spasseshalber habe ich auch mal 90 oder 128 in die php.ini gepackt, hat keinen unterschied gemacht.

Mit der gleichen Meldung von ~60MB? Oder hat er dann auch gesagt im würden die 90MB/128MB ausgehen?

Sollte es nicht möglich sein, nur eine ausgewählte Erweiterung zu installieren/updaten ohne das gleich ALLES überprüft wird?

Rein logisch: Nein
Woher sollte der Paketmanager wissen, welche Konflikte und welche gemeinsamen Abhängigkeiten und vor allem, welche gemeinsam erlaubten Versionen vorhanden sind, ohne ALLES zu überprüfen?

Einfaches Beispiel:

Extension A benötigt Extension B in Version 1.
Extension A ist installiert und Extension B in Version 1.

Jetzt willst du Extension C installieren.
Extension C benötigt Extension B in Version 2.

Würde man jetzt NUR Extension C und die abhängige Extension B prüfen, würde Extension B auf Version 2 aktualisiert (was im übrigen im aktuellen Extension Repository das Problem ist).
Extension C würde installiert und Extension B auf Version 2 aktualisiert.

Damit ist Extension A unbrauchbar!

Bei aktuellen ER2 bezeichnen wir dies als "Versionshopping", die Erweiterungsverwaltung wird dir ein Update/Downgrade von Extension B endlos anbieten, ohne dass du zum Ergebnis kommst. Denn Konflikte kann die Erweiterungsverwaltung vom ER2 einfach nicht auflösen.



Das sind Konfliktsituationen die sich nur dann auflösen lassen, wenn man ALLE Pakete überprüft. Weil vor der Prüfung weiß man nichts über Abhängigkeiten und Konflikte, dass weiß man immer erst hinterher.



Was möglich ist: Du kannst nur die Erweiterung auswählen die du aktualisieren willst. Dann prüft Composer zwar die Abhängigkeiten der anderen installierten Erweiterungen, aber nur die der installierten Versionen. Damit ist der Aufwand deutlich geringer, weil nicht alle Pakete in allen Versionen und mit allen Abhängigkeiten aufgelöst werden müssen.

[tril]

PS: Ich habe hier gerade ein "altes" Strato Hosting mit 128 MB RAM. Composer läuft sauber bei mitlerweile 24 installierten Paketen

[MacKP]

Hallo Baustelle404,
ich muss dich da enttäuschen. Contao ist KEIN Baukastensystem. Du solltest da schon Ahnung haben, von dem was du machst. Programmieren brauchst du da nicht unbedingt können, aber HTML und CSS solltest du schon drauf haben. Ohne CSS kannst ja an sich nix machen um deiner Seite ein schickes Aussehen zu geben (OK, Theme kaufen geht auch noch.. aber wenn du was anpassen möchtest, brauchst du wieder CSS).

Viele Grüße

[tril]

Dann bin ich auf Contao aufmerksam geworden und dachte, das wäre ähnlich simpel.
Braucht es eurer Meinung nach viel Einarbeitung oder ist der Aufwand ähnlich wie bei dem Baukastenprinzip?
Ich bekomme langsam meine Zweifel...

Hallo Max,
willkommen bei Contao.

Deine Frage hat eigentlich nichts mit dem eigentlichen Topic zu tun, vielleicht mag das ein Moderator abspalten

Zu deiner Frage: Contao ist *kein* Baukasten und wird es auch niemals sein.
Contao ist ein umfangreiches Content Management System wo du quasi bei 0 anfangen must.
Selbst mit einem fertigen Theme ist der Aufwand deutlich größer als bei einem Baukasten. Du musst nämlich erst mal das Theme einrichten, Seiten anlegen und das Theme zuweisen usw.
Deine Zweifel sind also berechtigt, wenn du Contao wie einen Baukasten betrachtest, wirst du wohl enttäuscht werden.

MfG Tristan

[Nina]

Das war leider wieder nur ein Spammer. Sein Beitrag wurde gelöscht.

[tab]

PS: Ich habe hier gerade ein "altes" Strato Hosting mit 128 MB RAM. Composer läuft sauber bei mitlerweile 24 installierten Paketen

Ist bei uberspace auch so, weil man da eben in der Regel auch 128MB zur Verfügung hat wenn das von phpinfo so ausgespuckt wird. Da habe ich das gesamte Metamodels-bundle-all und nebenbei noch andere Erweiterungen schon problemlos per Composer installiert und geupdated. Da war auch explizit von mir das memory_limit in der php.ini auf 128 MB gesetzt (obwohl auch mehr möglich wäre) und das hat gereicht.

Bei 1&1 kommt eben bei phpinfo ebenfalls 128MB, aber was wirklich zur Verfügung steht, hängt offensichtlichvon der aktuellen Serverauslastung ab. Vielleicht sollte man besser schreiben "von der aktuellen Serverüberlastung" . Manchmal (meistens) sind es 32 MB, manchmal 64, manchmal 128. Ich habe vor einiger Zeit ein wenig mit primitiven Skripts experimentiert, um das tatsächlich zur Verfügung stehende Memory in etwa zu bestimmen. Da hat sich das im Minutentakt geändert. Zudem scheint auch die Fehlermeldung die von Contao erzeugt wird, nicht unbedingt damit übereinzustimmen. Der Fehler kommt - zumindest gefühlt, es genau festzustellen ist bei den kurzfristigen Änderungen schwierig - schon bei weniger RAM als eigentlich laut Skript verfügbar wäre, keine Ahnung was 1&1 da noch mit reinrechnet, bzw Contao/PHP eben nicht in der Fehlermeldung berücksichtigt.

[tril]

Alternativ könnte man mal den Detached Mode auf dem 1&1 Hosting ausprobieren.