Taxonomy mit vielen Begriffen: Auflistung nicht mehr möglich (memory exhausted)

Es sollte Dir bereits bekannt sein, daß je nach Aufgabenstellung 64MB PHP-Memory für Drupal nicht genug sind. Bei Dir ist das jetzt der Fall. Da hilft nur das Memory Limit für PHP zu erhöhen. Ich setze als Standard 96MB ein und, wenn es sein muß, auch 128MB.

Beste Grüße
Werner

Hallo Werner,

besten Dank für deine schnelle Antwort.

Das ist mir schon bewusst - die Seite soll soweit ich weiß bei einem shared hosting Anbieter liegen - dort kann man das Limit meist nicht so hoch setzen.

Nun habe ich das lokal mal auf 128mb erhöht, dann kam die Meldung, dass die max_execution_time zu wenig ist (war aber auch schon auf 360). Gut, habe ich die auch erhöht, nun kommt wieder memory exhausted (die 128 mb reichen also auch nicht).

Gibts denn ne andere Möglichkeit, Taxonomy zu bearbeiten bzw. umzusortieren (z.B. verteilt auf mehrere Seiten)?

Wenn Du das lokal testen kannst, würde ich das Memory-Limit so lange erhöhen, bis es paßt. Dann weißt Du, daß es geht und wieviel Memory benötigt würde.. Für den Einsatz würde ich aber versuchen, das Vokabular aufzuspalten. Ich habe aber keine Erfahrung damit, da ich mit so großen Vokabularen noch nicht gearbeitet habe.

Beste Grüße
Werner

Aber mit Views müsste sich doch eine entsprechende Ansicht mit Seiten und Pager erstellen lassen, oder?

Habe das jetzt nicht probiert, aber das dürfte doch gehen. Z.B. 20 Begriffe pro Seite, alphabetisch geordnet usw. Ist eben etwas umständlicher, aber dafür würde es funktionieren. Denn wenn der Fehler auch bei 128 MB kommt, wird's auf Shared Hosting langsam echt knapp.

Hi,

das Problem mit Views: dadurch lässt sich das Vokabular ja auch nicht mehr umsortieren.

Für alle, die es interessiert: Mit dem Taxonomy Manager klappt die Bearbeitung ganz gut.

Bei sehr großen Taxonomy Listen sind die Abfragen offensichtlich nicht gerade optimal. Je nach technischem Hintergrundwissen würde ich mir mal anschauen was Drupal da genau macht und dann auf Grund der eigentlichen Ursache (z.B. könnte das sein Drupal geht den gesamten taxonomy Baum durch um einen Begriff anzuzeigen) nach Lösungen suchen.

Unter Drupal 5 hatte ich das Problem auch schon mal letztlich wurde das Feature dann aber eingestampft weshalb ich leider keine Lösung präsentieren kann aber etwas in die oben beschriebene Richtung war der Grund. Klar man kann auch meist mit Hardware nach solchen Problemen schmeißen aber das ist nicht unbedingt die schlauste Herangehensweise.

Anm: Die Core-Taxonomy Funktion von Drupal ist sehr gut und flexibel. Aber eben nicht unbedingt für jeden Use-Case gleichermaßen gut geeignet.

Tja, dann sollte die ehrliche Info an den Kunden lauten: Sorry, auf Shared Hosting (ist sowieso Blödsinn für CMS Systeme) läuft das nicht, wir müssen VPS oder einen dedicated root server haben. Mit nem Trabbi Motor lässt sich nunmal kein Sattelschlepper antreiben.

Sorry, aber diese allgemeine Aussage halte ich schlichtweg für falsch. Es gibt genügend Drupal-Installationen, die auf Shared Hosting super laufen, kommt eben immer auf die Anforderungen an. Aber es gibt auch welche, die betreiben ihr Drupal auf einem Shared Hosting mit 64 MB Memory, ohne Probleme zu haben. Und die sollen dann das 10fache ausgeben, ohne einen Nutzen daraus zu ziehen?

