Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

SQL beim schreiben sehr sehr langsam

Alles rund um die Server (Web-, Mail-, Datenbank-, Datenaustausch-, etc.) die man unter Linux betreiben kann

Moderator: Moderatoren

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 14. Okt 2019, 09:40

Hallo Gemeinde!

Hab da ein Problem mit SQL auf meiner Lokalen OpenSUSE 15.1 Web-Entwicklungs-Installation.

Schreibbefehle wie insert into sind immer extrem langsam. Besonders bemerkbar macht es sich wenn irgendwelche Cronjobs laufen oder ich ein Setup eines z.b. Webanwendung starte bzw damit arbeite.

Beispiel:
Import eines Backups über die Konsole mittels "mysql -u BENUTZER -p DATENBANKNAME < DATENBANKBACKUP.sql" braucht 12 Minuten für etwa 11.000 Datensätze. Das auch bei anderen Datenbank-Imports bzw. arbeiten mit diesen.

Ich habe schon im Netz nach hinweisen gesucht bin aber nicht wirklich fündig geworden. Vielleicht wähle ich auch die falschen Suchbegriffe.

Wäre für jeden Tipp dem Problem auf die schliche zu kommen sehr dankbar.

Mein System:

Datenbank:
Server: Localhost via UNIX socket
Server-Typ: MariaDB
Server-Version: 10.2.25-MariaDB - SUSE package
Protokoll-Version: 10
Server-Zeichensatz: UTF-8 Unicode (utf8mb4)

Webserver:
Apache
Datenbank-Client Version: libmysql - mysqlnd 5.0.12-dev - 20150407
PHP-Erweiterung: mysqli, curl, mbstring
PHP-Version: 7.2.5



Gruß
Matthias

Werbung:
marce
Advanced Hacker
Advanced Hacker
Beiträge: 1159
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von marce » 14. Okt 2019, 10:01

Poste doch mal die Maria-DB-Konfig - ich vermute mal, daß Du da nicht wirklich Optimierungen durchgeführt hast?

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 14. Okt 2019, 10:13

Hallo marce,

meinst Du die etc/my.cnf?
Wenn ja, da habe ich wirklich nichts dran gemacht.

my.cnf:

Code: Alles auswählen

# The following options will be passed to all MariaDB clients
[client]
# Please note that storing the password in this file is not safe. For this
# purpose you can, for example, list your password in the [client] section
# of the '~/.my.cnf' configuration file with an access mode set to 400 or 600.
# password   = your_password
# port       = 3306
# socket     = /run/mysql/mysql.sock

# The MariaDB server
[mysqld]

# For security reasons, bind to 127.0.0.1 by default to enable networking
# only on the loopback interface.
bind-address    = 127.0.0.1

# If log-error is not set, mysqld will write to "/var/lib/mysql/$HOSTNAME.err"
# which is not beneficial for rotating the log file if it grows in size.
log-error       = /var/log/mysql/mysqld.log

# Enable the slow query log to see queries with especially long duration
# slow_query_log=1
# slow_query_log_file = /var/log/mysql/mysqld_slow.log

# Operations 'LOAD DATA', 'SELECT ... INTO' and 'LOAD FILE()' will only
# work with files in the specified directory
secure_file_priv = /var/lib/mysql-files

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M

# Using newer file format that supports dynamic and compressed row formats.
# If you are using replication you have to make sure, that these options are
# set everywhere the same way (probably comment them out is the easiest way)
innodb_file_format=Barracuda
innodb_file_per_table=ON

# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin=mysql-bin
# binlog_format=mixed

# Remove leading # if you want to store your database elsewhere
# datadir	= /var/lib/mysql

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id	= 1

# These are commonly set, remove the # and set as required.
# port = 3306
# socket = /run/mysql/mysql.sock

# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M 

