一次CDN源站負載高的問題排查及解決
我們的CDN架構如下:
我們的CDN緩存策略是:使用源站的緩存策略,源站緩存策略是365天
。
首先查看Apache的訪問日誌:
錯誤日誌裏有大量的回源,內部程序邏輯是:如果文件不存在,就回去COS裏去取,然後存放到源站一份。源站上有定期清理磁盤的程序。
正常情況下,回源不會有這麽多,所以去查看一下cdn的緩存情況。
1、獲取CDN的節點IP:
命令:dig pic1.xxxx.com
2、通過指定節點,查看訪問資源的命中情況:
看到最後的結果都是MiSS,理論上兩個節點有一個HIT即可。
在測試過程中,偶爾有HIT,絕大多數的情況是MISS,即沒有命中,就會導致訪問回源。說明CDN上並沒有緩存住資源,絕大多數訪問直接打到源站上,所以源站負載撐不住了。
聯系CDN服務商,服務商回復說最近新增加了多個邊緣節點,可能會有一些問題導致以上情況,但是最近情況仍在繼續,為了避免再次出現問題,我們將CDN由迅達雲切換到了騰訊雲上,問題暫時得到解決。
一次CDN源站負載高的問題排查及解決
相關推薦
一次CDN源站負載高的問題排查及解決
https hit 兩個 ext 繼續 都是 cto 但是 指定節點 最近總是收到後端的CDN源站的負載高的報警,Apache經常會觸發重啟。於是啟動排查問題。 我們的CDN架構如下: 我們的CDN緩存策略是:使用源站的緩存策略,源站緩存策略是365天。 首先查看Apach
一次慢查詢語句的問題定位及解決方案
問題現象:前幾天在專案上線過程中,發現有一個頁面無法正確獲取資料,經排查原來是介面呼叫超時,而最後發現是因為SQL查詢長達到20多秒而導致了問題的發生。複雜SQL語句的構成:類比的語句來描述當時的場景,可以表達如下:SELECT * FROM a_table AS a LE
一次異常記憶體消耗問題的診斷及解決
這裡有一個誤解,CPID是指建立這個共享記憶體段的程序號,常見時間是2:29分,LPID是最後一次獲取和使用這個共享記憶體段的程序號,使用時間是2:29分。因為Oracle在建立了這個段之後這個程序的使命也就完成了,可以簡單的理解為類似一個sh指令碼執行完成後正常退出的過程,通理,最後一次使用這個共享記憶體段
一次線上機器load負載過高報警問題排查及其後續處理
問題來源:從3.14號開始陸續收到線上一臺機器的負載過高報警 問題排查 : 於是對gc、堆記憶體、load負載、cpu使用情況等進行了統計分析。 gc時間圖示 堆記憶體使用情況: load負載 cpu使用率 通過以上對gc的統計,
記一次 MongoDB 佔用 CPU 過高問題的排查
1. 引言 今天檢視監控無意間突然發現自己的伺服器上,CPU 佔用率飆升到 100%,load 升到 10 以上,登入的響應已經達到半分鐘。 馬上執行 top,發現主要是 mongodb 佔用了大量
記一次yarn導致cpu飆高的異常排查經歷
yarn就先不介紹了,這次排坑經歷還是有收穫的,從日誌到堆疊資訊再到原始碼,很有意思,下面聽我說 問題描述: 叢集一臺NodeManager的cpu負載飆高。 程序還在但是看日誌已經不再向ResourceManager傳送心跳,不斷重複下文2的動作。 心跳停止一段時間後會重連上RM但是cpu仍然很高,再過
一次FGC導致CPU飆高的排查過程
今天測試團隊反饋說,服務A的響應很慢,我在想,測試環境也會慢?於是我自己用postman請求了一下介面,真的很慢,竟然要2s左右,正常就50ms左右的。 於是去測試伺服器看了一下,發現伺服器負載很高,並且該服務A佔了很高的cpu。先用
記一次服務器IO過高處理過程
linux 服務器 緩沖區 io負載 記一次服務器IO過高處理過程 一、背景 在一次上線升級後,發現兩臺tomcat服務器的IOwait一直超過100ms,高峰時甚至超過300ms,檢查服務器發現CPU負載,內存的使用率都不高。問題可能出現在硬盤讀寫,而且那塊硬盤除了寫日誌外,沒有其他
記一次內存泄漏問題排查
set mage let tac rtb repo int exc adt 通過MonitoSDK的Sample App進行試用時,發現存在部分內存泄漏的情況,leakcanary直接彈出提示如下 可以看到MonitorDBActivity的instance導致泄漏。
一次怪異的業務卡頓排查過程
seq 用法 ipv 亂序 等於 瀏覽器 追蹤 cli tcp 上班的時候,突然被測試和產品加入了一個討論組,說有個問題需要我排查下,一頭霧水,於是開始進行了解和排查。 故障現象????客服人員使用該系統的其中幾個功能模塊的時候,彈出的溝通窗口會卡頓,並且關閉當前彈窗,返
一次SocketException:Connection reset 異常排查
端口 沒有 pipe eset 當前 發送 情況下 .net 指定端口 本次需求,並沒有修改邏輯,為什麽會出現這種情況呢?只是網絡關系,還是跟代碼有關呢。我有幾個疑問: 什麽情況下會產生Connection reset? 長連接中,向server發請求,是先發送數據的,如
記一次站點被掛馬問題排查
源碼 yahoo 首頁 阿裏 zhang 並且 加密 體積 ref 起因,在下班準備回家之際,收到幾條朋友發來的信息,說他的網站在百度搜索做信息流廣告推廣,但是從百度搜索點擊打開就會跳轉的×××,讓我幫忙排查下問題,是不是被掛馬了,於是乎就開始了後面的故事 為了保護網站
一次線上記憶體洩漏的問題排查
上線了好久的專案今天突然出現cpu到達100% 的情況,先將專案緊急重啟,恢復正常後登入伺服器排查gc日誌,發現存在記憶體洩漏的情況。 top命令檢視程序情況,top -Hp pid檢視執行緒,再jstack匯出日誌。過程匆忙,忘了截圖 搜尋jsatck日誌看到許多執行緒阻塞在這一行程式碼 基本可以
Linux(2)---記錄一次線上服務 CPU 100%的排查過程
Linux(2)---記錄一次線上服務 CPU 100%的排查過程 當時產生CPU飆升接近100%的原因是因為專案中的websocket時時斷開又重連導致CPU飆升接近100% 。如何排查的呢 是通過日誌輸出錯誤資訊: 得知websocket時時重新 連線的資訊,然後找到原因 解決了。 當然這
也許是史上最全的一次CDN詳解
CDN 全稱:Content Delivery Network或Content Ddistribute Network,即內容分發網路 <img src="https://pic2.zhimg.com/v2-5521af4d1343371f4e9dc58cbb8ee9d4_b.j
記一次Mysql佔用記憶體過高的優化過程
一.環境說明: 作業系統:CentOS 6.5 x86_64 資料庫:Mysql 5.6.22 伺服器:阿里雲VPS,32G Mem,0 swap 二.問題情況: 1.某日發現公司線上系統的Mysql某個例項的從庫長時間記憶體佔用達到60%如下圖 2.於是開始
一次JVM_OLD區佔用過高、頻繁Full GC的解決過程
最近,公司網站頻繁報警,JVM_OLD佔用過高,線上訪問超時嚴重,針對這個問題著實頭疼了一把,不過最終還是解決了,下面說下解決的過程。 1,首先 登到線上機器上去,top命令,檢視當前機器的負載,檢視當前哪個程序在消耗資源。 Shell 1
記一次ss程序莫名其妙掛掉排查
情況是這樣的,我這邊辦公環境是已經科學上網了,也就是在路由器裡面配置了ss,大概有20臺電腦同時在這個路由器下面,辦公上網。斷網情況是在中午發生的,就是莫名其妙的斷網了,根據經驗猜是不是ss程序掛了,路由器連不上了,就斷網了。登上伺服器一看,果然程序沒了,啟動後並沒多想。可能是人多了 一個程序扛不住了?為了
MySQL案例:一次單核CPU佔用過高問題的處理
客戶現場反饋,top的檢查結果中,一個CPU的佔用一直是100%。實際上現場有4個CPU,而且這個伺服器是mysql專屬伺服器。 我的第一反應是io_thread一類的引數設定有問題,檢查以後發現read和write的thread設定都是4,這和CPU數一致,因此可以斷定這並不是單顆CPU佔用過高的問題。
資料庫實戰案例—————記一次TempDB暴增的問題排查
前言 很多時候資料庫的TempDB、日誌等檔案的暴增可能導致磁碟空間被佔滿,如果日常配置不到位,往往會導致資料庫故障,業務被迫中斷。 這種檔案暴增很難排查,經驗不足的一些運維人員可能更是無法排查具體原因,導致問題不能徹底解決。 場景描述 客戶系統比較穩定,用了5臺機器做了AlwaysOn高