mySQL rödelt sich auf der HD tot

Diskutiere mit über: mySQL rödelt sich auf der HD tot im Datenbanksysteme für das Web Forum

  1. lupusoft

    lupusoft Thread Starter MacUser Mitglied

    Beiträge:
    250
    Zustimmungen:
    4
    Registriert seit:
    05.01.2004
    Moin,

    ich habe mySQL 4.0.21 auf einem Dual G5/1.8GHz unter Panther 10.3.5 laufen. Die Datenbank ist von der Anzahl der Datensätze her gesehen nicht besonders gross (die grösste Tabelle hat ca. 12000 rows), allerdings gibt es eine Tabelle mit ca. 1500 Datensätzen, die in einem blob Feld gezippte Dateien zwischen 500k und 6MB enthalten. Bei anfänglich durchaus akzeptabler Geschwindigkeit (entweder direkte SQL Anfragen oder über PHP), bricht mir der mysqld mittlerweile ziemlich zusammen. Ich habe versucht, einige Pufferwerte hochzusetzen, aber letztendlich kommt er offensichtlich nicht mit der Grösse der Datensätze zurecht. Wenn ich mir das Verhältnis von gelesenen zu geschriebenen Dateien anschaue, dann liege ich derzeit bei 1.8 Terabyte (!!!) zu 12 Gigabyte. Für mich ein deutliches Zeichen, dass er zuviel über die Platte arbeitet. Wenn ich das richtig interpretiere, dann liegt es weniger am Swappen (394943 pageins und 787265 pageouts), als daran, dass er die nicht die kompletten Tabellen ins RAM bekommt. Insgesamt hat die Bank eine Grösse von ca. 1.3 GB, der Mac hat 1.2 GB RAM. Virtuell hat mysqld 1.06 GB Speicher, bei 100 bis 200 MB physikalischem RAM.
    Was kann ich tun, um die Bank wieder flotter zu machen. Momentan ist es wirklich inakzeptabel; über das Webinterface dauert ein select query mittlerweile 1 bis 3 Minuten. Das kann es doch nicht sein, oder? mySQL sollte in der Lage sein Millionen von Datensätzen ohne Probleme zu handeln. Ist die MacOSX Implementation schlechter als bei anderen Platformen? Gibt es eigentlich eine Möglichkeit (oh, oh jetzt kommt die dumme Unix-Nichtwisser-Frage), bestimmten Programmen mehr physikalischen Speicher fest zuzuordnen. Da liegen über 800 MB RAM rum, die top als "inactive" markiert. Oder ist die einzige Chance, noch mehr RAM in den Rechner zu stopfen?

    Danke für eure Vorschläge, Lupus
     
  2. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.034
    Zustimmungen:
    1.314
    Registriert seit:
    13.09.2004
    @Lupus:
    Schlag mich ruhig, aber ich hab mal gelernt das man das so nicht machen soll! Zum aufbewahren von Dateien ( gezipped oder nicht) gibt es ein gutes DBMS ( das Filesystem). In die DB kommt allenfalls der Name und der Pfad dahin. Der Grund liegt einfach in Transaktionen und deren Logs, sowie Caches für Abfragen. Das DBMS muß hierzu ggf. mehrere Versionen eines BLOBs vorrätig halten. Damit killst Du jedes IDE-Plattensystem und erhältst genau den I/O von dem Du sprichst. Bei jedem JOIN, jedem GROUP,... werden zwischetabellen angelegt. Bei der BLOB-Größe in der Tat tödlich. Deshalb Dateien ins Dateisystem. Deren Verwaltung in die DB!

    So habs ich mal gelernt, mag beizeiten vielleicht andere Lösungen geben, dann möge man mich eines Besseren belehren.

    Gruß Karsten
     
  3. lupusoft

    lupusoft Thread Starter MacUser Mitglied

    Beiträge:
    250
    Zustimmungen:
    4
    Registriert seit:
    05.01.2004
    Hallo Karsten,
    Nicht doch, du hast ja vollkommen recht, ABER ich mache das nicht wirklich freiwillig. Das Problem ist folgendes: der XAMP (oder wie sagt man bei OSX?) Server liegt in einer DMZ, die sowohl von aussen, als auch von dem Firmen-LAN wo ich gerade arbeite, nur über ein Portfenster von 9000 bis 9010 erreichbar ist. Das bedeutet u.a., dass ich keine Möglichkeit habe vom LAN aus über FileSharing an die Platte des Servers zu kommen, um die ZIP Dateien direkt auf den Server zu legen. Andersherum hat natürlich auch der XAMP-Server keinerlei Zugriff auf das LAN. Ich weiss, dass ich theoretisch über ssh und eine Port-Umleitung doch an den AFP-Server vom G5 drankommen würde, aber das setzt auf der LAN-Seite ebenfalls OSX (oder was anderes mit X drinne) voraus. Die Clients im LAN, die den Server füttern, müssen aber alle unter OS9 laufen(proprietäre SW, das alte Problem). Also habe ich einen OS9 mySQL Client geschrieben, der den mysqld direkt auf einem 9000er port kontaktiert und die Daten rüberschiebt. Das ist natürlich alles suboptimal (ganz zu schweigen davon, welche Hürden ich bei der Programmierung des OS9 Clients nehmen musste), aber ich habe momentan keine andere Möglichkeit (naja, ich könnte natürlich eine FW-Platte nehmen und hin und herstöpseln, aber das ist nicht machbar).

    Naja, einerseits beruhigend zu hören, dass das "normal" ist, dass mein G5 so langsam aber sicher abschmiert, aber andererseits gibt es doch die blobs, und die sind genau für den Zweck vorgesehen, dass man da "dicke Dinger" reinpackt. Wie laufen denn Banken, die grosse Bilderarchive oder ähnliches verwalten? Haben die alle RAIDs dranhängen, damit es flüssig bleibt?
    Ich hab jedenfalls erstmal 2 zusätzliche Gigabyte RAM bestellt und hoffe, dass es damit besser geht. Hat sonst noch jemand Erfahrungen mit BLOB-Banken gemacht? Ich bin ein wenig unter Druck, weil der Server täglich von zig Kunden besucht wird, die ihre zip Files haben wollen...

    Gruss, Lupus
     
  4. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.034
    Zustimmungen:
    1.314
    Registriert seit:
    13.09.2004
    Mit sowas kriegst Du auch einen G6 mit 8GHz klein. RAM hilft...um das Problem zu verschieben, nicht um es zu lösen. Dein Problem habe ich verstanden (und beneide Dich nicht :D), ich kenne jedoch OS9 nicht (Macuser since 10/2004). Allerdings drängt sich mir eine ganz blöde Frage auf:

    Upload/Download würde ich über FTP/HTP realisieren. Kann man nicht einen Webserver auf einen der Ports laufen lassen (Innen wie aussen) und dort via FTP über HTTP Dateien uploaden? Dann könntest Du die mit PHP in ein Filesystem sortieren und deren Pfade in mysql verwalten um dynamische Angebotsseiten für die Kunden zu erstellen. Das wäre mein Ansatz gewesen. Um Deinen BLOB-Harddiskstreßtest vernünftig zu realiseren, braucht es Plattensysteme. Am Besten Raidcontroller mit ordentlich RAM drauf und nem RAID 0 oder 10. Dann hast Du eine reelle Chance.
     
  5. lupusoft

    lupusoft Thread Starter MacUser Mitglied

    Beiträge:
    250
    Zustimmungen:
    4
    Registriert seit:
    05.01.2004
    Moin,
    puh, habe mir eine kleine Verschnaufspause verschafft, indem ich heute morgen die beiden Gig-Riegel eingebaut habe. Läuft jetzt wieder einigermassen akzeptabel, aber wie du schon sagst, wird es wohl nur eine Frage der Zeit sein..
    Tja, und ich komme genau von der anderen Seite, sprich fühle mich ziemlich fit auf dem alten MacOS und programmiere halt auch semi-professionell dafür. So hat alles angefangen, ein paar Programme für die Firma, die den täglichen work-flow automatisieren: Ergebnisse analysieren, Bewertungen setzen, ein paar Kundendaten aus der FileMaker Bank ziehen, ein paar Dateien komprimieren, emails generieren, attachments reinhängen und abschicken. Alles "at the ease of a click" sozusagen. Das lief auch lange Zeit gut, bis die Auslieferungen der zips über email langsam ins Stocken geriet (Stichwort Spamfilter). Also musste ein Datenbanksystem für die passive "Auslieferung" der Kundendateien her, am besten gleich gepaart mit online-Bestellung etc. Naja, nach kurzem Zögern und ein paar Versuchen auf OS9 war klar, dass ich da nur mit OSX weiterkommen würde, wenn ich nicht jede Menge Räder neu erfinden wollte. Aber trotzdem muss es halt von den OS9 Rechnern im LAN aus mit ein paar Klicks funktionieren.
    OK, danke erstmal fürs Mitdenken. Was den zusätzlichen Webserver angeht, kann man das wohl mit virtuellen Hosts in Apache regeln, oder? Da hab ich mich aber noch nicht wirkich mit auseinandergesetzt. Aber der schwierigere Teil ist sicher das Sortieren mit PHP. Ich muss dazu sagen, dass ich nicht wirklich firm in PHP bin. Die jetzigen PHP-Seiten wurden von einem externen Fachmann erstellt (der übrigens witzigerweise Karsten heisst), halt mit HTML-templates und allen Schikanen. Da kann ich nicht wirklich mitreden, aber die PHP-Sortierungsgeschichte könnte ich ja auch wieder abgeben. Was mir mehr Kopfzerbrechen bereitet, ist die Frage, wie ich diesen Weg von den OS9 Rechnern aus beschreite. Wenn die Leute im Büro jetzt irgendwas "per Hand" machen müssen, gibts ne Meuterei. Also via Browser die Dateien hochladen fällt aus. Alternativ könnte ich natürlich einen handgestrickten http-client in meine Programme einbauen, aber da hab ich dann den ganzen http Protokoll Overhead drin. Also wird es wohl auf eine proprietäre Lösung hinauslaufen, sprich ein OSX Programm, das die zips entgegennimmt, in Ordner schiebt und den Pfad in die Bank schreibt. Das wird wieder Neuland für mich, selbst wenn es "nur" eine Carbon App wird.
    Jedenfalls danke für deine Hilfe, Lupus
     
  6. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.034
    Zustimmungen:
    1.314
    Registriert seit:
    13.09.2004
    @Lupus:
    Eije das klingt verzwickt. Aber keine Angst vor PHP! It's almost like C!
    Vergiß einfach alle Variablen-Typen und geh von einem C-Interpreter ( zugegeben mit einigen Eigenheiten) aus. Ich benutze PHP fast als einzige Scriptsprache um meine LINUXe zu verwalten, alltägliche Abläufe per Cron zu erledigen...
    Ist halt soviel lesbarer als Perl. Gut es ist nicht so schnell, aber wen störts bei derartigen Anwendungen. Den Internen und Externen Apache würd ich allein aus Sicherheitsgründen trennen. Zumal ja auch jeder auf eine andere Netzwerkkarte gebunden werden müßte...

    SoSo, Dateiupload per Browser überfordert User. Ich wußte nicht das wir in der gleichen Firma arbeiten und hab hier auch noch keinen Mac gesehen :D
     
  7. norbi

    norbi MacUser Mitglied

    Beiträge:
    3.506
    Zustimmungen:
    22
    Registriert seit:
    14.01.2003
    hab' zwar keine Ahnung von SQL, aber:
    wieso lagerst Du die Suchfelder für die Blobs nicht in eine eigene Tabelle aus. Wird in dieser schlanken Tabelle ein DS gefunden, braucht nur noch das EINE Blob in der Blob-Tabelle geladen werden.

    So isses gemeint:
    Tabelle1 - zum Suchen:
    - Index
    - Dateiname
    - Änderungsdatum
    - Dateityp
    - Dateigröße
    - ...
    Tabelle2 - mit den Blobs:
    - Index Tabelle 1
    - Blob

    Ich selbst hatte das ganze mal (in "4D") so gelöst, daß ich die Tabelle mit den Blobs nochmal aufgeteilt hatte, auf eine weitere Tabelle mit etwa 100 k großen Blobs pro DS. Beim Import und Export wurde die Datei in Stücken von der HD geladen bzw. in Stücken auf die HD geschrieben. Selbst mit 10 MB-Dateien war das auf einem Centris 660 AV (25 Mhz!, 64 MB RAM) kein Problem - und flott.

    No.
     
  8. lupusoft

    lupusoft Thread Starter MacUser Mitglied

    Beiträge:
    250
    Zustimmungen:
    4
    Registriert seit:
    05.01.2004
    Höhö, da kann ich dich gleich weiterleiten an die Leute nebenan. Wenn mein Programm 6000 Adressdaten aus der internen FileMaker Bank nach dem gewünschten Kunden durchsucht, 40 neue Records in 3 verschiedenen Tabellen der mySQL Bank für den Auftrag anlegt, anschliessend automatisch eine email mit den Auftragsdaten in Eudora erzeugt und dafür satte 7 Sekunden braucht, gibt es schon nervöses Fingertrommeln auf der Maus. Soviel dazu... :rolleyes:
    OK, hab dich falsch verstanden; ich dachte an einen weiteren httpd, der auf einem anderen Port der "externen" Karte läuft. In Gänsefüsschen, weil die Sache ja noch viel paranoider ist, als man sich (zumindest ich mir) vorstellen würde. Der Haus-Provider, an den wir gebunden sind, ist schon fast eine Behörde für Internetsicherheit. Vom Provider/Internet aus gesehen sitzt das das gesamte Gebäude mit einem dutzend Firmen hinter der ersten firewall, die eigentlich von aussen schon fast alles dicht macht. Von dieser ersten firewall geht es auf die zweite firewall, die hier in der Firma steht. Letzteres ist eine DOSe mit Suse und 3 Netzwerkkarten, eine "externe", eine fürs LAN (192.168.101.x) und die dritte für die DMZ (192.168.102.x). Das bedeutet, dass der G5 seine IP-Existenz quasi über reines port-mapping bezieht. Ich kann vom G5 aus ja nicht mal über irgendwelche ports nach "draussen" gehen, da alle anderen ports ausser 9000-9010 technisch gesehen zum LAN Interface gehören). Ironischerweise kann ich mir also nicht mal die Sicherheitsupdates von Apple runterladen. Diese Leute sind vollkommen phobisch und eine zweite Netzwerkkarte am G5, mit der ich wieder ins LAN gehe, wäre ja wieder die Umgehung der physikalischen Trennung. Ausserdem wäre das ja über Umwege auch das gleiche, als wenn ich die offenen ports direkt zu einem LAN-Rechner mappe. Da bekommt der Provider wieder Herzattacken und redet gleich von Haftungsausschluss und Schadensklagen in Millionenhöhe, die Dritten durch eingeschleuste Viren enstehen könnten, und da werden die Chefs natürlich weicheierig und wollen das auch nicht. Lustig ist auch, dass sie z.B. die Time-Server Abfragen der Macs blocken, weil das ja ein Sicherheitsrisiko darstellt. Und als ich den G5 Server dann in Betrieb genommen habe, hagelte es gleich Anrufe von erzürnten Kunden, die nicht auf die Seiten kamen. Da musste ich mich dann auch noch mit deren Sysadmins rumschlagen, damit die wiederum ihre firewalls für den rausgehenden port 9003 freischalten. Haha, manchmal weiss ich wirklich nicht, ob ich lachen oder weinen soll.
    Naja, ich komm ins Schwätzen. Muss aufpassen, dass ich nicht selbst zum Sicherheitsrisiko werde ;)
    Sei froh, dass ihr noch keine Macs habt, sonst erwarten die Leute bald, dass alles sprachgesteuert funktioniert
    :D
    Mmhja, darüber nachgedacht hab ich auch schon, könnte mir aber vorstellen, dass es nicht soviel bringt. Wenn ich mir die Tabelle mit zip-blobs anschaue, dann hab ich ca. 10 kleine Felder (varchar, int) mit Auftrags-spezifischen Sachen wie Datum Eingang/Ausgang, Kundennummer, mail-Adresse, ID (als primary key) etc. und halt das dicke binary blob Feld. Die kleinen Felder machen also kaum Raum aus. So wie ich es verstanden habe (und es ist nicht unwahrscheinlich, dass ich es nicht verstanden habe) läuft der Zugriff sowieso über die Index Tabellen, die MyISAM anlegt. Die Indices werden nicht dadurch kleiner, dass ich die blobs von den übrigen Daten trenne, im Gegenteil brauche ich einen weiteren Index. Die key index caches hab ich schon raufgesetzt, da kommt nix mehr an Geschwindigkeit. Es könnte was bringen bei Volltextsuchen, aber das passiert eigentlich nicht. Alle select und update queries beziehen sich auf ints, die gleichzeitig als key Werte benutzt werden (z.B. loggen sich die Kunden mit ihrer Kundennummer ein, die wiederum im primary key Feld stehen. Aufträge haben eine unique ID als prim. key und die Kundennummer als secondary key usw.). Wie nun aber InnoDB die Datensätze handelt, weiss ich natürlich nicht. Da lasse ich mich sehr gerne belehren, ob es was bringt, die zips in eine separate Tabelle zu verfrachten.
     
  9. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.034
    Zustimmungen:
    1.314
    Registriert seit:
    13.09.2004
    Hey wir arbeiten doch in der gleichen Firma! Aber im Ernst, so was geht in PHP ( und auch schneller als in 7 Sekunden) ohne Probleme. Ich meinte nur perl sei schneller bei administrativen Dingen ( String und Fileoperationen). Aus Gründen der Wart- uns Lesbarkeit nehm ich dafür auch nur noch PHP. Der Normalisierungsvorschlag von Norbi ist aufgrund der Speichergöße der Blobs wohl ohnehin ein Muß!

    Was Deine Admins angeht so ists brav ( so ists auch bei uns!)! Außer nat. den Port für Zeitserver, das ist in der Tat etwas übertrieben...
     
  10. lupusoft

    lupusoft Thread Starter MacUser Mitglied

    Beiträge:
    250
    Zustimmungen:
    4
    Registriert seit:
    05.01.2004
    Nee, die Angaben waren für mein selbstgebasteltes Programm auf einen alten G3 mit OS 8.6, der übers Netz mit dem mysqld redet. Ich weiss gar nicht, ob es überhaupt ein PHP für Classic gibt, und wenn, dann nur "Künstlich" draufgesetzt.
    Öh, versteh ich nicht. Die Definition heisst doch Ein Relationstyp ist in der 1. Normalform, wenn alle Attribute maximal einen Wert haben. Das ist doch bei mir der Fall; jedes zip gehört zu genau einem Auftrag. Kannste das nochmal erläutern?
    Tja, da kann man natürlich endlos dikutieren, wo der Kompromiss zwischen Sicherheit und Nutzbarkeit des Systems ist. Wenn wir hier ne Horde Windoof Rechner rumstehen hätten, wäre ich ja einsichtig, aber bei den ganzen Klimmzügen, die ich unternehmen muss, um an meinen eigenen Server zu gelangen, würde ich sagen, es wäre weniger zeitintensiv, den Server nach jeder Hackerattacke neu einzurichten. ;)
     
Die Seite wird geladen...
Ähnliche Themen - mySQL rödelt auf Forum Datum
SQL: Join auf Basis eines Start- und Endwerts aus der gejointen Tabelle Datenbanksysteme für das Web 02.09.2016
Mysql - Duplicates abfangen, mit php oder mit unique keys? Datenbanksysteme für das Web 08.03.2016
Mamp & Joomla auf localhost installation funktioniert nicht Datenbanksysteme für das Web 03.03.2016
mysql abfrage optimieren Datenbanksysteme für das Web 26.03.2014
php - mysql_error != mysqli_error - mysql meldet Fehler, mysqli nicht Datenbanksysteme für das Web 05.07.2013

Diese Seite empfehlen

Benutzerdefinierte Suche