Server durch Abfrage überlastet?

Wronnay · 10 Oktober 2014

Hallo,

ich habe eine Tabelle mit über 350 000 Datensätzen (die auch über 321 MiB groß ist) auf einen Server mit nur 500 MB RAM laufen - wenn ich jetzt eine Abfrage mache, dann kommt immer

Code:

 #2013 - Lost connection to MySQL server during query

ich habe schon

Code:

net_read_timeout        = 1000
net_write_timeout       = 1000

versucht, aber das hat nichts geholfen, kann es sein, dass mein Server einfach durch die Abfrage überlastet wird, oder hat das eine andere Ursache?

akretschmer · 10 Oktober 2014

Wronnay schrieb:
Hallo,

ich habe eine Tabelle mit über 350 000 Datensätzen (die auch über 321 MiB groß ist) auf einen Server mit nur 500 MB RAM laufen - wenn ich jetzt eine Abfrage mache, dann kommt immer

Code:

#2013 - Lost connection to MySQL server during query

ich habe schon

Code:

net_read_timeout = 1000 net_write_timeout = 1000

versucht, aber das hat nichts geholfen, kann es sein, dass mein Server einfach durch die Abfrage überlastet wird, oder hat das eine andere Ursache?

Wie sieht denn die Abfrage aus? Wie das Explain? Was steht im Log von der db?

Wronnay · 10 Oktober 2014

Die Abfrage

Code:

 SELECT *
FROM `1_meta_links`
ORDER BY `1_meta_links`.`last` DESC
LIMIT 0 , 30

Nachfolgend die Log: (anschneidend ist die Datenbank defekt? - Database page corruption on disk or a failed)

Code:

Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be re$
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 [Warning] option 'thread_stack': unsigned value 92160 adjusted to 131072
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and$
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: The InnoDB memory heap is disabled
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: Compressed tables use zlib 1.2.7
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: Using Linux native AIO
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: Initializing buffer pool, size = 128.0M
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: Completed initialization of buffer pool
Oct 10 14:23:35 vs609 mysqld: 141010 14:23:35 InnoDB: highest supported file format is Barracuda.
Oct 10 14:24:47 vs609 mysqld: InnoDB: Database page corruption on disk or a failed
Oct 10 14:24:47 vs609 mysqld: InnoDB: file read of page 25328.
Oct 10 14:24:47 vs609 mysqld: InnoDB: You may have to recover from a backup.
Oct 10 14:24:47 vs609 mysqld: InnoDB: stored checksum 364798435, prior-to-4.0.14-form stored checksum 1467043071
Oct 10 14:24:47 vs609 mysqld: InnoDB: Page lsn 0 1520627919, low 4 bytes of lsn at page end 1520627919
Oct 10 14:24:47 vs609 mysqld: InnoDB: Page number (if stored to page already) 25328,
Oct 10 14:24:47 vs609 mysqld: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Oct 10 14:24:47 vs609 mysqld: InnoDB: Page may be an index page where index id is 12791
Oct 10 14:24:47 vs609 mysqld: InnoDB: (index "PRIMARY" of table "search"."1_meta_links")
Oct 10 14:24:47 vs609 mysqld: InnoDB: Database page corruption on disk or a failed
Oct 10 14:24:47 vs609 mysqld: InnoDB: file read of page 25328.
Oct 10 14:24:47 vs609 mysqld: InnoDB: You may have to recover from a backup.
Oct 10 14:24:47 vs609 mysqld: InnoDB: It is also possible that your operating
Oct 10 14:24:47 vs609 mysqld: InnoDB: system has corrupted its own file cache
Oct 10 14:24:47 vs609 mysqld: InnoDB: and rebooting your computer removes the
Oct 10 14:24:47 vs609 mysqld: InnoDB: error.
Oct 10 14:24:47 vs609 mysqld: InnoDB: If the corrupt page is an index page
Oct 10 14:24:47 vs609 mysqld: InnoDB: you can also try to fix the corruption
Oct 10 14:24:47 vs609 mysqld: InnoDB: by dumping, dropping, and reimporting
Oct 10 14:24:47 vs609 mysqld: InnoDB: the corrupt table. You can use CHECK
Oct 10 14:24:47 vs609 mysqld: InnoDB: TABLE to scan your table for corruption.
Oct 10 14:24:47 vs609 mysqld: InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Oct 10 14:24:47 vs609 mysqld: InnoDB: about forcing recovery.
Oct 10 14:24:47 vs609 mysqld: InnoDB: Ending processing because of a corrupt database page.
Oct 10 14:24:47 vs609 mysqld: 141010 14:24:47  InnoDB: Assertion failure in thread 140629393385216 in file buf0buf.c line 3619
Oct 10 14:24:47 vs609 mysqld: InnoDB: We intentionally generate a memory trap.
Oct 10 14:24:47 vs609 mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Oct 10 14:24:47 vs609 mysqld: InnoDB: If you get repeated assertion failures or crashes, even
Oct 10 14:24:47 vs609 mysqld: InnoDB: immediately after the mysqld startup, there may be
Oct 10 14:24:47 vs609 mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to
Oct 10 14:24:47 vs609 mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
Oct 10 14:24:47 vs609 mysqld: InnoDB: about forcing recovery.
Oct 10 14:24:47 vs609 mysqld: 12:24:47 UTC - mysqld got signal 6 ;
Oct 10 14:24:47 vs609 mysqld: This could be because you hit a bug. It is also possible that this binary
Oct 10 14:24:47 vs609 mysqld: or one of the libraries it was linked against is corrupt, improperly built,
Oct 10 14:24:47 vs609 mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
Oct 10 14:24:47 vs609 mysqld: We will try our best to scrape up some info that will hopefully help
Oct 10 14:24:47 vs609 mysqld: diagnose the problem, but since we have already crashed,
Oct 10 14:24:47 vs609 mysqld: something is definitely wrong and this may fail.
Oct 10 14:24:47 vs609 mysqld:
Oct 10 14:24:47 vs609 mysqld: key_buffer_size=1048576
Oct 10 14:24:47 vs609 mysqld: read_buffer_size=126976
Oct 10 14:24:47 vs609 mysqld: max_used_connections=9
Oct 10 14:24:47 vs609 mysqld: max_threads=50
Oct 10 14:24:47 vs609 mysqld: thread_count=4
Oct 10 14:24:47 vs609 mysqld: connection_count=4