Das kann man so pauschal nicht sagen - Zum einen: shared host != shared host. Zum anderen läuft Drupal Core mit einigen Modulen gut bei 16MB Speicher für PHP.

Je nach dem wie gut etwas in Drupal umgesetzt ist läuft es eben gut bis gar nicht auf einem System X. Natürlich hat ein normaler Webspace Einschränkungen, aber zuerst sollte man sich die Technik anschauen. Um bei der Auto-Analogie zu bleiben: Ein als Sportwagen konzipiertes Auto mit 500ps wird nicht besonders gut darin sein große Lasten zu transportieren. Dafür gibt es den 500ps Lastwagen. Ähnlich verhält es sich bei der Softwareentwicklung. Die Qualität der Straße oder die reine PS-Zahl sagen da noch recht wenig über die Fähigkeit des Autos in einem Bestimmten Anwendungsfall aus.

Der (Haupt-)Grund ein CMS einzusetzen ist der, dass man seinen Content nicht mehr von Hand verwaltet kriegt. Drupal speichert seinen Content in einer Datenbank. Die Zugangsdaten zu der Datenbank stehen in der settings.php Datei. Jeder der auf derselben Maschiene einen Account hat und sich Zugang zur settings.php Datei verschaffen kann, kann damit auch meine Website übernehmen (bitte keine Diskussion über PHP Safe mode. Das feature ist nicht ohne Grund deprecated). Von dem Ärger, den man hat, wenn andere Kunden meinen CPU/Memory Hog spielen zu müssen, respektive wenn man selber resourcen frisst wie blöd und dann gedrosselt wird, gar nicht zu reden.

-> CMS auf Shared Hosting ist Blödsinn und am falschem Ende gespart!

Ein einfacher VPS ist bereits für 10€/Monat zu haben.

Ja und der VPS für 10 €/Monat wird dann sicher viel bessere Leistung bringen als ein ordentliches Shared Hosting-Paket... Sorry, aber das glaube ich dir einfach nicht.

Wer meinen Admin-Account hacked, kann auch meine Seite übernehmen -,-'

Aber gut, genau diese Diskussion mit genau den beiden Ausgangsmeinungen hatten wir vor nicht allzu langer Zeit schon an anderer Stelle und das wäre hier glaube ich zu sehr OffTopic. Ich bleibe bei meinem Shared Hosting, schon allein deswegen, weil ich keine andere Wahl habe, ich bin NICHT der Meinung, dass Shared Hosting für ein CMS Blödsinn ist (eher halte ich diese pauschale Aussage für Blödsinn) und fertig.

VPS erlaubt dir System tweaks, Shared hosting nicht:
* Du kannst den Webserver anweisen, Seiten komprimiert auszuliefern. Entgegen Drupals eigener komprimierung funktioniert das auch noch für CSS und Javascript Dateien -> Schnellerer Download -> Frühere Freigabe von Resourcen -> geringeres thrashing Risiko.
* Du kannst auf .htaccess Dateien verzichten (siehe Apache Doku, warum).
* Du kannst genau die Apache Module verwenden, die du brauchst oder auch ganz auf apache verzichten und Lighttp verwenden -> geringerer Memoryfootprint -> ebenfalls geringeres thrashing Risiko.

Irgendwie scheint es mir, als würdest du das Problem nicht verstehen: Shared Hosting ist ein potentielles Einfallstor, um deinen Admin-Account zu hacken. Zur Illustration: Du bist Kunde A, ich bin Kunde B und wir beide haben einen Account auf dem Shared Host. Ich komme vielleicht nicht per FTP an deine settings.php Datei ran, aber ich könnte auf meine Seite ein Script hochladen, welches folgendes enthällt:

