五一前,一个DBA同事反馈,在日常环境中删除一个大的slow log文件(假设文件大小10G以上吧),然后在MySQL中执行flush slow logs,会发现mysqld hang住。
今天尝试着重现了此问题,这里简要分析下原因。
重现步骤:
1. 构造slow log (将long_query_time设成了0);
2. 观察删rm slow log瞬间,tps/qps变化;
3. 观察执行flush slow logs瞬间,tps/qps变化;
4. 记录flush slow logs执行时, pstack打出的调用栈情况;
第一步,没啥好说的。
第二步,tps/qps没啥变化。
第三步,会发现tps/qps瞬间跌0,如下所示:
[ 639s] threads: 32, tps: 1121.00, reads/s: 15843.98, writes/s: 4490.99[ 640s] threads: 32, tps: 792.99, reads/s: 10803.89, writes/s: 3150.97[ 641s] threads: 32, tps: 0.00, reads/s: 0.00, writes/s: 0.00[ 642s] threads: 32, tps: 0.00, reads/s: 0.00, writes/s: 0.00[ 643s] threads: 32, tps: 471.01, reads/s: 6860.08, writes/s: 1908.02
mysql命令行会发现,flush slow logs执行时间刚好为3s左右。
第四步,我们看下pstack的输出结果,只记录相关的:
610 Thread 5 (Thread 0x2afdc4101700 (LWP 30762)):611 #00x0000003c6e40a7d6 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0612 #10x0000000000825135 in inline_mysql_rwlock_rdlock ()613 #20x0000000000838004 in LOGGER::lock_shared() ()614 #30x00000000008283bf in LOGGER::slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()615 #40x0000000000832b30 in slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()616 #50x0000000000609f23 in log_slow_statement(THD*) ()617 #60x00000000006099d1 in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()618 #70x0000000000606e02 in do_command(THD*) ()619 #80x00000000006f070f in do_handle_one_connection(THD*) ()620 #90x00000000006f020d in handle_one_connection ()621 #10 0x0000003c6e4077f1 in start_thread () from /lib64/libpthread.so.0622 #11 0x0000003c6e0e570d in clone () from /lib64/libc.so.6623 Thread 4 (Thread 0x2afdd0080700 (LWP 30763)):624 #00x0000003c6e40a7d6 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0625 #10x0000000000825135 in inline_mysql_rwlock_rdlock ()626 #20x0000000000838004 in LOGGER::lock_shared() ()627 #30x00000000008283bf in LOGGER::slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()628 #40x0000000000832b30 in slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()629 #50x0000000000609f23 in log_slow_statement(THD*) ()630 #60x00000000006099d1 in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()631 #70x0000000000606e02 in do_command(THD*) ()632 #80x00000000006f070f in do_handle_one_connection(THD*) ()633 #90x00000000006f020d in handle_one_connection ()634 #10 0x0000003c6e4077f1 in start_thread () from /lib64/libpthread.so.0635 #11 0x0000003c6e0e570d in clone () from /lib64/libc.so.6636 Thread 3 (Thread 0x2afdd0101700 (LWP 30764)):637 #00x0000003c6e40a7d6 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0638 #10x0000000000825135 in inline_mysql_rwlock_rdlock ()639 #20x0000000000838004 in LOGGER::lock_shared() ()640 #30x00000000008283bf in LOGGER::slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()641 #40x0000000000832b30 in slow_log_print(THD*, char const*, unsigned int, unsigned long long) ()642 #50x0000000000609f23 in log_slow_statement(THD*) ()643 #60x00000000006099d1 in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()644 #70x0000000000606e02 in do_command(THD*) ()645 #80x00000000006f070f in do_handle_one_connection(THD*) ()646 #90x00000000006f020d in handle_one_connection ()647 #10 0x0000003c6e4077f1 in start_thread () from /lib64/libpthread.so.0648 #11 0x0000003c6e0e570d in clone () from /lib64/libc.so.6649 Thread 2 (Thread 0x2afe18080700 (LWP 30855)):650 #00x0000003c6e40e54d in close () from /lib64/libpthread.so.0651 #10x00000000008f56ed in my_close ()652 #20x0000000000825c16 in inline_mysql_file_close ()653 #30x000000000082b305 in MYSQL_LOG::close(unsigned int) ()654 #40x000000000082b634 in MYSQL_QUERY_LOG::reopen_file() ()655 #50x0000000000828283 in LOGGER::flush_slow_log() ()656 #60x000000000071d8fc in reload_acl_and_cache(THD*, unsigned long, TABLE_LIST*, int*) ()657 #70x0000000000610200 in mysql_execute_command(THD*) ()658 #80x000000000061534d in mysql_parse(THD*, char*, unsigned int, Parser_state*) ()659 #90x00000000006086a0 in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()660 #10 0x0000000000606e02 in do_command(THD*) ()661 #11 0x00000000006f070f in do_handle_one_connection(THD*) ()662 #12 0x00000000006f020d in handle_one_connection ()663 #13 0x0000003c6e4077f1 in start_thread () from /lib64/libpthread.so.0664 #14 0x0000003c6e0e570d in clone () from /lib64/libc.so.6
会发现Thread 2在执行flush slow logs操作,其他的线程都在等待锁LOCK_log上边。
背后的原因其实很简单,在shell中执行rm slow log操作时,由于mysqld仍有文件句柄打开此文件,所以实际上此时文件并未删除。执行flush logs操作,其实际执行的是1)close;2)open 操作(logger.flush_slow_log -> mysql_slow_log.reopen_file),在close操作执行时,文件系统真正删除文件,此时该线程占用着LOCK_log锁。
删除时会执行刷脏(当然我构造这个场景很极端,基本所有slow log文件的内容都在文件系统缓存中),这个会很耗时间,比如我执行这个语句耗了3s。此时间段内,如果连接发来的语句需要记log(server层的log:slow log/binlog/general log共有LOCK_log这把锁)就会处于等待状态,那么系统对外的反应就是hang住了。
flush slow logs中调用执行的close所需时间和文件大小、以及文件系统缓存中该文件脏页比例都有关系,比如我在执行flush slow logs前使用sysctl vm.drop_caches=3清空
了文件系统缓存的话,同样大小的flush slow logs操作执行时间是0.42s,相应的阻塞时间也会减少不少。
可以考虑在slow logs的文件句柄上执行posix_fadvise调用,促使不会缓存很大的log文件内容(slow log也没啥需要缓存的),这有篇霸爷的文章,可以参考下 posix_fadvise清除缓存的误解和改进措施 。
另外,peter在07年就讨论过这个问题, Be careful rotating MySQL logs 其给出的建议是先mv file,然后flush logs,再执行删除文件的操作,让真正的删除行为由自己而不是mysqld完成。比较遗憾的是,五年过去了,LOCK_log这把锁的问题还没有完整的解决掉。
PS:
文章结尾记一点备忘,通过close/rm操作删除一个10G大小的文件,在执行sysctl vm.drop_caches=3清空缓存后,此操作的耗时仍在百毫秒量级(我的机器上是200ms+),其背后做了什么事情还需要找内核组的同事了解下。