# Configure the MariaDB server to use SSL 
# ssl-ca=/etc/mysql/ssl/ca-cert.pem
# ssl-cert=/etc/mysql/ssl/server-cert.pem
# ssl-key=/etc/mysql/ssl/server-key.pem

sql_mode=NO_ENGINE_SUBSTITUTION
# sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

[mysqld_multi]
mysqld     = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log        = /var/log/mysqld_multi.log

# If you want to use mysqld_multi uncomment 1 or more mysqld sections
# below or add your own ones.

# WARNING
# --------
# If you uncomment mysqld1 than make absolutely sure, that database mysql,
# configured above, is not started.  This may result in corrupted data!
#
# [mysqld1]
# port       = 3306
# datadir    = /var/lib/mysql
# pid-file   = /var/lib/mysql/mysqld.pid
# socket     = /var/lib/mysql/mysql.sock
# user       = mysql

# [mysqld2]
# port       = 3307
# datadir    = /var/lib/mysql-databases/mysqld2
# pid-file   = /var/lib/mysql-databases/mysqld2/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld2/mysql.sock
# user       = mysql

# [mysqld3]
# port       = 3308
# datadir    = /var/lib/mysql-databases/mysqld3
# pid-file   = /var/lib/mysql-databases/mysqld3/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld3/mysql.sock
# user       = mysql

# [mysqld6]
# port       = 3309
# datadir    = /var/lib/mysql-databases/mysqld6
# pid-file   = /var/lib/mysql-databases/mysqld6/mysql.pid
# socket     = /var/lib/mysql-databases/mysqld6/mysql.sock
# user       = mysql

!includedir /etc/my.cnf.d


Gruß
Matthias

marce
Advanced Hacker
Advanced Hacker
Beiträge: 1159
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von marce » 14. Okt 2019, 10:20

... da wäre noch ein include-Directory.

Aber wenn Du nichts gemacht hast und die Dumps einigermaßen sauber sind (z.B. indices erst nach dem Import erstellen und nicht parallel bei jedem einzelnen insert, nicht für jeden Insert eine einzelne Anweisung, ...)

... dann solltest Du da mal anfangen, was zu tun.

Stichworte: tuning-primer, mysqltuner, ...

Die off. Doku bietet da schon einiges an Ansätzen oder auch rudimentär die Ratgeber-Seite von phpMyAdmin.

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 14. Okt 2019, 10:32

marce hat geschrieben:
14. Okt 2019, 10:20
Aber wenn Du nichts gemacht hast und die Dumps einigermaßen sauber sind (z.B. indices erst nach dem Import erstellen und nicht parallel bei jedem einzelnen insert, nicht für jeden Insert eine einzelne Anweisung, ...)
Das werde ich mir heute abend mal genauer anschauen und einige Test durchführen.

marce hat geschrieben:
14. Okt 2019, 10:20
Stichworte: tuning-primer, mysqltuner, ...
Danke für die Bettlektüre. :)


Gruß
Matthias

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 16. Okt 2019, 09:24

marce hat geschrieben:
14. Okt 2019, 10:20
Aber wenn Du nichts gemacht hast und die Dumps einigermaßen sauber sind (z.B. indices erst nach dem Import erstellen und nicht parallel bei jedem einzelnen insert, nicht für jeden Insert eine einzelne Anweisung, ...)
Daran lag es schonmal nicht. Da auch das Problem bei selbst erstellten Lokalen Backups (Konsole oder PHPMyAdmin) aus der Datenbank und wieder einspielen zu diesen Einbrüchen kommt.


Gruß
Matthias

spoensche
Moderator
Moderator
Beiträge: 7468
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: SQL beim schreiben sehr sehr langsam

Beitrag von spoensche » 19. Okt 2019, 02:44

Wie groß ist die Datenbank?
Welche Storage Engine verwendet die Datenbank?
Was für Festplatten werden verwendet?
Werden die Festplatten in einem RAID betrieben?
Was für Hardware ist verbaut?
Wie sieht der I/O Wait aus?

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 19. Okt 2019, 11:00

