通過測試發現對大表進行Optimize Table不會阻塞DML語句,它只會在文件發生切換的時候短暫鎖表。
表上索引很多的情況,執行Optimize Table會很慢,建議評估表空間回收后的大小,如果回收之后表變得較小,建議刪除索引之后進行操作。通過測試刪除索引后速度能快一倍。
在執行optimizer table的時候,從庫會一直延遲,直到主庫完成操作,從庫才會開始操作optimizer table。
到了正式操作的時候,我們按照測試的結果進行執行。前期都較為順利。大概在操作了1個小時之后,突然出現監控連接數告警。
可以看到當前我們設置最大的Thread數量為3000。結果瞬間達到了最大值。
通過命令行進入到數據庫。發現大量的查詢語句在等待Waiting for table metadata lock。
這些查詢語句也都在查詢我們操作Optimize Table的表。沒有任何辦法數據庫就這樣全局hang死了。不停的有連接上來執行查詢操作,就要等待這個Waiting for table metadata lock。只能把源頭Optimize Table停掉。在停掉了之后,系統立馬恢復了正常。
在這次操作的過程中,其實前期也有完整的測試,但是還是出現了這樣的情況,一個很大的原因是我們沒辦法模擬生產的負載情況。
應用程序還有一個特點,一旦堵塞了住了,就會不停的連接,這樣的程序其實就是一個瘋狂壓測程序。
所以做這樣的測試,需要我們思考到一點:
我們需要捕捉到生產的流量,然后在測試的時候進行回放重演。
那么怎么進行流量的捕捉,一個簡單的方法就是使用tcpdump捕捉3306端口的信息。然后使用解析出數據,進行重演。此類方案比較多,比較令人熟悉的是tcpcopy這個解決方案。
那么最終的一個解決辦法就是,我們可以先在從庫上進行操作。這里的操作需要加上sql_log_bin = 0不記錄binlog日志。等從庫回收之后,再找個機會進行主從切換。
更多精彩干貨分享
點擊下方名片關注
IT那活兒
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/129909.html
摘要:為了一探究竟,于是開啟了這次應用性能調優之旅。使用即時編譯器和都能輕輕松松的讓你的應用程序在不用做任何修改的情況下,直接提高或者更高的性能。 這是一份事后的總結。在經歷了調優過程踩的很多坑之后,我們最終完善并實施了初步的性能測試方案,通過真實的測試數據歸納出了 Laravel 開發過程中的一些實踐技巧。 0x00 源起 最近有同事反饋 Laravel 寫的應用程序響應有點慢、20幾個并...
摘要:用法顯示當前的幫助信息不輸出任何信息顯示當前版本強制輸出禁用輸出不進行交互運行環境詳細輸出普通更加詳細可用命令全局命令清除編譯生成的文件,相當于的反操作將站點設為維護狀態顯示當前運行環境來源于 laravel artisan 用法 $ php artisan Laravel Framework version 5.1.46 (LTS) Usage: command [options] ...
摘要:具體來說,就是在寫數據庫的時候同時寫一份數據到緩存集群里,然后用緩存集群來承載大部分的讀請求。各種精妙的架構設計因此一篇小文頂多具有拋磚引玉的效果但是數據庫優化的思想差不多就這些了 前言 數據庫優化一方面是找出系統的瓶頸,提高MySQL數據庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要盡可能的節約系統資源,以便讓系統提供更大的負荷. 1. 優化一覽...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20