MysqloffersVariousStorageEngines, EverySuitedfordifferentusecases: 1) InnoDbisidealforApplicationsNeedingaCidComplianceandHighConcurrency, SupportingingTransactions und MisseractersactionSactions.2) MyisamisBestforread-Heavyworks, Fehlen von Abladungen, mangelndtransaktionen

Zu den allgemeinen Sicherheitslücken in MySQL gehören die SQL -Injektion, schwache Passwörter, unsachgemäße Berechtigungskonfiguration und eine nicht updierte Software. 1. SQL -Injektion kann durch Verwendung von Vorverarbeitungsanweisungen verhindert werden. 2. Schwache Passwörter können vermieden werden, indem Sie starke Kennwortstrategien verwenden. 3. Eine unsachgemäße Berechtigungskonfiguration kann durch regelmäßige Überprüfung und Anpassung der Benutzerberechtigungen behoben werden. 4. Die nicht updierte Software kann durch regelmäßiges Überprüfen und Aktualisieren der MySQL -Version gepatcht werden.

Das Identifizieren langsamer Abfragen in MySQL kann erreicht werden, indem langsame Abfrageprotokolle aktiviert und Schwellenwerte festgelegt werden. 1. Aktivieren Sie langsame Abfrageprotokolle und setzen Sie Schwellenwerte. 2. Sehen und analysieren Sie langsame Abfrageprotokolldateien und verwenden Sie Tools wie MySQLDUMPSLOW oder PT-Query-Digest für eingehende Analysen. 3. Die Optimierung langsamer Abfragen kann durch Indexoptimierung, Umschreiben von Abfragen und Vermeidung der Verwendung von Select*erreicht werden.

Um die Gesundheit und Leistung von MySQL -Servern zu überwachen, sollten Sie auf Systemgesundheit, Leistungsmetriken und Abfrageausführung achten. 1) Überwachen Sie die Systemgesundheit: Verwenden Sie die Befehle von Top-, HTOP- oder ShowglobalStatus, um CPU-, Speicher-, Festplatten -E/A- und Netzwerkaktivitäten anzuzeigen. 2) Leistungsindikatoren verfolgen: Überwachen Sie die Schlüsselindikatoren wie die Abfragennummer pro Sekunde, die durchschnittliche Abfragezeit und den Cache -Hit -Rate. 3) Optimierung der Abfrageausführung sicherstellen: Aktivieren Sie langsame Abfragenprotokolle, zeichnen und optimieren Sie Abfragen, deren Ausführungszeit den festgelegten Schwellenwert überschreitet.