Hallo spoensche!
spoensche hat geschrieben:
19. Okt 2019, 02:44
Wie groß ist die Datenbank?
Es sind mehrere Projekt. So Zwischen 10MB bis rauf auf 2GB.
spoensche hat geschrieben:
19. Okt 2019, 02:44
Welche Storage Engine verwendet die Datenbank?
Bei diversen Projekten ist als standard "innodb" installiert.
spoensche hat geschrieben:
19. Okt 2019, 02:44
Was für Festplatten werden verwendet?
Werden die Festplatten in einem RAID betrieben?
Was für Hardware ist verbaut?
Wie sieht der I/O Wait aus?
RAID ist nicht vorhanden. Und an der Festplatte sollte es nicht liegen, da es damit in der Vergangeheit nie Probleme gab.

Ich werde mal ein wenig nach "innodb" forschen. Ich habe den Verdacht das es nur an diesem Typ liegt. Ich hatte auch sonst nie Probleme in dieser Richtung gehabt, das Schreibprozesse so extrem langsam sind.


Gruß
Matthias

spoensche
Moderator
Moderator
Beiträge: 7468
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: SQL beim schreiben sehr sehr langsam

Beitrag von spoensche » 19. Okt 2019, 14:58

mattmarr hat geschrieben:
19. Okt 2019, 11:00
spoensche hat geschrieben:
19. Okt 2019, 02:44
Was für Festplatten werden verwendet?
Werden die Festplatten in einem RAID betrieben?
Was für Hardware ist verbaut?
Wie sieht der I/O Wait aus?
RAID ist nicht vorhanden. Und an der Festplatte sollte es nicht liegen, da es damit in der Vergangeheit nie Probleme gab.

Ich werde mal ein wenig nach "innodb" forschen. Ich habe den Verdacht das es nur an diesem Typ liegt. Ich hatte auch sonst nie Probleme in dieser Richtung gehabt, das Schreibprozesse so extrem langsam sind.
Datenbanken sind RAM und IO Säue.
Nur weil es in der Vergangenheit keine Performance Probleme mit der Festplatte gab, heisst das nicht, dass das immer der Fall ist.

Die technischen Daten der Festplatte sind schon wichtig.
Verwendest du eine SSD oder mechanische Festplatte? Wenn mechanisch SATA oder SAS.

Den I/O Wait kannst du, per top Befehl, ermitteln. (Grob und gesamt, genauer gehts mit sysstat)

Wird die Festplatte ausschließlich für die Datenbank verwendet?

Z.B. ist bei mechansichen Festplatten folgendes interessant:

