自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

記一次線上崩潰問題的排查過程

開發(fā) 前端
由于正值雙十一期間,業(yè)務(wù)以穩(wěn)定為主,線上服務(wù)崩潰,這可不是一件小事,趕緊登陸線上服務(wù)器,分析原因,迅速解決。

 [[436425]]

大家好,我是雨樂!

前幾天,突然收到報(bào)警,線上服務(wù)崩潰,然后自動重啟。

由于正值雙十一期間,業(yè)務(wù)以穩(wěn)定為主,線上服務(wù)崩潰,這可不是一件小事,趕緊登陸線上服務(wù)器,分析原因,迅速解決。

借助這篇文章,記錄下整個(gè)崩潰的分析和解決過程。

收到報(bào)警

上午上班后,正在劃水,突然收到郵件報(bào)警,如下:

問題分析

馬上登錄線上服務(wù)器,gdb調(diào)試堆棧信息。

堆棧信息如下:

  1. #0  0x0000003ab9a324f5 in raise () from /lib64/libc.so.6 
  2. #1  0x0000003ab9a33cd5 in abort () from /lib64/libc.so.6 
  3. #2  0x0000003abcebea8d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 
  4. #3  0x0000003abcebcbe6 in ?? () from /usr/lib64/libstdc++.so.6 
  5. #4  0x0000003abcebcc13 in std::terminate() () from /usr/lib64/libstdc++.so.6 
  6. #5  0x0000003abcebcd32 in __cxa_throw () from /usr/lib64/libstdc++.so.6 
  7. #6  0x00000000006966bf in Json::throwRuntimeError(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () 
  8. #7  0x0000000000681019 in Json::Reader::readValue() () 
  9. #8  0x000000000068277c in Json::Reader::readArray(Json::Reader::Token&) () 
  10. #9  0x0000000000681152 in Json::Reader::readValue() () 
  11. #10 0x00000000006823a6 in Json::Reader::readObject(Json::Reader::Token&) () 
  12. #11 0x00000000006810f5 in Json::Reader::readValue() () 
  13. #12 0x0000000000680e6e in Json::Reader::parse(char const*, char const*, Json::Value&, bool) () 
  14. #13 0x0000000000680c52 in Json::Reader::parse(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, Json::Value&, bool) () 
  15. ...... 

在上面堆棧信息中可以看到在調(diào)用Json::Reader::parse后經(jīng)過Json::Reader::readValue等調(diào)用,最后再調(diào)用Json::Reader::readValue時(shí)調(diào)用Json::throwRuntimeError拋出異常。

查看調(diào)用Json::throwRuntimeError函數(shù)的地方:

  1. src/lib_json/json_writer.cpp:    throwRuntimeError("commentStyle must be 'All' or 'None'"); 
  2. src/lib_json/json_reader.cpp:  if (stackDepth_g >= stackLimit_g) throwRuntimeError("Exceeded stackLimit in readValue()."); 
  3. src/lib_json/json_reader.cpp:  if (stackDepth_ >= features_.stackLimit_) throwRuntimeError("Exceeded stackLimit in readValue()."); 
  4. src/lib_json/json_reader.cpp:    if (name.length() >= (1U<<30)) throwRuntimeError("keylength >= 2^30"); 
  5. src/lib_json/json_reader.cpp:    throwRuntimeError(errs); 
  6. src/lib_json/json_value.cpp:    throwRuntimeError( 
  7. src/lib_json/json_value.cpp:    throwRuntimeError( 
  8. src/lib_json/json_value.cpp:JSONCPP_NORETURN void throwRuntimeError(JSONCPP_STRING const& msg) 
  9. src/lib_json/json_valueiterator.inl:  throwRuntimeError("ConstIterator to Iterator should never be allowed."); 

進(jìn)入對應(yīng)的函數(shù)

  1. bool Reader::readValue() { 
  2.   if (stackDepth_g >= stackLimit_g) throwRuntimeError("Exceeded stackLimit in readValue()."); 
  3.   ++stackDepth_g; 
  4.   ... ... 
  5.   --stackDepth_g; 
  6.   return successful; 

發(fā)現(xiàn),在滿足條件

  1. stackDepth_g >= stackLimit_g 

的時(shí)候,會調(diào)用throwRuntimeError,那么分析下stackDepth_g和stackLimit_g的聲明定義:

  1. static int const stackLimit_g = 1000; 
  2.  
  3. static int stackDepth_g = 0; 

問題基本明了:

stackDepth_g是個(gè)靜態(tài)全局變量,線程不安全,而出問題的服務(wù)是多線程的

在此準(zhǔn)備吐槽下,筆者使用jsoncpp對象的時(shí)候,都是在線程內(nèi)部一個(gè)局部變量,因此不會存在多線程訪問同一個(gè)局部jsoncpp對象的時(shí)候,因此確定就是因?yàn)槿肿兞慷嗑€程訪問導(dǎo)致的。一個(gè)開源的項(xiàng)目,里面竟然有全局變量,這在規(guī)范里面是不被允許的。

然后谷歌搜索了下大家都有過類似的問題,再次吐槽下。

問題解決

解決崩潰問題,首先需要看看是不是使用方式的問題,或者找一個(gè)線程安全的接口,再或者用其他庫進(jìn)行替換。

修改jsoncpp源碼

為了解決線程安全的問題,有兩種方案:1、在操作全局變量的時(shí)候,加上mutex,這個(gè)無非對性能要求很高的業(yè)務(wù)一個(gè)致命打擊,為了提高業(yè)務(wù)性能,所以內(nèi)部鎖都使用其他方式進(jìn)行了優(yōu)化,比如mutex使用雙buffer方式進(jìn)行了替換,雖然mutex的一個(gè)加鎖解鎖過程也就100ns。

2、將上述全局變量放入Json對象中,這樣局部變量就不會存在崩潰現(xiàn)象,但是這種方案存在一個(gè)問題,就是改動點(diǎn)很大,且需要大量嚴(yán)格的測試,放棄。

所以綜合考慮上述兩點(diǎn),決定采用其他更安全可靠的方式來解決線上崩潰問題。

使用rapidjson

之所以采用rapidjson,是因?yàn)榫€上幾十個(gè)服務(wù),大部分都使用rapidjson,只有線上崩潰的這個(gè)服務(wù)等少數(shù)幾個(gè)服務(wù),因?yàn)闅v史原因,用的jsoncpp。

