Organisatorisches Problem: Speicherplatz

[Anitram]

Ich habe ein ganz "profanes" Problem, nämlich ein Speicherproblem!

Mein Weblog (mit der selben Datenbank!) läuft inzwischen schon zwei Jahre. Mittlerweile haben sich, neben den s9y-Installationsdateien, rund 179 MB Daten (Texte, Bilder, Kommentare usw. ) angesammelt. Mein gebuchter Speicher beträgt aber nur 200MB.

Nun habe ich die Möglichkeit, auf 500MB hochzugehen oder aber zu löschen. Ich will aber weder das eine noch das andere machen. Wer von Euch stand schon einmal vor einem ähnlichen Problem? Und wenn es eine/n unter Euch gibt, wie hat er / sie es gelöst?

Ich danke Euch für Eure Hinweise.

[yellowled]

Mein Weblog (mit der selben Datenbank!) läuft inzwischen schon zwei Jahre. Mittlerweile haben sich, neben den s9y-Installationsdateien, rund 179 MB Daten (Texte, Bilder, Kommentare usw. ) angesammelt. Mein gebuchter Speicher beträgt aber nur 200MB.

Ich würde mal grob schätzen, dass der Löwenanteil davon Bilder ausmachen, die höchstwahrscheinlich in relativ "großzügigen" Formaten (sowohl Dimensionen als auch möglicherweise Dateityp) im Webspace lagern.

Erklärung, wie ich dazu komme: Mein Blog läuft ähnlich lange, belegt aber aktuell gerade mal ~50MB - ich bin sehr sparsam mit Grafiken im Blog, lagere z.B. Digicamfotos grundsätzlich zu flickr aus.

Der einzige Rat, der mir dazu einfällt: Mediendatenbank "entrümpeln", also Bilder wahlweise komplett auslagern oder eben in platzsparende Formate konvertieren bzw. ggf. massiv verkleinern. (Ja, das ist viel (Hand-)Arbeit. Ich persönlich würde mich vermutlich aus nackter Faulheit für ein Webspace-Upgrade entscheiden.)

YL

[ICE]

bringt vielleicht nicht viel, aber du kannst auch schonmal alle nicht benötigten styles aus dem /templates Verzeichnis löschen ... außer natürlich deinem verwendeten und den "default" style ...

und evtl. alle dateien aus dem "docs" verzeichnis ...
das war es dann aber und mehr als 200 bis 300 kilobyte wirst du damit nicht frei bekommen ...

Da hilft wirklich nur das entrümpeln der mediendatenbank.
Wenn Du eingefügte Digicam Bilder nicht löschen möchtest, dann mußt Du diese nachträglich noch verkleinern. In der Regel reichen für die Vollbilddarstellung von Fotos eine Auflösung von 800x600 Pixel.
Lade dazu alle Bilder aus der Mediendatenbank per FTP auf Deinen Rechner und lasse alle Bilder, die größer als die 800x600 Pixel sind, auf diese Auflösung verkleinern (mit dem gleichen Dateinamen). Lade dann alle Bilder einfach wieder in Deine Mediendatenbank zurück. Fertig.
Mit dem Programm Acdsee geht das z.B. in einem Rutsch und ist in wenigen Minuten erledigt. Vom Down- und Upload mal abgesehen.

Das ist das einzige was mir dazu einfällt.

Letzen Endes ist das nur ein verschieben des Problems auf später ...

[Anitram]

bringt vielleicht nicht viel, aber du kannst auch schonmal alle nicht benötigten styles aus dem /templates Verzeichnis löschen ... außer natürlich deinem verwendeten und den "default" style ...

Und genau den Default-Ordner hatte ich gestern abend gelöscht! Du kannst dir sicherlich meinen entsetzten Gesichtsausdruck vorstellen, als ich das Chaos im Blog sah! Aber er ist wieder online

Letzen Endes ist das nur ein verschieben des Problems auf später ...

Dem sich sicherlich irgendwann immer mehr Blogger stellen werden / müssen.

Eine Überlegung ist auch, die "alten" Beiträge in PDF umzuwandeln (ohne die dazu gehörigen Kommentare) und dann im s9y zu löschen.

Allerdings tauchen bei dieser Überlegung einige Fragen auf, die ich nicht beantworten kann:
- gibt es ein Plugin, das einzelne Beiträge in PDF umwandelt? Ich hatte nämlich nur eines gefunden, das den GESAMTEN Inhalt zu einem PDF zusammenfasst.

- Wenn ich Beiträge von mir über s9y lösche, verschwinden dann auch die dazu gehörigen Kommentare oder muss ich die vorher alle einzelnd löschen?

[garvinhicking]

