Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Server durch Abfrage überlastet?

Dieses Thema im Forum "MySQL und MariaDB" wurde erstellt von Wronnay, 10 Oktober 2014.

  1. Wronnay

    Wronnay Benutzer

    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?
     
  2. akretschmer

    akretschmer Datenbank-Guru

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

    Wronnay Benutzer

    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 ...
     
  4. akretschmer

    akretschmer Datenbank-Guru

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

    Wronnay Benutzer

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

    akretschmer Datenbank-Guru

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

    Wronnay Benutzer

    Das Problem ist, dass der Server schon älter ist und ich damals überall MySQL installiert habe.
    Jetzt setzte ich mehr auf SQLite und PostgreSQL.
     
    Hony% und akretschmer gefällt das.
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden