| Author |
Message |
kayf
Donator

Joined: 29 May 2009
Posts: 189

|
Posted:
2009-06-25, 14:40 erreichen von Max_LogSize: Log verkleinern NICHT löschen |
  |
Mein Log hat gestern das erste mal die max. Grösse (von mir eingestellt) erreicht. Es wurde also gelöscht und neu angelegt.
Ich hätte lieber, das das Log entsprechend gekürzt wird. Es also nach Erreichen der MaxSize immer - ungefähr - diese Grösse behält.
Hab dazu auch mal was - zugegeben einfaches - vorbereitet: Für den Crondump jedenfalls.
In Crondump.pl
if (-e $completelogdatei) {
$logsize=(stat($completelogdatei))[7];
# unlink($completelogdatei) if($logsize + length($print_out)>$log_maxsize && $log_maxsize>0);
######################## kürzen der completelogdatei auf - ungefähr - log_maxsize
if($logsize + length($print_out)>$log_maxsize && $log_maxsize>0) {
my $ShrinkAbout = abs(($log_maxsize - length($print_out)) - $logsize);
open(DATEI,">>$completelogdatei") || err_trap('can\'t open mysqldump_perl.complete.log ('.$completelogdatei.').');
while ($OldLog = <DATEI> ) {
if ( $SkipOldLog <= 0 ) {
$OldLog4NewLog .= $OldLog;
}
else {
if ( ($SkippedByte += length($OldLog)) >= $ShrinkAbout ) {
$SkipOldLog = 0;
}
}
}
close(DATEI)|| err_trap('can\'t close mysqldump_perl.complete.log ('.$completelogdatei.').');
unlink($completelogdatei);
$print_out = $OldLog4NewLog.$print_out;
}
########################
}
my $output=$print_out;
zwischen den Rauten ist mein Code. Habs jetzt nicht in der crondump.pl probiert (war mir zu umständlich) sondern nur den code ansich.
@DSB kannst ja mal schauen, ob dir das gefällt und evtl. einbauen.
|
|
  |
 |
Anzeigen
|
Posted:
Anzeigen |
 |
|
| |
 |
JayD
Moderator


Age: 50
Joined: 12 Apr 2009
Posts: 1017
Location: Ruhrgebiet

|
Posted:
2009-06-25, 18:21 (No subject) |
  |
Die Größe der Logfiles kannst Du doch recht großzügig einstellen, da wird auch nichts gelöscht.
Ich lösche meine allerdings regelmäßig manuell, die Logs von vor 1 Woche braucht man im Regelfall ja eh nicht mehr.
Die Kontrolle per Mail funktioniert ja einwandfrei, sofern man vom Hoster ebenfalls eine Cron-Mail mit kompl. Log bekommt.
Ansonsten gibt es auch noch die "Kurzform" der Logdatei, wenn einem das Andere zu viel/groß wird.
_________________ Gruß,
Jörg
Anfragen zu vBulletin, welche nichts mit Datenbanken bzw. dem Dumper zu tun haben, bitte nicht hier sondern im vBulletin-Support-Forum stellen.
Aus technischen Gründen befindet sich der Rest der Signatur auf der Rückseite dieses Beitrags.
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16067
Location: Reichenberg bei Würzburg

|
Posted:
2009-06-25, 20:14 (No subject) |
  |
Ich kann kay schon verstehen und werde mir das gerne ansehen.
Ich habe dabei nur Sorge, dass das partielle Löschen des Logfiles, damit es neue Zeilen aufnehmen kann, bei großen Datenbanken dazu führt, dass die Performance herunter gezogen wird.
Das muss ich intensiv testen.
Zuerst einmal aber herzlichen Dank für den konreten technischen Ansatz - sogar mit Code.
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
kayf
Donator

Joined: 29 May 2009
Posts: 189

|
Posted:
2009-06-25, 21:15 (No subject) |
  |
zugegeben, die while schleife mit dem zeilenweisen 'kopieren' in die variable ist nicht schön. gibt's bestimmt noch irgendwelche seek funktionen in perl. muss ich morgen mal schauen.
dann kann man bestimmt einfach n bestimmte anzahl byte überspringen dann noch ans ende der ge'seekten' zeile. und den rest evtl. per type oder so in die var schreiben....
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16067
Location: Reichenberg bei Würzburg

|
Posted:
2009-06-25, 21:33 (No subject) |
  |