Wenn der sysadmin hier geschlafen hat(*), hab ich die Zugangsdaten zu deiner Datenbank und kann beliebig an deinen Seiten rumpfuschen (mal dir selber aus, welchen Spaß ich haben könnte, wenn du einen Onlineshop betreibst und Kundendaten in deiner DB hast). Desweiteren musst du dir nicht nur Gedanken darüber machen, ob die 25+ anderen Kunden auf dem SH (die du nicht kennst) vertrauenswürdig sind, sondern auch ob sie ihre Seiten soweit abgesichert haben, dass ihnen niemand obigen Code schnipsel unterjubeln kann. Die Tatsache, dass man in erster Linie zu SH greift, weil man von Systemadministration keine Ahnung hat, wirkt hier nicht sonderlich beruhigend.

(*) Eine vollständige Diskussion über Safe mode und Wege, ihn auszutricksen erspar ich mir hier mal. Google dürfte zu dem Thema ausreichend Material bereit halten.

Und da ich auch gerne das letzte Wort habe: Es ist schön, wenn man eine Meinung hat. Es ist schöner, wenn man sie auch begründen kann. Shared Hosting kam zu einer Zeit auf, als man kostengünstig mehrere Präsenzen auf einer Maschiene unterbringen musste und als Websites noch aus statischen HTML files bestanden, die jeder lesen konnte (d.h. es war damals ein ausreichender Schutz, die Dateien lediglich auf read-only zu setzen). Beide Bedingungen sind unter Drupal nicht mehr gegeben. Dementsprechend ist es schon alleine aus Sicherheitsgründen nicht vertretbar, CMS auf Shared Hosting laufen zu lassen, auch wenn es noch so billig sein mag.

Ich habe nen Dual Quadcore im Einsatz auf dem 3 gesharete Websites laufen. Zeig mir mal den 10 Euro VPS der das schafft ;)

Abgesehen davon richten sich VPS an Leute die das Ding auch warten können und damit meine ich nicht nur mich ins Plesk einzuloggen und da ein wenig rumzuklicken. Für 99% aller (Drupal-)Websites ist Shared Hosting ausreichend. Der Großteil der Seiten wird eh von quasi-statischen Firmenpräsentationen gestellt. Ein VPS ist da Perlen vor die Säue und klaut zudem noch eine wertvolle IPv4 Adresse. Zum Einen hat, wie Exterior schon anmerkte, ein Billig-VPS häufig auch nicht mehr RAM als mein iPhone und zum Anderen kann mein Kunde mit SSH und dergleichen nichts anfangen. Wozu auch?

Zum einen ist das allgemein so nicht korrekt - unterschiedliche Shared Hosting Pakete / Anbieter bieten auch unterschiedlich viele Möglichkeiten über die .htaccess einzugreifen - zum anderen ist vieles für eine "normale" Website und dessen Inhaber irrelevant. Auf die .htaccess zu verzichten bringt dir erst was wenn dein 10 Euro VPS den Anfragen schon lange nicht mehr gewachsen ist. Lighttp wird im Drupal-Umfeld zugunsten von nginx kaum noch verwendet, da die Entwicklung dort einfach stagniert und es in der Praxis gerne mal Memory Leaks etc gibt. Hier gilt zudem dasselbe wie für die .htaccess.

Wenn der Sysadmin geschlafen hat, ist es unerheblich ob er auf einem Shared Server oder auf deinem VPS oder der darunterliegenden Maschine schlampt. Zu dumm nur, dass beim VPS der Kunde selbst der Sysadmin ist und der häufigst anzutreffende Kunde hat im Leben noch keine Shell gesehen, geschweige denn dass ihm zu erklären wäre warum er sich den Adminaufwand selbst an die Backe heften sollte (sei es indem er es selbst macht oder jemanden dafür bezahlt).

Ich kann natürlich immer das Bild vom bösen und anfähigen Hoster malen und die Pferde scheu machen, aber glaub mir, es gibt auch Hoster die wirklich was von ihrem Business verstehen und da kannst du auch ohne den überflüssigen Safe Mode nicht wild auf andere Webs zugreifen. Die von dir geschilderten Szenarien sind nicht aus der uft gegriffen, aber fernab davon die Regel bei Hostern darzustellen.