Hi!

Eine Überlegung ist auch, die "alten" Beiträge in PDF umzuwandeln (ohne die dazu gehörigen Kommentare) und dann im s9y zu löschen.

Das führt nicht wirklich zu etwas. PDFs sind größer als das, was ein Beitrag in der s9y Datenbank belegt. Du würdest durch so eine Konvertierung also noch Speicherplatz verlieren, ganz abgesehen von den Durchsuchen-Features etc.

- Wenn ich Beiträge von mir über s9y lösche, verschwinden dann auch die dazu gehörigen Kommentare oder muss ich die vorher alle einzelnd löschen?

Die Kommentare verschwinden nicht, die müsste man manuell löschen.

Du kannst ja mal via phpMyAdmin deine Datenbank ansehen. Bei den meisten Providern wird nämlich die Datenbank NICHT auf deinen verfügbaren FTP Speicherplatz gerechnet. Schätzungsweise ist deine Datenbank recht klein, und dein kompletter upload/ Ordner belegt den Speicherplatz?

Dann würden nämlich alle Optimierungen an s9y zwangweise dazu führen, dass es garnichts bringt.

Auch ich würde sagen die einzige Chance die Du hast, ist deine Bilder zu löschen.

Viele Grüße,
Garvin

[Anitram]

An den Bildern liegt es nicht - die betragen insgesamt nur 19.2MB... und damit sollte man leben können.

Ich suche immer noch die Datei oder die Einträge, die dieses "Volumen" verursachen, und ich weiß nicht mehr, wo ich noch nachsehen soll.


Nachschlag:
Ich seh grad, dass in der DB es eine Tabelle mit Namen:

s9y_images gibt, die insgesamt 600 KB (66tausendirgendwas Bytes) groß ist. Was verbirgt sich dahinter? Die Bilder selbst sind doch im s9y-Pfad abgelegt.

s9y_references gibt, die 275.000 Bytes groß ist!! (Was verbirgt sich dahinter?)

s9y_suppress gibt, die einen Überhang von 1.332 Bytes hat! (Wie kann das passieren?)

s9y_visitors gibt, mit 490.000 Bytes. (Kann ich die Inhalte so einfach löschen?)

[ICE]

Sag mal ... eine Frage, wie genau setzen sich Deine 179 MB denn zusammen? Bei manchen Webhostern werden nämlich auch die eMail Postfächer zur Domain zum Webspace mit eingerechnet.

Wenn Du schreibst, dass Dein Medienordner nur 19 Megabytes hat, dann kann es eigentlich nur noch das sein. Die normalen Texteinräge des Blogs sind nämlich vernachlässigbar groß.

Ich seh grad, dass in der DB es eine Tabelle mit Namen:

s9y_images gibt, die insgesamt 600 KB (66tausendirgendwas Bytes) groß ist. Was verbirgt sich dahinter? Die Bilder selbst sind doch im s9y-Pfad abgelegt.

s9y_references gibt, die 275.000 Bytes groß ist!! (Was verbirgt sich dahinter?)

s9y_suppress gibt, die einen Überhang von 1.332 Bytes hat! (Wie kann das passieren?)

s9y_visitors gibt, mit 490.000 Bytes. (Kann ich die Inhalte so einfach löschen?)

Die bytes, die Du da aufzählst können auch nicht die 179 Megabyte erklären. denn 275.000 bytes sind ja nur 275 Kilobyte, also auch nix im Vergleich zu den 179 MB!

[Anitram]

s9y-Installation mit allen Bildern= ca. 36MB
eigentliche DB = ca. 13 MB

Ich habe mich eben mit dem Support meines Providers per E-Mail in Verbindung gesetzt und ihn gebeten, nach dem Speicherfresser zu suchen. Das Problem ist nur, dass der Speicher immer weniger wird und ich massive Panik davor habe, dass irgendwann in allernächster Zukunft nix mehr geht, weil der SPeicher voll ist.

[yellowled]

Email-Postfächer klingt nach einer verdächtig guten Idee, eine andere Möglichkeit wären Logfiles: Sowohl von s9y erzeugte wie etwa spamblock.log als auch vom Webserver erzeugte - letzteres wäre allerdings eine ziemliche Frechheit seitens des Providers ...

YL

[Anitram]

Wo finde ich diese Logfiles und wie identifiziere ich sie über ftp?

[yellowled]

Wo finde ich diese Logfiles und wie identifiziere ich sie über ftp?

Üblicherweise beinhalten sie irgendein Datumsformat im Dateinamen ("...2007-02-06...") enden auf ".log", ggf. auf "log.gz" und sie liegen gerne in einem Verzeichnis "logs" oder "logfiles". Allerdings wirst Du vermutlich keine Berechtigung haben, sie per FTP zu löschen, zumindest handhabt mein Hoster das so.