Leider gibt es keinen Befehl, der hinten eine Zeile anfügt und vorne eine Zeile aus der Datei rauslöscht.
Man kommt deshalb nicht drumrum den bisherigen Inhalt der Datei kompett einzulesen, gezielt vorne zu löschen, hinten die neue Information anzufügen, die vorhandene Logdatei zu löschen und anschließend alles wieder als neue Komplettdatei zu speichern. Und das alles bei jedem einzelnen Logeintrag.
Deshalb habe ich es ja so gelöst, wie es momentan der Fall ist. Jetzt werden einfach nur neue Zeilen ans Ende angefügt (dafür gibt es die Möglichkeit eine Datei zu öffnen und den Dateizeiger an das Ende zu setzen) und wenn die Maximalgröße erreicht wird, wird die Datei einfach komplett gelöscht und neu angelegt. Das ist schnell und belastet weder den Arbeitsspeicher noch dauert das lange.
Bei der Methode mit dem "vorne weg und hinten dran" muss für jede einzelne Zeile die komplette Datei gelesen werden. Deshalb meine Angst, dass das unperformant ist. Hier muss ebenso eine sichere Fehlerbehandlung implementiert werden, damit man sich auf die Angaben im Log verlassen kann (Dieses muss schließlich gerade im Fehlerfall Aufschluß geben können und deshalb unmißverständlich zu 100% funktionieren!). So trivial ist das alles nicht.
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
kayf
Donator

Joined: 29 May 2009
Posts: 189

|
Posted:
2009-06-25, 22:00 (No subject) |
  |
ja, ich weiss. hab beruflich auch mit programmierung zu tun. allerdings ist die performance meiner perl scripte nicht ganz so wichtig. ob das nun 30 oder 31min läuft, ist meist egal.
aber:
http://www.hidemail.de/blog/seek-perl.shtml
http://www.hidemail.de/blog/read-perl.shtml
scheint mir so, als ob man für den 'start'-wert nur noch das ende der zeile gehen muss, in die man gerade gesprungen ist.
und so hat man mit zwei,drei funktionen das alte log file ohne ein paar byte von vorne in nem scalar stehen.
aber wie gesagt, um performance musste ich mich noch nie wirklich kümmern
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16067
Location: Reichenberg bei Würzburg

|
Posted:
2009-06-25, 22:14 (No subject) |
  |
« kayf » wrote: aber wie gesagt, um performance musste ich mich noch nie wirklich kümmern
Ich schon.
MySQLDumper soll auf dem langsamsten Hoster der Welt genau so zuverlässig laufen, wie auf einem Top-Webspace.
Ebenso läuft MySQLDumper unabhängig von der PHP- oder MySQL-Version und den Konfigurationseinstellungen des Servers. MSD funktioniert unter safe_mode ebenso wie ohne, regelt alles, was Limits von Post-, Filesize oder Timeouts anbelangt selbstständig oder gibt unmißverständliche Meldungen aus, wenn etwas nicht automatisch geregelt werden kann. Von der korrekten Zeichensatzbehandlung rede ich jetzt erst gar nicht.
Oder nimm die Dateibehandlung - Du kannst aus einer GZ-komprimierten Datei die Wiederherstellung eines riesigen Backups starten, ohne, dass die Datei auf dem Server entpackt werden muss und damit die Gefahr bestünde, dass dadurch der maximale Speicherplatz gesprengt würde.
Der Dumper hat im Detail eine ganze Reihe von durchdachten Lösungen zu bieten, von denen der Otto-Normal-Verbraucher nichts mitbekommt, außer, dass es schlichtweg funktioniert.
Das soll ja auch so bleiben. Das immer so zu programmieren, dass das klappt ist eine der größten Herausforderungen. Und ich versuche natürlich jeden Engpass von vorneherein zu entdecken und zu vermeiden, damit es so bleibt, dass MSD überall problemlos läuft.
Und das Einlesen eines Logfiles, dessen Größe durch den Anwender selbst eingestellt werden kann, ist ganz klar eine potentielle Falle für das Sprengen des Speichervolumens. Was ist wenn der Anwender 100 MB als Größe für das Logfile angibt, Perl aber nur 64 MB Speicher zur Verfügung gestellt bekommt. Dann ists schon Essig mit dem Einlesen der kompletten Logdatei in den Arbeitsspeicher, Du erhältst einen "internal server error" und wenn die User damit hier im Forum aufschlagen, hast Du keinerlei Anhaltspunkt was eigentlich das Problem verursacht hat.
Und dann?
Wenn Du glaubst, dass das niemand machen würde (100 MB Logfilegröße) weil es unlogsisch erscheint, dann kann ich Dir aus meiner nun 6-jährigen Erfahrung sagen: "Alles, was man falsch einstellen kann und nicht durch das Programm abgefangen wird, kann und wird mit 100%iger Sicherheit von mindestens einem - meistens mehreren- Anwendern falsch eingestellt werden!"
Anschließend darf ich das dann hier geduldig supporten und darf dabei niemals sagen "Du Trottel! Verstehst Du eigentlich ansatzweise was Du da tust, Du Admin?"
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
JayD
Moderator


