关于删除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 Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。
Undress AI Tool
免費脫衣圖片
Clothoff.io
AI脫衣器
AI Hentai Generator
免費產生 AI 無盡。
熱門文章
熱工具
記事本++7.3.1
好用且免費的程式碼編輯器
SublimeText3漢化版
中文版，非常好用
禪工作室 13.0.1
強大的PHP整合開發環境
Dreamweaver CS6
視覺化網頁開發工具
SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)
熱門話題
拼多多買過的東西在哪裡查看記錄 查看買過的商品記錄的方法
Mar 12, 2024 pm 07:20 PM
拼多多軟體內提供的商品好物非常多，隨時隨地想買就買，而且每一件商品品質都是嚴格把關的，件件商品都是正品，不同還有非常多優惠的購物折扣，讓大家網購根本停不下來。輸入手機號碼在線登錄，在線添加多個收貨地址和聯繫方式，可以隨時查看最新的物流動態，不同品類的商品板塊都是開放的，搜索上下滑動選購下單，足不出戶輕鬆體驗便捷的網購服務，還能查看所有的購買記錄，包括自己買過的商品，數十個購物紅包、優惠券免費領取使用，現在小編在線詳細為拼多多用戶們帶來查看買過的商品記錄的方法。 1.打開手機，點選拼多多圖標，
Stable Diffusion 3論文終於發布，架構細節大揭秘，對復現Sora有幫助？
Mar 06, 2024 pm 05:34 PM
StableDiffusion3的论文终于来了！这个模型于两周前发布，采用了与Sora相同的DiT（DiffusionTransformer）架构，一经发布就引起了不小的轰动。与之前版本相比，StableDiffusion3生成的图质量有了显著提升，现在支持多主题提示，并且文字书写效果也得到了改善，不再出现乱码情况。StabilityAI指出，StableDiffusion3是一个系列模型，其参数量从800M到8B不等。这一参数范围意味着该模型可以在许多便携设备上直接运行，从而显著降低了使用AI
你是否真正掌握了座標系轉換？自動駕駛離不開的多感測器問題
Oct 12, 2023 am 11:21 AM
一先導與重點文章主要介紹自動駕駛技術中幾種常用的座標系統，以及他們之間如何完成關聯與轉換，最終建構出統一的環境模型。這裡重點理解自車到相機剛體轉換(外參)，相機到影像轉換(內參)，影像到像素有單位轉換。 3d向2d轉換會有對應的畸變，平移等。重點：自車座標系相機機體座標系需要被重寫的是：平面座標系像素座標系難點：要考慮影像畸變，去畸變和加畸變都是在像平面上去補償二簡介視覺系統一共有四個座標系：像素平面座標系（u,v）、影像座標系（x,y）、相機座標系（）與世界座標系（）。每種座標系之間均有聯繫，
自動駕駛與軌跡預測看這篇就夠了！
Feb 28, 2024 pm 07:20 PM
軌跡預測在自動駕駛中承擔著重要的角色，自動駕駛軌跡預測是指透過分析車輛行駛過程中的各種數據，預測車輛未來的行駛軌跡。作為自動駕駛的核心模組，軌跡預測的品質對於下游的規劃控制至關重要。軌跡預測任務技術堆疊豐富，需熟悉自動駕駛動/靜態感知、高精地圖、車道線、神經網路架構（CNN&GNN&Transformer）技能等，入門難度很高！許多粉絲期望能夠盡快上手軌跡預測，少踩坑，今天就為大家盤點下軌跡預測常見的一些問題和入門學習方法！入門相關知識1.預習的論文有沒有切入順序？ A：先看survey，p
從頭開始，逐步引導您安裝Flask，快速建立個人博客
Feb 19, 2024 pm 04:01 PM
從零開始，手把手教你安裝Flask和快速建立個人部落格作為一個喜歡寫作的人來說，擁有個人部落格是非常重要的。而Flask作為一個輕量級的PythonWeb框架，可以幫助我們快速建立一個簡潔而功能完善的個人部落格。在本文中，我將從零開始，手把手教你如何安裝Flask並快速建立個人部落格。第一步：安裝Python和pip在開始之前，我們需要先安裝Python和pi
DualBEV：大幅超越BEVFormer、BEVDet4D，開卷！
Mar 21, 2024 pm 05:21 PM
這篇論文探討了在自動駕駛中，從不同視角（如透視圖和鳥瞰圖）準確檢測物體的問題，特別是如何有效地從透視圖（PV）到鳥瞰圖（BEV）空間轉換特徵，這一轉換是透過視覺轉換（VT）模組實施的。現有的方法大致分為兩種策略：2D到3D和3D到2D轉換。 2D到3D的方法透過預測深度機率來提升密集的2D特徵，但深度預測的固有不確定性，尤其是在遠處區域，可能會引入不準確性。而3D到2D的方法通常使用3D查詢來採樣2D特徵，並透過Transformer學習3D和2D特徵之間對應關係的注意力權重，這增加了計算和部署的
首個多視角自動駕駛場景影片產生世界模型 | DrivingDiffusion: BEV資料與模擬新思路
Oct 23, 2023 am 11:13 AM
作者的一些個人思考在自動駕駛領域，隨著BEV-based子任務/端到端方案的發展，高品質的多視圖訓練資料和相應的模擬場景建立愈發重要。針對當下任務的痛點，「高品質」可以解耦成三個面向：不同維度上的長尾場景：如障礙物資料中近距離的車輛以及切車過程中精準的朝向角，以及車道線資料中不同曲率的彎道或較難收集的匝道/匯入/合流等場景。這些往往靠大量的資料收集和複雜的資料探勘策略，成本高昂。 3D真值-影像的高度一致：當下的BEV資料取得往往受到感測器安裝/標定，高精地圖以及重建演算法本身的誤差影響。這導致了我
GSLAM | 一個通用的SLAM架構和基準
Oct 20, 2023 am 11:37 AM
突然發現了一篇19年的論文GSLAM：AGeneralSLAMFrameworkandBenchmark開源程式碼：https://github.com/zdzhaoyong/GSLAM直接上全文，感受這項工作的品質吧~1摘要SLAM技術最近取得了許多成功，並吸引了高科技公司的關注。然而，如何同一現有或新興演算法的介面，一級有效地進行關於速度、穩健性和可移植性的基準測試仍然是問題。本文，提出了一個名為GSLAM的新型SLAM平台，它不僅提供評估功能，還為研究人員提供了快速開發自己的SLAM系統的有用