Da musst du dir mal an die eigene Nase fassen, was die Begründung angeht, denn wie oben bereits gesagt stimmt das von dir gezeichnete Bild schlichtweg nicht. Zudem verlagerst und potenzierst du Sicherheitsaspekte mit VPS lediglich und löst sie nicht. Ein System als Ganzes ist nicht sicherer, wenn ich daraus 10 gleiche Systeme machen kann. Klar, das erzählt man gerne auf den gerade haufenweise stattfindenen Seminaren zum Thema Virtualisierung, aber gegen die einfache Wahrheit, dass mit steigender Komplexizität eines Systems auch die Sicherheitsprobleme mehr werden, hilft alles Marketing nichts. Und Maler Müller weißzumachen, er müsse nun den Hoster wechseln und sich einenen teureren VPS anlachen, müsse seinen EDV Service bitten bei ihm intern die E-Mail-Umstellung zu handeln und mich beauftragen seinen VPS für eine Wartungspauschale auf dem Laufenden zu halten mag ja für den Einen oder Anderen ein nettes Geschäftsmodell sein, aber ich halte es so verallgemeinert wie du es darstellst schlichtweg für unlauter.

Seltsamer Vergleich, insbesondere da:
* Eine Drupal Website eher RAM als CPU braucht (siehe ursprungsposting)
* Ein VPS selbstverständlich auch für Shared Hosting verwendet werden kann. Der Unterschied zum SH vom Provider ist allerdings, dass man sich seine Nachbarschaft selber aussuchen kann.
* Wie du weiter unten anmerkst, gehst du sowieso von quasi statischen Firmenpräsentationen aus. Diese Klasse von Websites erzeugt eher selten genug Traffic, um eine auch nur einen schwachbrüstigen VPS ins Schwitzen zu bringen.

Ähm... ja? Verkaufst du deinen Kunden Drupal etwa als "wartungsfreies" Paket, bei dem man sich um nix kümmern muss? Fände ich persönlich ja ein wenig unseriös.

... Für die Drupal eventuell ein bisschen Overkill sein könnte, meinst du nicht auch? Wenns denn unbedingt trotzdem Drupal sein soll, dann könnte man in diesen Fällen durchaus über das html_export Modul nachdenken. Vorteil davon ist, dass man sich weder um Updates noch um Datenbankintegrität sorgen machen muss. Probleme mit dem memory limit oder der execution time gibts schonmal gar nicht und ohne PHP overhead werden Seiten auch rasend schnell ausgeliefert.

Mal ganz davon abgesehen, dass diese Internetpräsenzen vom Typ "Webvisitenkarte" in den meißten Fällen sowieso zum Schornstein raus geblasenes Geld sind und man meiner Meinung nach einen Kunden falsch berät, wenn man ihm eine "Hallo, wir sind da" Website andreht.

Ich finde es seltsam wie du deine Prioritäten setzt. Die Tatsache, dass IPv4 Adressen knapp werden ist kein Grund, gentlemanlike auf eine zu verzichten, wenn möglich, sondern eben genau sich eine zu sichern solange es noch geht. IP Adressen schwimmen nunmal nicht frei im Internet rum, wie Fische im Wasser, sondern sind bereits an Rechenzentren zugeteilt und wurden von diesen mit der festen Absicht, sie an Kunden weiter zu reichen, reserviert. Wenn du keine willst, will sie halt ein anderer. Womöglicher einer, der ein bisschen weitsichtiger plant und die Möglichkeit in Betracht zieht, dass seine Website auch über HTTPS erreichbar sein sollte. Zumindest für den Loginbereich kann das durchaus sinnvoll sein.
Dann wiederum: Systemsicherheit spielt für dich und Exterior anscheinend sowieso nur eine untergeordnete Rolle.

[/quote]

Klar, wozu auch sollte man einem Kunden eine Website verkaufen, die in erster Linie auf wartungsfreiheit getrimmt ist? Von denen möchte ja auch nie wieder was hören.

