krusty007 wrote:So habe jetzt doch noch auf meinen Server zugreifen können. Hier sind die Auszüge:
Code: Select all
# key_buffer = 16M
key_buffer = 128M
aber
Code: Select all
| Uptime | 167028 |
| Key_blocks_unused | 115980 |
| Key_blocks_used | 1 |
| Key_read_requests | 12 |
| Key_reads | 1 |
Du verwendest gar kein MyISAM, also brauchst Du auch keinen key_buffer zu verschwenden. Mach den wieder klein, Du brauchst nur InnoDB Buffer Cache.
Code: Select all
set-variable = max_connections=1200
So viel? Vielleicht tut da irgendwo mysql_pconnect() wo es nicht tun sollte?
Code: Select all
# Replication Master Server (default)
# binary logging is required for replication
# log-bin
Du stehst nicht auf Backup, was?
Code: Select all
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 5M
Gut, paßt von der Größe zu Deinen Tabletypen. Bisher findet sich Data nur in Deiner history-Tabelle (11MB), und dort generierst Du extrem große Index-Lengths. Möglicherweise gehst Du hier einen architekturellen Irrweg, wir müssen das in einem anderen Artikel weiter unten noch mal genauer besprechen - was ist das Ziel Deiner Anwendung (was generierst Du - System Down Warnungen oder Grafiken mit historischen Meßwerten?) und bist Du sicher, daß Du hier nicht OLTP und DWH im selben Datenmodell vermischt?
Code: Select all
innodb_flush_log_at_trx_commit = 1
Kannst Du Dir bei der Natur Deiner Daten erlauben, das auf "2" zu setzen?
Code: Select all
| Com_delete | 93291 |
| Com_insert | 208651 |
| Com_select | 1476131 |
| Com_update | 453973 |
| Com_replace | 0 |
| Questions | 2366963 |
| Uptime | 167028 |
Up 2 Tage, 14 qps Durchschnitt, 1.95 mal mehr SELECT als DML. Kein REPLACE verwendet, wahrscheinlich auch keine extended INSERT Syntax - kannst Du Writes in die Datenbank batchen, oder mußt Du für jede Ã?nderung ein einzelnes INSERT generieren? Kannst Du statt UPDATE REPLACE verwenden und dann REPLACE mit extended INSERT Syntax verwenden, um zu batchen?
Code: Select all
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 115980 |
| Key_blocks_used | 1 |
| Key_read_requests | 12 |
| Key_reads | 1 |
Jedes Byte Speicher für den key_buffer ist verschendet. Setze den auf 16M.
Max_connections auf 1200 und dann das?
Code: Select all
| Open_tables | 77 |
| Opened_tables | 278 |
Dein Table Cache ist gross genug.
Code: Select all
| Qcache_free_blocks | 0 |
| Qcache_free_memory | 0 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 0 |
| Qcache_queries_in_cache | 0 |
| Qcache_total_blocks | 0 |
Du verwendest den Query Cache nicht. Warum nicht? Bringt er bei Dir nix (alles mit prepared Statements?) oder weißt Du nix von dem?
Code: Select all
| Select_full_join | 0 |
| Select_full_range_join | 0 |
| Select_range | 35858 |
| Select_range_check | 0 |
| Select_scan | 287356 |
| Slow_queries | 0 |
keine Full Joins, keine Slow Queries. Alles ist gut.
Code: Select all
| Threads_cached | 0 |
| Threads_connected | 2 |
| Threads_created | 55957 |
| Threads_running | 1 |
Thread_cache kann auf 20 oder so gesetzt werden.
Code: Select all
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 20971520 |
Je nachdem, was Du da machst, kann das knapp sein.
Je nachdem, was Du da an Hardware hast, kann es besser sein, dies auf 4 zu setzen.
Code: Select all
| log_slow_queries | OFF |
| long_query_time | 10 |
Derzeit brauchst Du das nicht (Counter ist 0), aber vielleicht willst Du das präventiv dennoch anschalten.
Hier, die gesparten 128M aus dem Key_buffer_size solltest Du mal lieber hier rein stecken.
Wie gesagt, 20 wäre wohl gut bei den jetzigen Leistungsdaten.
Momentan werden nur ein paar Hosts mit dem Monitoring Tool überwacht, es sollen aber über 1200 werden. Bei jedem Host werden dabei dann 6 Werte über SNMP abgefragt. Diese werden dann in die DB geschrieben. Das Abfragen passiert jede Minute. Vielen Dank für die Hilfe. Bin wie schon geschrieben nicht wirklich ein Datenbank Kenner.
1200 Hosts pro Minute sind 20 Hosts, also 120 SNMP Queries pro Sekunde. Wenn jede dieser Queries einen Integer generiert, akkumulierst Du 480 Byte pro Sekunde, also 40.5 MB und 10 Mio Samples (Rows?) pro Tag. Da wirst Du nicht viel Freude dran haben, es sei denn, zu aggregierst fleißig und schmeißt die Raw-Daten regelmäßig weg.
Deswegen ist es sinnvoll hier die Alerts und die History sauber voneinander zu trennen (Zwei Schemata, möglicherweise sogar in zwei verschiedenen Datenbanken) und eine saubere Schnittstelle zwischen beiden Dingen zu definieren. Alerts sind OLTP-Jobs, die History ist ein klassischer DWH-Job.
Du solltest auf keinen Fall Constraints definieren, die aus dem OLTP-Teil ins DHW zeigen, wie ein anderer "Ich snmp mir mein Netz"-Kunde, den ich mal gehabt habe das gemacht hat. Das Alert-Schema wird klassisch streng normalisiert sein, das History-Schema wird ein klares Star-Schema um die History-Tabelle drumrum sein. Was sind die Dinge, die Du aus der History ziehen willst? Hast Du Dir schon über Granularität und Aggregierung der Daten Gedanken gemacht oder willst Du wirklich auf 300 Mio Rows pro Monat rumsitzen?
Mit 120 SNMP Queries pro Sekunde wirst Du auch ohne Datenbank die Kiste schon ziemlich stressen. Ohne eine klare Strategie für Batching beim Data Load wirst Du keine ausreichende Datenbank-Performance im Alert-Teil der Datenbank bekommen.