Age: 50
Joined: 12 Apr 2009
Posts: 1017
Location: Ruhrgebiet

|
Posted:
2009-06-25, 23:05 (No subject) |
  |
Das leidige Thema... (Foren) Software kaufen, irgendwie auf den Server bekommen und sich ab da dann "Admin" schimpfen, obwohl man bis dahin mit Ach und Krach wusste wo der PC eingeschaltet wird.
Das (leidige) tägliche Geschäft im Support...aber da muß man halt durch...
Ich habe in einem Supportforum mal eine Umfrage bezgl. "Was muß/sollte ein Admin an Wissen/Können/Voraussetzungen mitbringen?" gestartet.
Mit interessantem Ergebnis...
Wenn eine Software nicht "mitdenkt", sind die Fragen & Probleme vieler s.g. "Admins" am ersten Tag vorprogrammiert....
_________________ Gruß,
Jörg
Anfragen zu vBulletin, welche nichts mit Datenbanken bzw. dem Dumper zu tun haben, bitte nicht hier sondern im vBulletin-Support-Forum stellen.
Aus technischen Gründen befindet sich der Rest der Signatur auf der Rückseite dieses Beitrags.
|
|
  |
 |
DSB
Developer


Age: 41
Joined: 30 Apr 2004
Posts: 16067
Location: Reichenberg bei Würzburg

|
Posted:
2009-06-25, 23:15 (No subject) |
  |
Mein Ziel war jetzt nicht Anwender zu verunglimpfen, sondern Kay zu zeigen, wie tiefgehend und weitsichtig die Konzepte im Dumper durchdacht werden müssen, damit sie auf allen Servern in allen Konfigurationen funktionieren.
Der letzte Absatz war dazu da, zu verdeutlichen, welcher Folgen es hat wenn man anschließend den Support dafür leisten muss und wie schwer das wird wenn man keinen technischen Anhaltspunkt hat.
Ok, beim letzten Satz meines Postings bin ich etwas sehr drastisch geworden, aber das ist meine Art wenn ich Zusammenhänge klar darstellen will.
Eigentlich wollte ich sagen: "Ja, das ist so möglich, aber es bedeutet eine mögliche Fehlerquelle, die ich gerne vermeiden möchte."
_________________ Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
    |
 |
kayf
Donator

Joined: 29 May 2009
Posts: 189

|
Posted:
2009-06-26, 08:46 (No subject) |
  |
okay, da haste recht. an so grosse logfiles hab ich nun wirklich nicht gedacht.
dafür ist mein ansatz natürlich NICHT zu gebrauchen.
|
|
  |
 |
JayD
Moderator


Age: 50
Joined: 12 Apr 2009
Posts: 1017
Location: Ruhrgebiet

|
Posted:
2009-06-26, 19:56 (No subject) |
  |
Aber Du hast ja Recht damit, leider ist es ja oft so "drastisch".
Um Verunglimpfung geht's sicher nicht, allerdings wäre manchmal tatsächlich eine Art "Sachkunde-Nachweis" ganz sinnvoll und wünschenswert, bevor sich Jemand "Admin" nennen darf bzw. eine komplexe eigene Sache aufzieht.
Nicht zuletzt zu seinem eigenen Schutz (und dem der User), aber auch aus rechtlicher Hinsicht usw usw..
Ist nicht böse gemeint, tut aber trotzdem Not. Wenn ich allein in allen möglichen Supportforen ständig gepostete DB-Zugänge (wohlgemerkt, diese enthalten auch User-Daten!) sowie Mail-Adressen etc. sehe und wie sorglos "Admin" damit umgeht, wird mir regelmäßig ganz schlecht.
Unter diesem Wissen ist es nur mehr als angesagt, eine Software für User (Admins) so idiotensicher/wasserdicht wie nur irgend möglich zu machen.
Ich kann aus eigener Erfahrung nur sagen, dass man dabei wirklich an JEDEN Sche** denken und jede noch so dumme Möglichkeit in Betracht ziehen muß.... (leider)...
_________________ Gruß,
Jörg
Anfragen zu vBulletin, welche nichts mit Datenbanken bzw. dem Dumper zu tun haben, bitte nicht hier sondern im vBulletin-Support-Forum stellen.
Aus technischen Gründen befindet sich der Rest der Signatur auf der Rückseite dieses Beitrags.
|
|
  |
 |
|
|
CrackerTracker © 2004 - 2012 CBACK.de
Powered by Orion based on phpBB
© 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours
phpBB SEO
|