Eine Drupal Website braucht ebenso RAM wie CPU. Wo im Einzelfall der Bottleneck liegt ist von Site zu Site sehr unterschiedlich. Das ursprüngliche Problem hier im Thread lag auch nicht per se am RAM, sondern am zugewiesenen Grenzwert in der php.ini. Dieser muss mit Erfordernissen im Normalbetrieb (Zugriffe durch User) aber nicht viel zu tun haben, da diese Spitzenwerte nur auf ganz bestimmten Seiten im Backend des Admin erreicht werden.

Die durchschnittliche Website braucht sich ihre Nachbarschaft nicht aussuchen. Sie läuft zufriedenstellend auf marktüblichem Shared Hosting und auch wenn ich selbst Server administriere und Hosting anbiete sehe ich nicht, warum ich jemandem etwas aufschwatzen sollte, so lange es nicht notwendig ist.

Ich kann Dienstleistung lediglich anbieten. Was meine Kunden letzten Endes an Leistung einkaufen ist ihre Entscheidung und wie aus dem eben Gesagten schon herausklingt, nötige ich niemanden dazu bei mir hosten zu lassen. Wenn ich das vorhandene Hosting Paket eines Kunden für ausreichend erachte oder andernorts für vergleichweise wenig Geld (ich konkurriere bewusst nicht mit den Stratos der Welt) ihm eines anraten kann, tue ich das. Mit Hosting im unteren Segment kann man praktisch nur Peanuts verdienen und hat dafür den ganzen Support am Hals. Ich konzentriere mich lieber auf einige wenige und habe so mehr Zeit für Projekte.

Ich rede dabei nicht von Visitenkarten, sondern von mehr oder minder klassichen 10-Seitern und der Möglichkeit für den Kunden Pressemitteilungen reinzusetzen, Produkte einzustellen, etc. Das ist, da die meisten von den Möglichkeiten nur suboptimal Gebrauch machen, für mich eine quasi-statische Website. Waffe der Wahl ist dafür bei mir nunmal Drupal. Den Stress mal irgendwann von Joomla, Wordpress, you-name-it migrieren zu müssen vermeide ich dadurch und da ich nur Drupal mache, kann ich diese einfachen Fälle auch relativ easy umsetzen. Es zwingt mich ja niemand in jedem noch so kleinen Drupal-Projekt gleich alle 3000+ Module reinzukloppen.
Bei deisen Seiten gibt es kein Problem mit dem PHP Memory Limit, der Execution Time oder sonstwas, da ich den Webspace auf Herz und Nieren geprüft oder ihn gar angeraten habe. Das ist es nämlich, was ich im Kern tue: Ich berate.

Die Hoster binden sich die Kosten für die Netze nicht einfach so ans Bein, sondern weil sie die Dinger brauchen. Bei Shared Hosting kannst du x Präsenzen über eine IP laufen lassen und musst erst eine zusätzliche aufschalten, wenn jemand ein eigenes SSL Zertifikat nutzen will. Für nen VPS geht immer mindestens eine IP drauf und oft kann man bei VPS-Angeboten später auch keine zusätzlichen mehr nachordern und man steht mit dem Projekt mal wieder vor einem Umzug.
Mich scheren IPs nicht primär, aber ich verliere das große Ganze nicht aus den Augen.

Sehr lesenswert ist übrigens auch die Aussage von Manuel Schmitt (Geschäftsführer von manitu) zum Thema warum er keine virtuellen Server anbietet: http://www.hostblogger.de/blog/archives/2501-Nachgefragt-Hoster-ohne-vSe...

Ja, warum sollte man einen Kunden zufrieden stellen und ihm eine Lösung bieten, die einfach nur funktioniert? Herrje, man stelle sich vor jeder Kunde wäre mit seiner Website auf ewig zufrieden, dann hätten wir ja morgen schon alle nichts mehr zu tun, nicht wahr!?

