RootForum Community

Posted: **2003-08-25 10:54**

*InMeinemDebianSystemNachRedHatSuch*

Ich sagte nicht, dass es nur Amis sind, nur, dass es eben nicht nur deutsche sind...

Posted: **2003-09-11 09:21**

Mit MySQL 4.0.15 wurde der Bug beseitigt...

Posted: **2003-09-12 23:50**

Hmmmm,

vieleicht sollte man bei derart grossen Tabellen/DBs ein professionelleres Backend waehlen, vieleicht Interbase 6/7 (bzw. Firebird 1.5 als OS-Loesung) oder Oracle. Wobei IB und Oracle natuerlich Geld kosten wuerden....

BTW: Ich habe festgestellt, dass MySQL bei Verwendung der SQL JOIN-Syntaxe extrem lahm wird. Die meisten Haupt-/Detailbeziehungen lassen sich aber ebenso gut als normale WHERE-Statements umschreiben. Das brachte mir schon dramatische Performancegewinne.

Posted: **2003-09-14 12:50**

mach mal log_bin => ON auf OFF

Falls du keine Replikation brauchst, bekommst du einen großen Geschwindigkeitsschub

Posted: **2003-09-14 12:52**

btw: du bist an der Table-Grenze, du erlaubst zuwenige Tables im Cache!

Posted: **2003-09-14 12:55**

warum hast du kein skip-networking? Du greifst doch hoffentlich über Socket auf die Datenbank zu?

Gib mal mehr Infos/Stats über den MySQL-Server - wieviele temp-Tabellen würden erstellt? Wie groß sind die Resultate deiner Joins? Passen die noch in die Buffer?

Posted: **2003-09-14 14:59**

Vielleicht auf Sybase ASE 12 umsteigen? ;)

Gruss,

Out

Posted: **2003-10-02 19:39**

Hi,

erstmal sorry für die verspäteten Antworten :-)

@Jtb

warum hast du kein skip-networking? Du greifst doch hoffentlich über Socket auf die Datenbank zu?

doch, oder wie sonst sollten 12 WebServer gleichzeitig auf eine Datenbank zugreifen können ? DB und Apache auf einem Server geht wegen der Last nicht. Die DB wird übrigends auf 6 Maschinen repliziert.

mach mal log_bin => ON auf OFF

Geht nicht, dann schlägt logischerweise die Replikation fehl (die wird übrigends per SSH getunnelt)

Gib mal mehr Infos/Stats über den MySQL-Server

Was genau brauchst Du ?

Ich hab mir vorerst damit beholfen, einen "dicken Kasten" in einem Rechenzentrum aufzustellen; nur wie lange der reicht (2*XION 3,8, SCSI RAID 10, und 8 GB RAM) ist jetzt schon wieder abzusehen :-( Es muss doch eine Möglichkeit geben, MySQL beizubringen, etwas schneller zu werden :-D

coolsurfer

Posted: **2004-09-07 18:07**

MySQL ist auch bei mir am Ende angelangt.

3,5 Mill. Einträge in einer Tabelle und Ende im Gelände ....

Ich habe das System vor einem halben Jahr in den Datenbankabfragen optimiert. Früher waren es um die 120 Abfragen pro Seite (ja, Asche auf mein Haupt ;o)), heute sind es nur noch um die 30 bis 40.

Dementsprechend ging jetzt natürlich die Useranzahl nach dem Update nach oben. Der Server war flotter unterwegs.

Derzeit habe ich im Durchschnitt ca. 120 DB-Abfragen pro Sekunde! Pro Monat um die 220GB Traffic.
Ich weis auch nicht mehr wie ichs handeln kann.
170 MB Speicher im laufenden Prozess des Servers ...

Mal am Beispiel;

Code: Select all

CREATE TABLE `yno_priv_msgs` (
  `msg_id` int(10) NOT NULL auto_increment,
  `msg_image` varchar(100) default NULL,
  `subject` varchar(100) default NULL,
  `from_userid` int(10) NOT NULL default '0',
  `to_userid` int(10) NOT NULL default '0',
  `msg_time` varchar(20) default NULL,
  `msg_text` text,
  `read_msg` tinyint(10) NOT NULL default '0',
  PRIMARY KEY  (`msg_id`),
  KEY `to_userid` (`to_userid`)
) TYPE=MyISAM;

Das ist die Tabelle (besser eine) die am meisten Schwierigkeiten verursacht. Es handelt sich hierbei um eine Art Kurz-Nachrichten Tool.

