MySQL Hohe Schreiblatenz

Entwickle ich eine social-ähnliche Anwendung, die derzeit für die Nutzung von AWS-services. Insbesondere die DB läuft auf RDS mit MYSQL.
Bisher testen wir die app mit einer begrenzten Anzahl von Benutzern (meist Freunde), die sich in durchschnittlich 15 Write IOPS/Sek.

Das eigentliche problem ist im Zusammenhang mit der sehr hohen schriftlich Latenz der db, die immer über 100ms. Der RDS-Instanz ist ein db.m3.xlarge und das ist viel mehr als das, was wir brauchen.

Ich versuchte, führen Sie einen Belastungstest in einer separaten Instanz (identische Konfiguration der DB und EC2), aber ich war nicht in der Lage zu reproduzieren wie eine hohe Latenz, auch wenn ich das senden war eine wesentlich höhere Zahl von Anfragen. So dachte ich, kann es aufgrund der Tabelle Fragmentierung, aber ich hab noch nicht laufen ein Tisch Optimierung, denn die db würde nicht zugänglich sein, während dieses Vorgangs.

Haben Sie Erfahrungen mit diesem problem?

MEHR INFO

• Verwenden wir mysql-version 5.6.21 mit INNODB als storage-engine.
• Die ganze DB ist über 100MB in der Größe

• Die größte Tabelle (genannt Message) hat über 790k Zeilen. Über diese Tabelle, die folgende Abfrage

  insert into Message (user_id, creationDate, talk_id, text, id) 
  values (2015, '2015-02-01 16:40:06.737', 18312, 'Some text ', 904870)

  nahm 11s ausgeführt werden.

• Schlimmer noch, die Abfrage

  insert into Comment (anonymous, user_id, creationDate, deleted, post_id, text, id) 
  values (1, 107347, '2015-02-01 16:40:01.849', 0, 124888, 'Comment text', 265742)

  nahm 14s, aber die Tabelle Kommentar hat etwa 160k.

Diesen beiden Tabellen werden erzeugt durch:

CREATE TABLE `comment` (
    `id` bigint(20) NOT NULL,
    `anonymous` bit(1) NOT NULL,
    `creationDate` datetime NOT NULL,
    `deleted` bit(1) NOT NULL,
    `text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
    `user_id` bigint(20) NOT NULL,
    `post_id` bigint(20) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `FK_jhvt6d9ap8gxv67ftrmshdfhj` (`user_id`),
    KEY `FK_apirq8ka64iidc18f3k6x5tc5` (`post_id`),
    CONSTRAINT `FK_apirq8ka64iidc18f3k6x5tc5` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`),
    CONSTRAINT `FK_jhvt6d9ap8gxv67ftrmshdfhj` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

und

CREATE TABLE `message` (
    `id` bigint(20) NOT NULL,
    `creationDate` datetime NOT NULL,
    `text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
    `user_id` bigint(20) NOT NULL,
    `talk_id` bigint(20) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `FK_d0j091jvk2y4mmfbadnqlohtf` (`user_id`),
    KEY `FK_64tr15t6wu5y9u143gxt6o3g2` (`thread_id `),
    CONSTRAINT `FK_64tr15t6wu5y9u143gxt6o3g2` FOREIGN KEY (`thread_id`) REFERENCES `thread` (`id`),
    CONSTRAINT `FK_d0j091jvk2y4mmfbadnqlohtf` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

EINIGE GRUNDSTÜCKE

Mit AppDynamics ich habe in der Lage, extrahieren Sie die folgenden Grundstücke:

• Wait-States: Ist das nicht der Abfrage Ende der Zeit zu groß?

  

• Puffer Seite:

  

• Schreiben von Wartezeit und Warteschlange:

  

Query-Cache

+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| query_cache_limit            | 1048576   |
| query_cache_min_res_unit     | 4096      |
| query_cache_size             | 1048576   |
| query_cache_type             | OFF       |
| query_cache_wlock_invalidate | OFF       |
+------------------------------+-----------+

Danke für Eure Hilfe!

Andrea