关于删除MySQL Logs的一点记录
五一前,一个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+),其背后做了什么事情还需要找内核组的同事了解下。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









Pinduoduo ソフトウェアは多くの優れた製品を提供し、いつでもどこでも購入でき、各製品の品質は厳しく管理され、すべての製品は正規品であり、多くの優遇ショッピング割引があり、誰もがオンラインで買い物をすることができます。携帯電話番号を入力してオンラインにログインし、オンラインで複数の配送先住所や連絡先情報を追加し、最新の物流動向をいつでも確認できます さまざまなカテゴリの商品セクションが開き、検索して上下にスワイプして購入および注文することができます家から出ることなく利便性を体験することができます.オンライン ショッピング サービスでは、購入した商品を含むすべての購入記録を確認することもでき、数十のショッピング赤い封筒とクーポンを無料で受け取ることもできます.今回、編集者は Pinduoduo ユーザーに詳細なオンライン サービスを提供しました購入した製品の記録を表示する方法。 1. 携帯電話を開き、Pinduoduo アイコンをクリックします。

StableDiffusion3 の論文がついに登場しました!このモデルは2週間前にリリースされ、Soraと同じDiT(DiffusionTransformer)アーキテクチャを採用しており、リリースされると大きな話題を呼びました。前バージョンと比較して、StableDiffusion3で生成される画像の品質が大幅に向上し、マルチテーマプロンプトに対応したほか、テキスト書き込み効果も向上し、文字化けが発生しなくなりました。 StabilityAI は、StableDiffusion3 はパラメータ サイズが 800M から 8B までの一連のモデルであると指摘しました。このパラメーター範囲は、モデルを多くのポータブル デバイス上で直接実行できることを意味し、AI の使用を大幅に削減します。

最初のパイロットおよび重要な記事では、主に自動運転技術で一般的に使用されるいくつかの座標系と、それらの間の相関と変換を完了し、最終的に統合環境モデルを構築する方法を紹介します。ここでの焦点は、車両からカメラの剛体への変換 (外部パラメータ)、カメラから画像への変換 (内部パラメータ)、および画像からピクセル単位への変換を理解することです。 3D から 2D への変換には、対応する歪み、変換などが発生します。要点:車両座標系とカメラ本体座標系を平面座標系とピクセル座標系に書き換える必要がある 難易度:画像の歪みを考慮する必要がある 歪み補正と歪み付加の両方を画面上で補正する2. はじめに ビジョンシステムには、ピクセル平面座標系 (u, v)、画像座標系 (x, y)、カメラ座標系 ()、世界座標系 () の合計 4 つの座標系があります。それぞれの座標系には関係性があり、

ゼロから始めて、Flask をインストールし、個人ブログをすぐに構築する方法を段階的に説明します。書くことが好きな人にとって、個人ブログを持つことは非常に重要です。軽量の Python Web フレームワークである Flask は、シンプルで完全に機能する個人ブログを迅速に構築するのに役立ちます。この記事では、ゼロから始めて、Flask をインストールして個人ブログを迅速に構築する方法を段階的に説明します。ステップ 1: Python と pip をインストールする 開始する前に、まず Python と pi をインストールする必要があります

自動運転では軌道予測が重要な役割を果たしており、自動運転軌道予測とは、車両の走行過程におけるさまざまなデータを分析し、将来の車両の走行軌跡を予測することを指します。自動運転のコアモジュールとして、軌道予測の品質は下流の計画制御にとって非常に重要です。軌道予測タスクには豊富な技術スタックがあり、自動運転の動的/静的知覚、高精度地図、車線境界線、ニューラル ネットワーク アーキテクチャ (CNN&GNN&Transformer) スキルなどに精通している必要があります。始めるのは非常に困難です。多くのファンは、できるだけ早く軌道予測を始めて、落とし穴を避けたいと考えています。今日は、軌道予測に関するよくある問題と入門的な学習方法を取り上げます。関連知識の紹介 1. プレビュー用紙は整っていますか? A: まずアンケートを見てください。

この論文では、自動運転においてさまざまな視野角 (遠近法や鳥瞰図など) から物体を正確に検出するという問題、特に、特徴を遠近法 (PV) 空間から鳥瞰図 (BEV) 空間に効果的に変換する方法について検討します。 Visual Transformation (VT) モジュールを介して実装されます。既存の手法は、2D から 3D への変換と 3D から 2D への変換という 2 つの戦略に大別されます。 2D から 3D への手法は、深さの確率を予測することで高密度の 2D フィーチャを改善しますが、特に遠方の領域では、深さ予測に固有の不確実性により不正確さが生じる可能性があります。 3D から 2D への方法では通常、3D クエリを使用して 2D フィーチャをサンプリングし、Transformer を通じて 3D と 2D フィーチャ間の対応のアテンション ウェイトを学習します。これにより、計算時間と展開時間が増加します。

著者の個人的な考えの一部 自動運転の分野では、BEV ベースのサブタスク/エンドツーエンド ソリューションの開発に伴い、高品質のマルチビュー トレーニング データとそれに対応するシミュレーション シーンの構築がますます重要になってきています。現在のタスクの問題点に対応して、「高品質」は 3 つの側面に分離できます。 さまざまな次元のロングテール シナリオ: 障害物データ内の近距離車両、車両切断中の正確な進行角、車線などラインデータ 曲率の異なるカーブやランプ・合流・合流などの撮影が難しいシーン。これらは多くの場合、大量のデータ収集と複雑なデータ マイニング戦略に依存しており、コストがかかります。 3D 真の値 - 一貫性の高い画像: 現在の BEV データ取得は、センサーの設置/校正、高精度マップ、再構成アルゴリズム自体のエラーの影響を受けることがよくあります。これが私を導いた

19 年前の論文を突然発見 GSLAM: A General SLAM Framework and Benchmark オープンソース コード: https://github.com/zdzhaoyong/GSLAM 全文に直接アクセスして、この作品の品質を感じてください ~ 1 抽象的な SLAM テクノロジー近年多くの成功を収め、多くのハイテク企業の注目を集めています。ただし、既存または新たなアルゴリズムへのインターフェイスを使用して、速度、堅牢性、移植性に関するベンチマークを効果的に実行する方法は依然として問題です。この論文では、GSLAM と呼ばれる新しい SLAM プラットフォームを提案します。これは、評価機能を提供するだけでなく、研究者が独自の SLAM システムを迅速に開発するための有用な方法を提供します。