Soll ich die Datenbank mal über ein Backup wiederherstellen - es könnte aber sein, dass das Problem nicht ein defekt, sondern einfach die große Tabelle ist - das Projekt ist eine Suchmaschine, in der täglich neue Datensätze hinzugefügt werden - ein Backup würde also nur eine kleinere Version der Datenbank wiederherstellen ...

akretschmer · 10 Oktober 2014

Wronnay schrieb:
Soll ich die Datenbank mal über ein Backup wiederherstellen - es könnte aber sein, dass das Problem nicht ein defekt, sondern einfach die große Tabelle ist - das Projekt ist eine Suchmaschine, in der täglich neue Datensätze hinzugefügt werden - ein Backup würde also nur eine kleinere Version der Datenbank wiederherstellen ...

Joa, scheint sich zerlegt zu haben. Entweder ist MySQL über sich selbst gestolpert, oder die Hardware hat was weg.

Wronnay · 10 Oktober 2014

Das wird wohl an MySQL liegen - andere Tabellen und Datenbanken funktionieren einwandfrei ...

akretschmer · 10 Oktober 2014

Wronnay schrieb:
Das wird wohl an MySQL liegen

Ja, davon gehe ich auch aus. Ich bin ja eh der Meinung, daß wer wichtige Daten hat kein MySQL nimmt - zumindest kein zweites Mal.

Wronnay · 10 Oktober 2014

akretschmer schrieb:
Ich bin ja eh der Meinung, daß wer wichtige Daten hat kein MySQL nimmt - zumindest kein zweites Mal.

Das Problem ist, dass der Server schon älter ist und ich damals überall MySQL installiert habe.
Jetzt setzte ich mehr auf SQLite und PostgreSQL.

Server durch Abfrage überlastet?

Wronnay

Benutzer

akretschmer

Datenbank-Guru

Wronnay

Benutzer

akretschmer

Datenbank-Guru

Wronnay

Benutzer

akretschmer

Datenbank-Guru

Wronnay

Benutzer

Ähnliche Themen