YL

[Anitram]

Ich habe die Antwort erhalten, die mir nicht so ganz gefällt. Garvin hat deshalb eben von mir Post erhalten - vielleicht weiß er ja etwas damit anzufangen.

[Anitram]

Hier der Text der Antwort:

ich hab Antwort vom Rechenzentrum:

> >Ihre Kundin verwendet unserer Meinung anch Scripte welche nur eine
> >Session öffnen, diese aber nicht mehr schließen. Dadurch sammeln sich
> >sehr schnell viele kleine Dateien an die in der Summe dann den
> >Speicherplatz "schlucken".
> >Ich habe nun alle Sessiondateien gelöscht und der Speicherplatzverbruach
> >ist auf 40MB zurück gegangen, allerdings wird dies sicher nicht lange so
> >sein. Es kommt dann auf die Besucherzahl am Tag drauf an.

Ist also wie befürchtet - irgendeins von deinen Scripten läuft Amok.
Serendipity selber denke ich können wir ausschließen, das Problem wäre schon
lange auch anderen aufgefallen. Aber vermutlich ist ein Plugin unsauber
programmiert und öffnet eine Session (da wird jedesmal eine kleine Datei in
einem speziellen Verzeichnis geschrieben, das ist das was der Techniker da
anspricht), schließt die Session aber nicht ordnungsgemäß - und die Datei
bleibt deswegen bestehen und verstopft deinen Speicherplatz.

Ich habe ein Plugin inzwischen in Verdacht, und zwar das serendipity_event_entryproperties, bei dem ich das Cachen von Artikeln zugelassen (also mit "JA" markiert) hatte, was ich aber inzwischen auf NEIN gesetzt habe. Mittlerweile habe ich auch viele Plugins gelöscht, und einige wieder "neu" aufgesetzt.

Es laufen bei mir folgende Event_plugins:
Textformatierung: Smileys
Spartacus
Browserkompatibilität
Spamschutz
Spamschutz (SURBL)
Freie Artikel Tags
Statische Seiten
Kategorien zuweisen
Passwort vergessen
Layout Plugin: Druckerfreundliche Version
Layout Plugin: Link-Formatierung
Datum der letzten Aktualisierung
Nächster/ Vorheriger Artikel
Textformatierung BBCode
Benutzerprofile
Trackbacks kontrollieren
Textformatierung: NL2BR
Erweiterte Eigenschaft von Artikeln (<-- Mein Verdächtiger wegen des Cachen von Artikeln)

Es waren ursprünglich noch einige mehr installiert, wie z.B. das PodCast-Plugin (das ich aber zur Zeit nicht brauche), Inaktiv sind zur Zeit: Tooltipps, Layout: Link-Formatierung und Link-List

Die URl meines Blogs ist: martina-kausch.de und die s9y-Version, die ich verwende, ist die allerneueste 1.1.

Betrieben mit Serendipity 1.1 und PHP 4.4.1

[garvinhicking]

Hi!

Was sessions angeht: Kein PHP-Script kann eine "Session schließen". Sessiondaten bleiben auf dem Server immer solange gespeichert, bis ein PHP-Server Prozess, genannt "Garbage Collection" (GC) ausgeführt wird und alte Sessiondateien löscht.

Das wird durch die session.gc_probability geklärt und durch session.cache_expire und session.gc_maxlifetime.

Sessiondaten sollten standardmäßig maximal 1440 Minuten alt werden, d.h. dein Sessionverzeichnis dürfte auch nur die Sessiondaten der Besucher von vor maximal 1440 Minuten auffindbar sein. Wenn die Daten dort älter wären, wäre es also eher ein Bug in der Garbage Collection oder eine zu hohe Konfiguration des Wertes.

Halte das mal im Auge ob auch nächste Woche das Verzeichnis wieder so groß geworden ist. Wenn ja, bitte deinen Provider mal die timestamps der Dateien zu checken und die Dateigröße.

Wenn Deine PHP-Installation keine Cookie-Sessions akzeptiert würde für jeden PHP-Aufruf des Blogs eine neue Session geöffnet. Normalerweise werden die nach 180 Minuten wieder gelöscht (maximal 1440) so dass man eigentlich nur einen Puffern von einigen MB benötigt.

Solltest du aber mehrere tausend parallele Besucher in der Stunde haben, würden da auch mehrere tausend Sessiondateien herumliegen...

Viele Grüße,
Garvin

[Anitram]

Stand 14:10 Uhr heute: 44,31 MB

Ich werde das mal im Auge behalten.