Der Hauptunterschied zwischen MySQL und Mariadb ist Leistung, Funktionalität und Lizenz: 1. MySQL wird von Oracle entwickelt und Mariadb ist seine Gabel. 2. Mariadb kann in Umgebungen mit hoher Last besser abschneiden. 3.MariADB bietet mehr Speichermotoren und Funktionen. 4.Mysql nimmt eine doppelte Lizenz an, und Mariadb ist vollständig Open Source. Die vorhandene Infrastruktur, Leistungsanforderungen, funktionale Anforderungen und Lizenzkosten sollten bei der Auswahl berücksichtigt werden.

MySQL verwendet eine GPL -Lizenz. 1) Die GPL -Lizenz ermöglicht die freie Verwendung, Änderung und Verteilung von MySQL, aber die geänderte Verteilung muss GPL entsprechen. 2) Gewerbelizenzen können öffentliche Änderungen vermeiden und für gewerbliche Anwendungen geeignet sind, die Vertraulichkeit erfordern.

Die Situationen bei der Auswahl von InnoDB anstelle von MyISAM umfassen: 1) Unterstützung der Transaktion, 2) hohe Genauigkeitsumgebung, 3) hohe Datenkonsistenz; Umgekehrt umfasst die Situation bei der Auswahl von MyISAM: 1) hauptsächlich Lesen von Operationen, 2) Es ist keine Transaktionsunterstützung erforderlich. InnoDB ist für Anwendungen geeignet, die eine hohe Datenkonsistenz und Transaktionsverarbeitung erfordern, z. B. E-Commerce-Plattformen, während MyISAM für lessintensive und transaktionsfreie Anwendungen wie Blog-Systeme geeignet ist.

In MySQL besteht die Funktion von Fremdschlüssel darin, die Beziehung zwischen Tabellen herzustellen und die Konsistenz und Integrität der Daten zu gewährleisten. Fremdeschlüssel behalten die Wirksamkeit von Daten durch Referenzintegritätsprüfungen und Kaskadierungsvorgänge bei. Achten Sie auf die Leistungsoptimierung und vermeiden Sie bei der Verwendung häufige Fehler.


Heiße KI -Werkzeuge

Undresser.AI Undress
KI-gestützte App zum Erstellen realistischer Aktfotos

AI Clothes Remover
Online-KI-Tool zum Entfernen von Kleidung aus Fotos.

Undress AI Tool
Ausziehbilder kostenlos

Clothoff.io
KI-Kleiderentferner

Video Face Swap
Tauschen Sie Gesichter in jedem Video mühelos mit unserem völlig kostenlosen KI-Gesichtstausch-Tool aus!

Heißer Artikel

Heiße Werkzeuge

MinGW – Minimalistisches GNU für Windows
Dieses Projekt wird derzeit auf osdn.net/projects/mingw migriert. Sie können uns dort weiterhin folgen. MinGW: Eine native Windows-Portierung der GNU Compiler Collection (GCC), frei verteilbare Importbibliotheken und Header-Dateien zum Erstellen nativer Windows-Anwendungen, einschließlich Erweiterungen der MSVC-Laufzeit zur Unterstützung der C99-Funktionalität. Die gesamte MinGW-Software kann auf 64-Bit-Windows-Plattformen ausgeführt werden.

Herunterladen der Mac-Version des Atom-Editors
Der beliebteste Open-Source-Editor

VSCode Windows 64-Bit-Download
Ein kostenloser und leistungsstarker IDE-Editor von Microsoft

SublimeText3 Linux neue Version
SublimeText3 Linux neueste Version

DVWA
Damn Vulnerable Web App (DVWA) ist eine PHP/MySQL-Webanwendung, die sehr anfällig ist. Seine Hauptziele bestehen darin, Sicherheitsexperten dabei zu helfen, ihre Fähigkeiten und Tools in einem rechtlichen Umfeld zu testen, Webentwicklern dabei zu helfen, den Prozess der Sicherung von Webanwendungen besser zu verstehen, und Lehrern/Schülern dabei zu helfen, in einer Unterrichtsumgebung Webanwendungen zu lehren/lernen Sicherheit. Das Ziel von DVWA besteht darin, einige der häufigsten Web-Schwachstellen über eine einfache und unkomplizierte Benutzeroberfläche mit unterschiedlichen Schwierigkeitsgraden zu üben. Bitte beachten Sie, dass diese Software
