nicht angemeldet
1&1 MySQL-Server Auslastung?!
1 0 0
1&1 MySQL-Server Auslastung?!
StruppiHallo,
folgendes hab ich festgestellt: Hab eigentlich zum ersten Mal überhaupt bei phpMyAdmin die Serverstats für meinen im Hosting-Paket integrierten MySQL-Server aufgerufen. Und dann seh ich folgendes:
Empfangen 279 MiB 109 MiB
Gesendet 3.779 MiB 1.478 MiB
Insgesamt 4.057 MiB 1.587 MiB
Denn Server haben die scheinbar heute früh neu gestartet. Der läuft jetzt ca. 2 1/2 Stunden!
Kann das wirklich sein, so eine Auslastung? 1,5 MiB (!) in einer Stunde?
Ist das Normal? Wieviel Leute sind denn da insgesamt drauf?
Selbst bei 1000 Leuten wären das 1,5 MiB für jeden durchschnittlich. Ist da einer extrem oder wie? Soll man da mal bei 1&1 nachfragen?
Meine Seiten brauchen bei höchstens 10 KiB Daten pro Aufruf sage und schreibe teilweise über eine Minute, bis sie sich aufgebaut haben. Das kann es doch nicht sein!
Gruß,
Andy
-
Hallo Andy,
Empfangen 279 MiB 109 MiB
Gesendet 3.779 MiB 1.478 MiB
Insgesamt 4.057 MiB 1.587 MiBDenn Server haben die scheinbar heute früh neu gestartet. Der läuft jetzt ca. 2 1/2 Stunden!
Kann das wirklich sein, so eine Auslastung? 1,5 MiB (!) in einer Stunde?
Du meinst wohl eher 1500 MB je Stunde :-)
Ist das Normal? Wieviel Leute sind denn da insgesamt drauf?
Warum sollte das nicht normal sein? Das sollte kein Problem darstellen. Ein Server - gerade bei einem Massenhoster - steht nicht deswegen im Rechenzentrum, um die meiste Zeit vor sich hinzudösen. Server kosten Geld, z.B: Anschaffungskosten, Verbrauchskosten, Wartungskosten, Administrationskosten. Massenhosting ist ein knallhartes Geschäft. Bei den heutigen Hostingpreisen ist doch kaum Spielraum, um Server nur so zum Spass hinzustellen.
Was für ein Paket nutzt Du? Wieviel kostet Dich das im Monat?
Selbst bei 1000 Leuten wären das 1,5 MiB für jeden durchschnittlich. Ist da einer extrem oder wie? Soll man da mal bei 1&1 nachfragen?
Sieht doch bisher nicht nach einem Problem aus, außer ...
Meine Seiten brauchen bei höchstens 10 KiB Daten pro Aufruf sage und schreibe teilweise über eine Minute, bis sie sich aufgebaut haben. Das kann es doch nicht sein!
bei Dir. 10 KB kann man einfach und aufwendig abrufen. Die reine Menge sagt wenig aus. Hast Du Deine Queries mal mit EXPLAIN getestet?
Möglicherweise sind Deine Queries optimierbar. Vielleicht begehst Du ja auch einen Fehler (der oft von Anfängern gemacht wird) - und fragst in einer Schleife die Datenbank wiederholt ab, statt die Daten auf einmal abzurufen. Vielleicht nutzt Du sogar die API um einen einfachen
JOINzu realisieren. Vielleicht gehst Du ähnlich wie Daniel vor, vielleicht begehst Du einen Fehler wie MiSo, ...Es gibt viele Möglichkeiten, etwas falsch zu machen. Eine Ferndiagnose allein aufgrund der Datenmenge ist ungefähr so zuverlässig wie Lesen im Kaffeesatz.
Freundliche Grüße
Vinzenz
-
Hallo!
Kann das wirklich sein, so eine Auslastung? 1,5 MiB (!) in einer Stunde?
Du meinst wohl eher 1500 MB je Stunde :-)
Eigentlich meinte ich 1,5 GiB! :)
Ist das Normal? Wieviel Leute sind denn da insgesamt drauf?
Warum sollte das nicht normal sein? Das sollte kein Problem darstellen. Ein Server - gerade bei einem Massenhoster - steht nicht deswegen im Rechenzentrum, um die meiste Zeit vor sich hinzudösen. Server kosten Geld, z.B: Anschaffungskosten, Verbrauchskosten, Wartungskosten, Administrationskosten. Massenhosting ist ein knallhartes Geschäft. Bei den heutigen Hostingpreisen ist doch kaum Spielraum, um Server nur so zum Spass hinzustellen.
Hey hey, langsam, das ist mir ja schon klar. Meine ursprüngliche Frage war ja auch, wieviel da mitbenutzen. Und ob ein Server eben soviel Traffic gut verkraftet. Das ist mit normal gemeint.
Was für ein Paket nutzt Du? Wieviel kostet Dich das im Monat?
1&1 Business Pro 5.0 und kosten tuts nicht grad wenig, so um die 30 €.
Möglicherweise sind Deine Queries optimierbar.
Optimierbar wären Sie allenfalls über ein paar Joins mehr. Ansonsten sind es normale Select-Abfragen mit einem WHERE und einem ORDER BY.
Vielleicht begehst Du ja auch einen Fehler (der oft von Anfängern gemacht wird) - und fragst in einer Schleife die Datenbank wiederholt ab, statt die Daten auf einmal abzurufen.
Bitte mal erklären, ist nicht ganz verständlich. Wie ist das gemeint? Beispiel evtl.
Vielleicht nutzt Du sogar die API um einen einfachen
JOINzu realisieren.Und wie ist das gemeint bitte? Beispiel evtl.
Danke!
Gruß,
Andy-
Hallo Andy,
Eigentlich meinte ich 1,5 GiB! :)
Hey hey, langsam, das ist mir ja schon klar. Meine ursprüngliche Frage war ja auch, wieviel da mitbenutzen. Und ob ein Server eben soviel Traffic gut verkraftet. Das ist mit normal gemeint.ja, sollte er locker. Ist doch gar nicht sooo viel.
Was für ein Paket nutzt Du? Wieviel kostet Dich das im Monat?
1&1 Business Pro 5.0 und kosten tuts nicht grad wenig, so um die 30 €.Das ist heutzutage wirklich nicht wenig. In dem Bereich kannst Du schon einen Root-Server kriegen.
Möglicherweise sind Deine Queries optimierbar.
Optimierbar wären Sie allenfalls über ein paar Joins mehr.Wie bitte? Und was machst Du statt dessen? Verschachtelte Schleifen in Deiner Programmiersprache?
Ansonsten sind es normale Select-Abfragen mit einem WHERE und einem ORDER BY.
Wieviele für eine einzelne Seite?
Vielleicht begehst Du ja auch einen Fehler (der oft von Anfängern gemacht wird) - und fragst in einer Schleife die Datenbank wiederholt ab, statt die Daten auf einmal abzurufen.
Bitte mal erklären, ist nicht ganz verständlich. Wie ist das gemeint? Beispiel evtl.</archiv/2006/7/t133316/>
</archiv/2006/4/t127782/>Vielleicht nutzt Du sogar die API um einen einfachen
JOINzu realisieren.
Und wie ist das gemeint bitte? Beispiel evtl.</archiv/2006/1/t121430/>
Freundliche Grüße
Vinzenz
-
Hallo!
Wieviele für eine einzelne Seite?
Gegenfrage: Wieviele Queries wären normal pro Seite, bzw. pro funktionellen Seitenabschnitt? :)
Gruß,
AndyP.S.: Hab extrem optimiert und hab eine 20 Anfragen auf eine vereinen können! :)
-
Gegenfrage: Wieviele Queries wären normal pro Seite, bzw. pro funktionellen Seitenabschnitt? :)
P.S.: Hab extrem optimiert und hab eine 20 Anfragen auf eine vereinen können! :)Schon ganz gut. Je weniger, desto besser. Wenn Du aber bspw. Daten erfasst, nehmen wir mal als Beispiel Vertragsdaten, dann musst Du vielleicht mehrere Queries absenden:
- Vertragsarten holen
- interne Vertragspartner holen (wenn der Konzern mehrere Gesellschaften hält)
- externe Vertragspertner holen (ist der Kunde schon bekannt?)
- für ext. Vertragspartnerdaten Orte holen, ggf. Strassen und Länder ebenfalls
- Banken holen (ggf. auch Prüfsummenverfahren)
Man könnte also pi mal Daumen fordern pro Entität eine Query absunden (ich nenne das LIST-Queries, auch GET-, SET- und LET-Queries sind denkbar, aber beim GET, SET und LET braucht man dann in der Tat nur eine Query).
-
Hallo!
Man könnte also pi mal Daumen fordern pro Entität eine Query absunden (ich nenne das LIST-Queries, auch GET-, SET- und LET-Queries sind denkbar, aber beim GET, SET und LET braucht man dann in der Tat nur eine Query).
Ich denke ich verstehe!? ;) Also rein auf GET (SELECT) bezogen, eine Query das Optimum pro Themenbereich, wenn ich es so ausdrücken darf!
Gruß,
Andy-
Ich denke ich verstehe!? ;) Also rein auf GET (SELECT) bezogen, eine Query das Optimum pro Themenbereich, wenn ich es so ausdrücken darf!
Wobei Du manchmal für die Vorbereitung der Datenerfassung Daten aus einem Themenbereich (eine Query) benötigst, manchmal Daten aus mehreren Themenbereichen (mehrere Queries). Bei der eigentlichen Datenerfassung ("SET") oder Datenaktualisierung ("LET") oder Datenlöschung ("DEL") jeweils eine Query.
-
Wobei Du manchmal für die Vorbereitung der Datenerfassung Daten aus einem Themenbereich (eine Query) benötigst, manchmal Daten aus mehreren Themenbereichen (mehrere Queries). Bei der eigentlichen Datenerfassung ("SET") oder Datenaktualisierung ("LET") oder Datenlöschung ("DEL") jeweils eine Query.
Genau so und nicht anders; man kann vermutlich eine Einträge einer Shoutbox schlecht in einem Query mit Information für eine Galerie erfragen. :)
(Na gut, vielleicht schon! *g*)Wobei es aber bei SET, LET, DEL mehr Queries sein können, wenn man Änderungen an verschiedenen Tabellen vornehmen will / muss.
Gruß,
Andy-
Genau so und nicht anders; man kann vermutlich eine Einträge einer Shoutbox schlecht in einem Query mit Information für eine Galerie erfragen. :)
Gemeint war etwas anderes. Lösen wir uns mal vom mässig geeigneten Wort Themenbereich. Wenn Du bespw. Kommunikationsdaten erfasst, dann gibt es da bestimmt Felder, die auf weitere Entitäten verweisen (z.B. Land, Ort, mögliche Anreden), solche Felder werden üblicherweise über SELECT-Elemente dem Nutzer zur Erfassung angeboten und müssen aus verschiedenen Tabellen geladen werden (wenn das Datendesign korrekt ist). Für die Vorbereitung auf solche Erfassungen nutze ich mehrere "Queries". (Es mag "Extremisten" geben, die auch da mit einer "Query" auskommen, aber ich bezweifle deren Einfachheit und damit deren Qualität.)
Wobei es aber bei SET, LET, DEL mehr Queries sein können, wenn man Änderungen an verschiedenen Tabellen vornehmen will / muss.
Es gibt/gab da wohl ein Missverständnis zwischen uns bzgl. "Queries", ich verstehe immer so genannte stored procedures unter einer "Query" bzw. ein SQL-Batch. Das in den SPs und Batches natürlich etliche "Queries" ausgeführt werden sollte sonnenklar sein.
-
Hallo!
Gemeint war etwas anderes. [...] (Es mag "Extremisten" geben, die auch da mit einer "Query" auskommen, aber ich bezweifle deren Einfachheit und damit deren Qualität.)
Okay, geb ich mich geschlagen. :) Mit Themenbereich meinte ich eben unabhängige Teile einer Seite, die sich thematisch und eben datenbanktechnisch nicht zusammenfassen lassen können. Und dann ist eben eine Query (wie es diese Extremisten machen oder schaffen) das Optimum für jeden dieser einzelnen Abschnitte.
Wobei es aber bei SET, LET, DEL mehr Queries sein können, wenn man Änderungen an verschiedenen Tabellen vornehmen will / muss.
Es gibt/gab da wohl ein Missverständnis zwischen uns bzgl. "Queries", ich verstehe immer so genannte stored procedures unter einer "Query" bzw. ein SQL-Batch. Das in den SPs und Batches natürlich etliche "Queries" ausgeführt werden sollte sonnenklar sein.
Okay, dann ist das klar. :)
Gruß,
Andy
-
-
-
-
-
P.S.: Hab extrem optimiert und hab eine 20 Anfragen auf eine vereinen können! :)
Das ist immer noch nicht aussagekräftig.
Benutzt du '*' in deinen Abfragen?
Benutzt du Limit um einzelne Reihen abzufragen?
Benutzt du joins um Ergebnisse zu verknüpfen?
Hast du die richtigen Indizies gesetzt? (ist zwar nicht für die Menge, aber für die Geschwindigkeit relevant)Struppi.
--
Javascript ist toll (Perl auch!)-
Benutzt du '*' in deinen Abfragen?
Nein! :)
Benutzt du Limit um einzelne Reihen abzufragen?
Will alles! :)
Benutzt du joins um Ergebnisse zu verknüpfen?
Ja!
Hast du die richtigen Indizies gesetzt? (ist zwar nicht für die Menge, aber für die Geschwindigkeit relevant)
Denk doch mal.
Das ist immer noch nicht aussagekräftig.
Reicht das? :)
SELECT DISTINCT YEAR(date) AS year, MONTH(date) AS month , COUNT(DISTINCT pics_categories.id) AS num, (MAX(pics_entries.filename)>$newerAs) AS new FROM pics_categories LEFT JOIN pics_entries ON pics_entries.catid = pics_categories.id WHERE pics_categories.status & 0x01=0 GROUP BY year, month ORDER BY year DESC, month DESC, filenameGrob zusammen gefasst funktioniert es so:
1. Tabelle pics_categories enthält Angaben über ein Event, das in Bildern festgehaltet wurde! Wann es war und wie es heißt.
2. Tabelle pics_entries enthält immer einen Eintrag pro Bild, mit Verweis auf die Kategorie, einen Hitcount und dem Dateinamen.
3. Die Dateinamen setzen sich immer so zusammen YYYY-MM-DD-HH... usw., das bedeuted immer wenn ein Bild auf den Server kommt, bekommt es das aktuelle Datum u. die aktuelle Zeit vorne an gestellt.
4. Erreichen wollte ich folgendes und hab ich ja auch! :)
Alle Kategorien zusammengefaßt nach Jahr und Monat und wieviel Kategorien in einem bestimmten Monat sind. Das ganze nach Jahr u. Monat absteigend sortiert.
5. Zusätzlich ein Flag, welches mir anzeigt, ob eine Kategorie(ngruppe) neue Bilder (Bilder neuer als $newerAs) enthalten, damit ich in der Ausgabe das Ganze kenntlich machen kann.Funktioniert.
Ach ja pics_categories.status dient zum Ausblenden von Kategorien, deshalb ist das in der WHERE-Klausel.
Fragen? :)
Gruß,
Andy-
Reicht das? :)
SELECT DISTINCT YEAR(date) AS year, MONTH(date) AS month , COUNT(DISTINCT pics_categories.id) AS num, (MAX(pics_entries.filename)>$newerAs) AS new FROM pics_categories LEFT JOIN pics_entries ON pics_entries.catid = pics_categories.id WHERE pics_categories.status & 0x01=0 GROUP BY year, month ORDER BY year DESC, month DESC, filename
Was sagt EXPLAIN dazu? > Fragen? :) Falls du damit meinst, dass wir jetzt Wissen das du weißt was du tust, nein. Struppi. -- [Javascript ist toll](http://javascript.jstruebig.de/) (Perl auch!)-
Hallo!
Nachdem ich mich ja für etwaige Optimierungen interessiere:
SELECT DISTINCT YEAR(date) AS year, MONTH(date) AS month , COUNT(DISTINCT pics_categories.id) AS num, (MAX(pics_entries.filename)>$newerAs) AS new FROM pics_categories LEFT JOIN pics_entries ON pics_entries.catid = pics_categories.id WHERE pics_categories.status & 0x01=0 GROUP BY year, month ORDER BY year DESC, month DESC, filename
> Was sagt EXPLAIN dazu? EXPLAIN bringt folgendes: table:pics\_categories type: ALL (leider) possible\_keys: NULL (weiß nicht, was ich nehmen soll) key: NULL (logisch) key\_len: NULL (logisch) ref: NULL (auch logisch) rows: 74 Extra: Using where; Using temporary; Using filesort (Mist, mist, mist \*g\*) table: pics\_entries type: ref possible\_keys: catid key: catid key\_len: 4 ref: pics\_categories.id rows: 55 Extra: Keine Ahnung wie ich das wegbringe. Hier noch die Definitionen der Tabellen: ~~~sql CREATE TABLE `pics_categories` ( `id` int(11) NOT NULL auto_increment, `tag` varchar(6) NOT NULL default '', `description` varchar(128) NOT NULL default '', `place` varchar(128) default NULL, `date` datetime default NULL, `status` tinyint(4) NOT NULL default '0', PRIMARY KEY (`id`), UNIQUE KEY `tag` (`tag`) ) TYPE=MyISAM; CREATE TABLE `pics_entries` ( `id` int(11) NOT NULL auto_increment, `filename` varchar(255) NOT NULL default '', `catid` int(11) NOT NULL default '0', `hits` int(11) NOT NULL default '0', `status` tinyint(4) NOT NULL default '0', PRIMARY KEY (`id`), UNIQUE KEY `filename` (`filename`), KEY `catid` (`catid`) ) TYPE=MyISAM;Danke für jeden Tipp.
BTW: Mit verschiedenen Indizes hab ich schon experimentiert, aber keinen Erfolg gehabt. Und das ORDER-BY-Optimierungszeug von der MySQL-Dokumentationsseite blick ich scheinbar nicht ganz.Gruß,
Andy
-
-
-
-
-
-
-