- mittlere Zugriffszeit (Zeit, die für die Positionierung der Schreib-Lese Köpfe benötigt wird
- SATA oder SAS
- HDD interner Cache
- U/min, min. 7500 besser 15000

Zu InnoDB:

Folgende InnoDB Parameter sind, bezüglich schreiben, relevant:

- innob_flush_log_at_trx_commit
- innodb_file_per_table
- innodb_flush_method, optimal ist O_DIRECT

Zu den Insert Statements:

Handelt es sich bei den INSERT Statements um viele einzelne oder verwendest du Batch-Inserts? (ein INSERT Statement für viele Datensätze).
Wie lange dauert den ein Restore des Dumps?

Ist das System fleissig am Swappen?
Läuft der Webserver auf dem selben System?
Um wie viele Projekte handelt es sich?
Werden die Webseiten sehr häufig aufgerufen? (Also hoher Traffic)

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 23. Okt 2019, 18:54

Hallo alle!

Ich kam erst heute wieder dazu das Problem weiter einzugrenzen.
Dazu habe ich ganz spontan den mysql (datadir) Ordner (Btrfs) auf eine eigene Festplatte (ext4) umgezogen. Jetzt rennt MySQL wieder wie der Blitz. Also lag es schon mal nicht an MySQL.

Ich komme erst gegen Wochenende wieder dazu das noch genauer zu untersuchen. Hab immer mehr die Haupt-festplatte oder das Dateisystem Btrfs in Verdacht. Mal schauen.


Gruß
Matthias

spoensche
Moderator
Moderator
Beiträge: 7468
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: SQL beim schreiben sehr sehr langsam

Beitrag von spoensche » 24. Okt 2019, 23:00

An BTRFS liegt es denke ich nicht.

Poste doch mal die Ausgabe von

Code: Alles auswählen

free -m
smartctl -a /dev/sda | egrep -i rotation

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 25. Okt 2019, 10:27

Hallo spoensche,

hier die Ausgaben auf der Konsole.

Code: Alles auswählen

# free -m
              total        used        free      shared  buff/cache   available
Mem:           7918        4171         534         176        3213        3304
Swap:          7919           0        7919

Code: Alles auswählen

# smartctl -a /dev/sdb | egrep -i rotation
Rotation Rate:    7200 rpm
Hier mal die komplette Ausgabe von smartctl:

Code: Alles auswählen

# smartctl -a /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.12.14-lp151.28.20-default] (SUSE RPM)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST2000DM001-9YN164
Serial Number:    Z1E2HGSW
LU WWN Device Id: 5 000c50 04f54de78
Firmware Version: CC4B
User Capacity:    2.000.398.934.016 bytes [2,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Fri Oct 25 10:20:41 2019 CEST

==> WARNING: A firmware update for this drive may be available,
see the following Seagate web pages:
http://knowledge.seagate.com/articles/en_US/FAQ/207931en
http://knowledge.seagate.com/articles/en_US/FAQ/223651en

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (  584) seconds.
Offline data collection
capabilities:                    (0x73) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        ( 230) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x3085) SCT Status supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       -       166128360
  3 Spin_Up_Time            0x0003   095   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   096   096   020    Old_age   Always       -       4614
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       34733825387
  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always       -       10848
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   096   096   020    Old_age   Always       -       4613
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0
189 High_Fly_Writes         0x003a   096   096   000    Old_age   Always       -       4
190 Airflow_Temperature_Cel 0x0022   058   042   045    Old_age   Always   In_the_past 42 (Min/Max 21/42 #1576)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       216
193 Load_Cycle_Count        0x0032   094   094   000    Old_age   Always       -       13846
194 Temperature_Celsius     0x0022   042   058   000    Old_age   Always       -       42 (0 15 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       10776h+22m+46.100s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       22926876626936
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       10982329814016

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     10847         -
# 2  Short offline       Completed without error       00%     10835         -
# 3  Short offline       Completed without error       00%     10825         -
# 4  Short offline       Completed without error       00%     10816         -
# 5  Short offline       Completed without error       00%     10804         -
# 6  Short offline       Completed without error       00%     10794         -
# 7  Short offline       Completed without error       00%     10788         -
# 8  Short offline       Completed without error       00%     10781         -
# 9  Short offline       Completed without error       00%     10770         -
#10  Short offline       Completed without error       00%     10763         -
#11  Short offline       Completed without error       00%     10751         -
#12  Short offline       Completed without error       00%     10741         -
#13  Short offline       Completed without error       00%     10735         -
#14  Short offline       Completed without error       00%     10725         -
#15  Short offline       Completed without error       00%     10717         -
#16  Short offline       Completed without error       00%     10707         -
#17  Short offline       Completed without error       00%     10694         -
#18  Short offline       Completed without error       00%     10681         -
#19  Short offline       Completed without error       00%     10669         -
#20  Extended offline    Interrupted (host reset)      00%     10664         -
#21  Short offline       Completed without error       00%     10652         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

josef-wien
Ultimate Guru
Ultimate Guru
Beiträge: 5327
Registriert: 23. Sep 2008, 17:09

Re: SQL beim schreiben sehr sehr langsam

Beitrag von josef-wien » 25. Okt 2019, 12:14

Zu den Attributen 1 und 7 siehe https://de.wikipedia.org/wiki/Self-Moni ... Auswertung. Zur realistischen Beurteilung müßte man die ursprünglichen Werte der Platte im Neuzustand kennen. Ansonsten sieht alles normal aus.

Kann es sein, daß die Platte trotz ihrer Umdrehungszahl eher ein gemächlicher Typ ist? Kann es sein, daß die die großen Dateien beherbergenden Sektoren wild auf der Platte verstreut sind? NCQ wird ja wohl aktivert sein (das Ergebnis muß größer als 1 sein, das Maximum ist 31):

Code: Alles auswählen

cat /sys/block/sdb/device/queue_depth
Mehr fällt mir nicht ein.

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 25. Okt 2019, 12:39

josef-wien hat geschrieben:
25. Okt 2019, 12:14
Kann es sein, daß die Platte trotz ihrer Umdrehungszahl eher ein gemächlicher Typ ist? Kann es sein, daß die die großen Dateien beherbergenden Sektoren wild auf der Platte verstreut sind? NCQ wird ja wohl aktivert sein (das Ergebnis muß größer als 1 sein, das Maximum ist 31):

Code: Alles auswählen

cat /sys/block/sdb/device/queue_depth
Mehr fällt mir nicht ein.
Die Platte ist in letzter Zeit öfter mal sehr Aktiv beim Speichern. Kann aber nicht sagen seit wann. Hab bisher auch keine veränderungen gemerkt bei der täglichen Benutzung. Halt bei den Web-Projekten auf einmal viel es deutlich auf.
Bekomme folgende Ausgabe:

Code: Alles auswählen

> cat /sys/block/sdb/device/queue_depth
1

josef-wien
Ultimate Guru
Ultimate Guru
Beiträge: 5327
Registriert: 23. Sep 2008, 17:09

Re: SQL beim schreiben sehr sehr langsam

Beitrag von josef-wien » 25. Okt 2019, 16:37

Laut https://www.seagate.com/gb/en/support/k ... -193785en/ kann die Festplatte NCQ. Daß es nicht verwendet wird, könnte am mainboard liegen (oder Du hast es deaktiviert). Theoretisch ist das schlecht, da die Festplatte Befehle nur sequentiell abarbeiten kann (mit NCQ kann sie die Reihenfolge im Hinblick auf möglichst wenig Zugriffspausen durch optimale Bewegungen der Schreib-/Leseköpfe selbst festlegen). Was das in der Praxis bedeutet, kann ich nicht beurteilen.

spoensche
Moderator
Moderator
Beiträge: 7468
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: SQL beim schreiben sehr sehr langsam

Beitrag von spoensche » 26. Okt 2019, 20:28

Installiere bitte mal Sysstat.

Code: Alles auswählen

zypper in sysstat
Dann wartest du mal eine Stunde und postest bitte die Ausgabe von

Code: Alles auswählen

iostat -kx

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 27. Okt 2019, 13:25

SDA ist derzeit meine derzeit SQL Platte.
SDB ist meine Hauptplatte auf der OpenSuSE 15.1 LEAP drauf läuft.

Code: Alles auswählen

> iostat -kx
Linux 4.12.14-lp151.28.20-default (xxx.xx)    27.10.2019      _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13,20    0,27    3,75    2,09    0,00   80,70

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              0,03    0,72      1,16     11,41     0,01     0,47  14,63  39,57    4,94   13,34   0,01    36,43    15,95  11,20   0,84
sdb              1,10   26,40     68,68    361,33     0,03     2,20   2,23   7,68   14,73   12,41   0,35    62,53    13,69   0,77   2,10
Deine I/O Waits sind bei beiden Platten sehr sehr hoch.

sda: 13,34%
sdb: 12,41%

100 Projekte inkl. der Datenbank sind zu viel für dein System.

-Hast du mal im Slow Log geprüft, ob dort Statements aufgeführt werden, die z.B. in einer WHERE Bedingung keinen Index verwenden. Es gibt mehrere Möglichkeiten hier etwas zu optimieren.

8 GB RAM sind für den Workload unterdimensioniert. Für den Betrieb der Datenbank kannst du schon mal den RAM voll bestücken und anschließend den InnoDB Buffer Pool wie folgt zuweisen:

- wenn die Webprojekte, weiterhin auf der gleichen Maschine laufen sollen, dann einen Bufferpool von 70% des physikalischen RAM's
- wenn die Webprojekte auf einen eigenen Server umgezogen werden, dann zwischen 80-85% des physikalischen RAM's

Um den Festplatten mal auf den Zahn zu fühlen, kannst du mit dem Tool Fio eine Messsung der Lesegeschwindigkeit mit einem random Zugriffsmuster ermitteln.

An der Kernel Konfguration kann auch noch einiges rausgeholt werden. (z.B. Dateisystem Caching, der Zyklus, in dem die Daten auf die Platte geschrieben werden.

Was für Dienste betreibst du noch auf dem System?

marce
Advanced Hacker
Advanced Hacker
Beiträge: 1159
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von marce » 28. Okt 2019, 06:39

Für ein lokales Web-Entwicklungssystem sollte die Hardware mehr als ausreichend sein. Egal ob da nun 1, 5, 100 oder 1000 Projekte drauf "eingerichtet" sind.

Ich würde die DB entsprechend optimieren, ggf. dann noch das Filesystem passend wählen.

Das MySQL / MariaDB in der von den meisten Distributionen mitgelieferten Default-Konfiguration mehr oder wenig lahmarschig und damit ggf. Richtung unbenutzbar geht ist ja durchaus bekannt.

mattmarr
Member
Member
Beiträge: 70
Registriert: 14. Feb 2007, 19:02
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von mattmarr » 28. Okt 2019, 09:38

Hallo marce,

marce hat geschrieben:
28. Okt 2019, 06:39
Ich würde die DB entsprechend optimieren, ggf. dann noch das Filesystem passend wählen.
Bin bereits dabei mir gedanken zu machen. Datenbank hat bereits eine eigene Platte. Diese ist mit ext4 formatiert. Auch werde ich die Tage den www-Order eine eigene Platte spendieren.
marce hat geschrieben:
28. Okt 2019, 06:39
Das MySQL / MariaDB in der von den meisten Distributionen mitgelieferten Default-Konfiguration mehr oder wenig lahmarschig und damit ggf. Richtung unbenutzbar geht ist ja durchaus bekannt.
Komisch ist, das ich die Jahre nie Probleme hatte. Als wenn das ganze mit der neu Installation (~ ende Mai) von OpenSuSE 15.1 Leap erst angefangen hat.

Eben hatte ich wieder das Problem. Wollte mir eine Testversion von Pimcore demo-ecommerce (https://pimcore.com/docs/5.x/Developmen ... ation.html) Installieren. Bei der Installation der Datenbank läuft und läuft und läuft es. Nach knapp einer Dreiviertelstunde habe ich abgebrochen. In der Datenbank sind Einträge drin aber wohl nicht alle.
Das ist echt wie verhext.


Gruß
Matthias

marce
Advanced Hacker
Advanced Hacker
Beiträge: 1159
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: SQL beim schreiben sehr sehr langsam

Beitrag von marce » 28. Okt 2019, 09:41

... sollten sich aber die Workflows bei Dir nicht von Heute auf Morgen geändert haben, sehr wohl aber das Verhalten des Systems sollte man ggf. doch auch nochmals genauer die Hardware anschauen.

Antworten