Viele Nachrichten werden zwar gleich gelöscht, jedoch bleiben auch ne Menge "liegen".

So der Index msg_id unter 500.000 bleibt und die Zeilen (Nachrichten) bei ca. 35.000, macht die Tabelle so gut wie keine Probleme.

Aber wehe es geht im Index über 1 Mill. Dann sucht sich das Ding dumm und dusselig.

Die Tabelle wird pro User einmal pro Minute abgefragt. Es wird hinzugeschrieben, gelöscht etc. Da hängt ne Abfrage oft 2 bis 5 Sekunden .... je nach Userlast mit der Abfrage z.B.

Code: Select all

SELECT msg_id, from_userid
FROM yno_priv_msgs
WHERE (
to_userid = '5290'
)
AND (
read_msg = '0'
)

(read_msg = 0 deshalb, damit keine ungelesenen gelöscht werden können)

Was bedeutet, ich muss diese Tabelle wohl in mehrere aufteilen. Und das kann es ja an sich nicht sein, denke ich mir mal.

Alternativen?!
Um ehrlich zu sein, ich weis an der Stelle mal nicht weiter

Posted: **2004-09-08 12:17**

Combined Index ausprobiert? (Ã?ber to_userid und read_msg) ?

Ansonsten vielleicht wäre es evtl. eine möglichkeit anstatt der deletes einfach
updates auf einen "gelöscht" zustand zu machen und die Daten dann einmal
in der Nacht tatsächlich zu löschen?

Man könnte auch mal testen ob das "tiniyint" wirklich performanter
als ein "echter" INT ist.

Ohne das Datenmodell und die Verteilung der Daten allerdings zu kennnen,
kann man da nicht viel sagen.

Gruss,

Out

Posted: **2004-09-09 14:36**

Mal sehen was er damit sagt.
Hab Deine Ideen mal umgesetzt und werds mal beobachten ;o)

Sieht nun so aus:

Code: Select all

CREATE TABLE `yno_priv_msgs` (
  `msg_id` int(10) NOT NULL auto_increment,
  `msg_image` varchar(100) default NULL,
  `subject` varchar(100) default NULL,
  `from_userid` tinyint(7) NOT NULL default '0',
  `to_userid` tinyint(7) NOT NULL default '0',
  `msg_time` varchar(20) default NULL,
  `msg_text` text,
  `read_msg` tinyint(10) NOT NULL default '0',
  PRIMARY KEY  (`msg_id`),
  KEY `to_userid` (`to_userid`,`read_msg`)
) TYPE=MyISAM;

Zur Verteilung der Daten, ich hoffe ich denke richtig was Du da meinst ;o)

Einzige Beziehung zur anderen Tabelle sind die User ID's.

Mal die komplette DB ..

Code: Select all

CREATE TABLE `yno_users` (
  `uid` int(11) unsigned NOT NULL auto_increment,
  `name` varchar(60) NOT NULL default '',
  `uname` varchar(25) NOT NULL default '',
  `email` varchar(100) NOT NULL default '',
  `user_regdate` varchar(20) NOT NULL default '',
  `user_viewemail` tinyint(2) default NULL,
  `user_theme` int(3) default NULL,
  `pass` varchar(40) NOT NULL default '',
  `ublockon` tinyint(1) NOT NULL default '0',
  `ublock` text NOT NULL,
  `theme` varchar(100) NOT NULL default '',
  `commentmax` int(11) NOT NULL default '4096',
  `counter` int(11) NOT NULL default '0',
  `user_level` int(10) NOT NULL default '1',
  `user_ingroup` int(10) NOT NULL default '1',
  `user_regtime` int(11) unsigned NOT NULL default '0',
  `user_lastvisit` int(11) NOT NULL default '0',
  `user_lastip` varchar(60) NOT NULL default '',
  `user_lastmod` varchar(40) NOT NULL default '',
  `user_lasturl` varchar(255) NOT NULL default '',
  `user_stat` tinyint(1) NOT NULL default '0',
  `user_bday` date default NULL,
  `user_sexus` tinyint(1) unsigned NOT NULL default '0',
  PRIMARY KEY  (`uid`),
  UNIQUE KEY `uname` (`uname`),
  KEY `user_ingroup` (`user_ingroup`),
  KEY `user_stat` (`user_stat`),
  KEY `user_lastvisit` (`user_lastvisit`),
  KEY `user_lastmod` (`user_lastmod`)
) TYPE=MyISAM ;

Ich hoffe das war das richtige ;o)

RootForum Community

MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?

Re: MySQL an der Grenze ?