Keine Ahnung welchen Anspruch andere hier an sich und ihre Arbeit haben, aber ich möchte mein Geld primär nicht damit verdienen Probleme lösen zu müssen die der Kunde ohne mich nicht gehabt hätte. Es gibt unter den Websites der Welt viele Karteileichen. Das ist nunmal so. Die Auftraggeber leben nicht im und mit dem Web, alles was ihnen in Gesprächen erzählt hat ist verflogen und so dümpelt die Site vor sich hin. Ab und an wird mal eine Kontaktperson im Text geändert und ansonsten dauert es Jahre, bis die Geschäftsführung die Site über hat und man etwas Neues möchte.
Denen soll ich nun also von Anfang an ein Hosting und nen Wartungsvertrag bei mir aufs Auge drücken, damit ich denen dauerhaft regelmäßig Kohle für eine Leistung aus dem Kreuz leiern kann, die sie eigentlich nicht zwingend bräuchten? Nein, lass mal. Das bindet meinerseits zuviel Ressourcen die ich lieber für spannendere ongoing Projects investieren möchte.

MIr ist nun auch nicht klar geworden wie du das Problem aller Drupaler damit lösen willst jedem zu einem VPS zu raten. Es sind nunmal die wenigsten in der Lage ein solches System sicher zu betreiben und die Möglichkeiten zu nutzen, was soll es ihnen also bringen? Ich brauche als alleinstehender armer Student, der 500 Meter von der Uni entfernt im Wohnheim wohnt auch keinen 7sitzigen Van mit 3 Liter Maschine.

Könnte es sein, dass du unter "Shared Hosting", "läuft auf einem meiner Server und unter meiner Kontrolle" verstehst, während ich von "läuft bei Strato und entzieht sich meiner Kontrolle" rede?

Kann Alexander nur beipflichten. Freilich gibt es einige Ramsch-Angebote im shared Bereich und so bald eine Seite ein paar Module mehr oder man Pech hat mit den Nachbarn auf dem Server kann es eng werden aber der Sicherheitsaspekt zählt eher nicht. Große Anbieter wir 1und1, Strato oder Hetzner haben einen besch... Support aber auch genug schlaue Sysadmins die im Hintergrund arbeiten. Denen passieren Anfängerfehler durch die Hacks einfach möglich werden deutlich weniger wahrscheinlich wie dem Freizeitadmin der auch mal ein Sicherheitsupdate verschläft, gerade keine Zeit dazu hat, im Urlaub ist oder halt mal einen Fehler macht. Die Kernprozesse funktionieren bei den großen hostern, da kann man sich darauf verlassen.

Bis jetzt habe ich nur einmal erlebt, dass der Server eines Hosters gehacked wurde und das war bei einem eher kleinen bis mittelgroßen Billig-Ramsch-Hoster. Dagegen habe ich mehrfach erlebt, dass einzelne Admins Fehler unterlaufen sind oder sie unsauber gearbeitet haben.

Auch Performance ist nicht wirklich ein stichhaltiges Argument. Ich habe z:B. einen kleinen vServer zum testen von Software bei Hosteurope und die Performance ist teilweise schlechter wie bei anderen einfachen shared hosting Accounts.

Kurz: Mit jeder Pauschalisierung begibt man sich auf dünnes Eis.

btw: Falls jm. Interesse an einem HostEurope root-Server mit Vertragslaufzeit bis zum 22.9. hat bitte persönlich bei mir melden. Ich habe nach einem Server-Umzug einen kaum genutzten Server da stehen der günstig abzugeben ist. (Xeon Dual Core E3110 (2 x 3,00 GHz), 2.048 MB RAM, 1 x 160 GB SATA HDD, 5.000 GB Traffic)

ps: Hmm ich fürchte jetzt haben wir den Thread langsam vollends ins OT getrieben O_o

Nein.

Bekräftigend möchte ich einwerfen, dass es auch Shared Hosting gibt, das auf Drupal optimiert ist. Die Eignung für vernünftigen Drupal-Einsatz finde ich ein deutlich besseres Kriterium für Qualität als das Auftauchen eines root-Zugangs in der Featureliste.

Beste Grüße,
Jochen