先介紹下rapidjson,下述內(nèi)容來自于rapidjson官網(wǎng):

  • RapidJSON 是一個(gè) C++ 的 JSON 解析器及生成器。它的靈感來自 RapidXml。
  • RapidJSON 小而全。它同時(shí)支持 SAX 和 DOM 風(fēng)格的 API。SAX 解析器只有約 500 行代碼。
  • RapidJSON 快。它的性能可與 strlen() 相比。可支持 SSE2/SSE4.2 加速。
  • RapidJSON 獨(dú)立。它不依賴于 BOOST 等外部庫。它甚至不依賴于 STL。
  • RapidJSON 對內(nèi)存友好。在大部分 32/64 位機(jī)器上,每個(gè) JSON 值只占 16 字節(jié)(除字符串外)。它預(yù)設(shè)使用一個(gè)快速的內(nèi)存分配器,令分析器可以緊湊地分配內(nèi)存。
  • RapidJSON 對 Unicode 友好。它支持 UTF-8、UTF-16、UTF-32 (大端序/小端序),并內(nèi)部支持這些編碼的檢測、校驗(yàn)及轉(zhuǎn)碼。例如,RapidJSON 可以在分析一個(gè) UTF-8 文件至 DOM 時(shí),把當(dāng)中的 JSON 字符串轉(zhuǎn)碼至 UTF-16。它也支持代理對(surrogate pair)及 "\u0000"(空字符)。

不過rapidjson為了性能,在使用上面需要極其小心。

筆者之前踩過類似坑,局部字符串賦值給rapidjson對象,結(jié)果rapidjson并沒有馬上使用該局部字符串,而是在最后才會訪問局部字符串里面的內(nèi)容,而此時(shí),局部字符串早已出了作用域,導(dǎo)致rapidjson獲取的內(nèi)容是亂碼。

結(jié)語

在使用開源項(xiàng)目的時(shí)候,一定要做好調(diào)研,必要的時(shí)候,能過一下源碼實(shí)現(xiàn)(這個(gè)有點(diǎn)難??),否則很容易入坑。

筆者在使用libcurl作為httpclient的時(shí)候,也因?yàn)橛|發(fā)了libcurl的一個(gè)bug,導(dǎo)致線上崩潰,當(dāng)時(shí)連續(xù)通宵了兩個(gè)晚上,才解決。

一入C++深似海,從此XX是路人。

責(zé)任編輯:武曉燕 來源: 高性能架構(gòu)探索
相關(guān)推薦

2017-12-19 14:00:16

數(shù)據(jù)庫MySQL死鎖排查

2019-04-15 13:15:12

數(shù)據(jù)庫MySQL死鎖

2018-07-20 08:44:21

Redis內(nèi)存排查

2023-01-04 18:32:31

線上服務(wù)代碼

2023-04-06 07:53:56

Redis連接問題K8s

2021-05-13 08:51:20

GC問題排查

2018-11-13 10:44:23

Linux服務(wù)器雙網(wǎng)卡網(wǎng)絡(luò)

2020-11-16 07:19:17

線上函數(shù)性能

2021-03-29 12:35:04

Kubernetes環(huán)境TCP

2019-09-10 10:31:10

JVM排查解決

2019-06-10 15:20:18

2021-05-31 10:08:44

工具腳本主機(jī)

2019-03-15 16:20:45

MySQL死鎖排查命令

2022-02-08 17:17:27

內(nèi)存泄漏排查

2022-07-13 08:31:18

React問題排查

2021-03-05 07:14:08

Linuxcrashvmcore

2024-10-15 09:27:36

2024-04-10 08:48:31

MySQLSQL語句

2023-10-10 12:05:45

2019-08-26 09:50:09

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號