Ankündigung

Einklappen
Keine Ankündigung bisher.

MySQL-Tuner optimieren

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MySQL-Tuner optimieren

    Hallo Zusammen,

    ich habe nun eine Frage zum MySQLTuner.
    Ich habe schon alles möglich probiert, jedoch bekomme ich den join_buffer_size nicht weg...wie hoch soll/kann man den denn noch setzen?

    Auch habe ich bereits die Tabellen optimiert - die Meldung, dass die Tabellen optimiert werden sollen, kommt jedoch nachwievor...

    [--] Data in InnoDB tables: 4M (Tables: 271)
    [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
    [!!] Total fragmented tables: 271

    -------- Security Recommendations -------------------------------------------
    [OK] All database users have passwords assigned

    -------- Performance Metrics -------------------------------------------------
    [--] Up for: 5m 7s (4K q [16.055 qps], 536 conn, TX: 979K, RX: 472K)
    [--] Reads / Writes: 100% / 0%
    [--] Total buffers: 4.5G global + 66.6M per thread (151 max threads)
    [OK] Maximum possible memory usage: 14.3G (45% of installed RAM)
    [OK] Slow queries: 0% (0/4K)
    [OK] Highest usage of available connections: 3% (6/151)
    [OK] Key buffer size / total MyISAM indexes: 4.0G/74.2M
    [OK] Key buffer hit rate: 98.4% (137K cached / 2K reads)
    [OK] Query cache efficiency: 64.8% (2K cached / 3K selects)
    [OK] Query cache prunes per day: 0
    [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 502 sorts)
    [!!] Joins performed without indexes: 7
    [OK] Temporary tables created on disk: 9% (54 on disk / 586 total)
    [OK] Thread cache hit rate: 98% (6 created / 536 connections)
    [OK] Table cache hit rate: 23% (472 open / 1K opened)
    [OK] Open file limit used: 4% (365/8K)
    [OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
    [OK] InnoDB data size / buffer pool: 4.6M/128.0M

    -------- Recommendations -----------------------------------------------------
    General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    Variables to adjust:
    join_buffer_size (> 64.0M, or always use indexes with joins)


  • #2
    Auch habe ich bereits die Tabellen optimiert - die Meldung, dass die Tabellen optimiert werden sollen, kommt jedoch nachwievor...
    Das wird auch so bleiben, solange folgendes der Fall bleibt:
    Joins performed without indexes: 7
    join_buffer_size (> 64.0M, or always use indexes with joins)
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #3
      Das bedeuted? Relevante Indexes haben wir eigentlich gesetzt...

      Kommentar


      • #4
        Nein, habt ihr nicht (zumindest offensichtlich nicht überall).

        Die Datenbank sagt: 7 Joins wo kein Index genutzt wurde, die Datenbank lügt nicht und sie weiss es am besten.
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Komisch - jetzt bekommen wir ein ganz anderes ergebniss, obwohl nichts geändert wurde...

          [--] Data in MyISAM tables: 1G (Tables: 157)
          [--] Data in InnoDB tables: 4M (Tables: 271)
          [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
          [!!] Total fragmented tables: 271

          -------- Security Recommendations -------------------------------------------
          [OK] All database users have passwords assigned

          -------- Performance Metrics -------------------------------------------------
          [--] Up for: 1h 41m 46s (17K q [2.894 qps], 1K conn, TX: 3M, RX: 1M)
          [--] Reads / Writes: 98% / 2%
          [--] Total buffers: 4.5G global + 66.6M per thread (151 max threads)
          [OK] Maximum possible memory usage: 14.3G (45% of installed RAM)
          [OK] Slow queries: 0% (0/17K)
          [OK] Highest usage of available connections: 3% (6/151)
          [OK] Key buffer size / total MyISAM indexes: 4.0G/74.2M
          [OK] Key buffer hit rate: 98.2% (202K cached / 3K reads)
          [OK] Query cache efficiency: 86.1% (9K cached / 11K selects)
          [OK] Query cache prunes per day: 0
          [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 725 sorts)
          [OK] Temporary tables created on disk: 9% (76 on disk / 800 total)
          [OK] Thread cache hit rate: 99% (6 created / 1K connections)
          [!!] Table cache hit rate: 6% (288 open / 4K opened)
          [OK] Open file limit used: 0% (0/8K)
          [OK] Table locks acquired immediately: 100% (4K immediate / 4K locks)
          [OK] InnoDB data size / buffer pool: 4.6M/128.0M

          -------- Recommendations -----------------------------------------------------
          General recommendations:
          Run OPTIMIZE TABLE to defragment tables for better performance
          MySQL started within last 24 hours - recommendations may be inaccurate
          Enable the slow query log to troubleshoot bad queries
          Increase table_cache gradually to avoid file descriptor limits
          Variables to adjust:
          table_cache (> 4069)

          Kommentar


          • #6
            Ich würde vorschlagen, du lässt den Server mal 4 Wochen lang laufen, ihr testet die Applikation(en) intensiv in allen Bereichen und DANN schaust du nochmal nach... bei Laufzeiten von 5 Minuten bzw. anderthalb Stunden ist wohl noch nicht sooo viel in der DB passiert, meinste nicht auch?
            Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

            Kommentar


            • #7
              MySQL-Tuner optimieren

              Ich könnte dir eine schöne Grafik von monitorix dazu zeigen, die sich auf meinem Server gerade bildet. Erst nach ca 10 bis 24h Betrieb pendelt sich MySQL langsam im optimalen Betrieb ein (cache hit rate etc). Nach ein paar Minuten ist ein solcher Test einfach nichtssagend.
              GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

              Kommentar


              • #8
                Was nicht heute alles als OK durchgeht. 16GB RAM für die Datenbank und trotzdem erzeugen fast 10% aller Queries eine Temporäre Tabelle auf der Platte... Okeyyyy.

                Kommentar


                • #9
                  Zitat von erc Beitrag anzeigen
                  Was nicht heute alles als OK durchgeht. 16GB RAM für die Datenbank und trotzdem erzeugen fast 10% aller Queries eine Temporäre Tabelle auf der Platte... Okeyyyy.
                  IIRC *kann* MySQL manche Dinge nur via Platte und temp. Tabellen ausführen. Egal, was an RAM da ist.
                  PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                  Kommentar

                  Lädt...
                  X