Linux 性能診斷:快速檢查單(Netflix版)

快速檢查單

快速檢查單（Quick Reference Handbook，QRH）是飛行員在飛行過程中依賴的重要指導(dǎo)性文件。

第一張飛行檢查單起源于一次嚴(yán)重的航空事故。1935年波音公司研制的一架新型轟炸機在試飛過程中突然墜機锹漱，導(dǎo)致2名機組人員遇難——包括一名最優(yōu)秀的試飛員普洛耶爾·希爾少校。后來的調(diào)查結(jié)果分析类溢，事故并不是機械故障引起的凌蔬，而是人為失誤造成露懒。新型飛機比以往的飛機更復(fù)雜，飛行員要管理4臺發(fā)動機砂心，操控起落架懈词、襟翼、電動配平調(diào)整片和恒速液壓變距螺旋槳等辩诞。因為忙于各種操作坎弯，希爾少校忘記了一項簡單卻很重要的工作 —— 在起飛前忘記對新設(shè)計的升降舵和方向舵實施解鎖。

美國軍方組織飛行專家編制了一份飛行檢查單译暂，將起飛抠忘、巡航、著陸和滑行各階段的重要步驟寫在一張索引卡片上外永。飛行員根據(jù)檢查單的提示檢查剎車是否松開崎脉，飛行儀表是否準(zhǔn)確設(shè)定，機艙門窗是否完全關(guān)閉伯顶，升降舵等控制面是否已經(jīng)解鎖囚灼。

Netflix 性能工程團隊

登陸一臺 Linux 服務(wù)器排查性能問題：開始一分鐘你該檢查哪些呢？
在 Netflix 我們有一個龐大的 EC2 Linux集群祭衩，也有許多性能分析工具用于監(jiān)視和檢查它們的性能灶体。它們包括用于云監(jiān)測的Atlas (工具代號) ，用于實例分析的 Vector (工具代號) 掐暮。盡管這些工具能幫助我們解決大部分問題蝎抽，我們有時也需要登陸一臺實例、運行一些標(biāo)準(zhǔn)的 Linux 性能分析工具路克。在這篇文章樟结，Netflix 性能工程團隊將向您展示：在開始的60秒鐘，利用標(biāo)準(zhǔn)的Linux命令行工具衷戈，執(zhí)行一次充分的性能檢查狭吼。

Linux 性能分析黃金60秒

運行以下10個命令，你可以在60秒內(nèi)殖妇，獲得系統(tǒng)資源利用率和進程運行情況的整體概念。查看是否存在異常破花、評估飽和度谦趣，它們都非常易于理解璧帝，可用性強蛆挫。飽和度表示資源還有多少負(fù)荷可以讓它處理，并且能夠展示請求隊列的長度或等待的時間碌识。

uptime
dmesg | tail vmstat 1
mpstat -P ALL 1 pidstat 1
iostat -xz 1 free -m
sar -n DEV 1
sar -n TCP,ETCP 1 top
性能檢查的一般步驟

這些命令需要安裝sysstat包峭梳。這些命令輸出的指標(biāo)舰绘，將幫助你掌握一些有效的方法：一整套尋找性能瓶頸的方法論蹂喻。這些命令需要檢查所有資源的利用率、飽和度和錯誤信息（CPU捂寿、內(nèi)存口四、磁盤等）。同時秦陋，當(dāng)你檢查或排除一些資源的時候蔓彩，需要注意在檢查過程中，根據(jù)指標(biāo)數(shù)據(jù)指引驳概，逐步縮小目標(biāo)范圍赤嚼。

接下來的章節(jié)，將結(jié)合生產(chǎn)環(huán)境的案例演示這些命令顺又。如果希望了解這些工具的詳細(xì)信息更卒，可以查閱它們的操作文檔。

1. uptime

$ uptime
23:51:26up21:31, 1user, loadaverage:30.02,26.43,19.02

這是一個快速查看平均負(fù)載的方法稚照，表示等待運行的任務(wù)（進程）數(shù)量蹂空。在Linux系統(tǒng)中，這些數(shù)字包含等待CPU運行的進程數(shù)锐锣，也包括不間斷I/O阻塞的進程數(shù)（通常是磁盤I/O）腌闯。它展示了一個資源負(fù)載（或需求）的整體概念，但是無法理解其中的內(nèi)涵雕憔，在沒有其它工具的情況下姿骏。僅僅是一種快速查看手段而已。

這三個數(shù)字呈現(xiàn)出平均負(fù)載在幾何級減弱斤彼，依次表示持續(xù)1分鐘分瘦，5分鐘和15分鐘內(nèi)。這三個數(shù)字能告訴我們負(fù)載在時間線上是如何變化的琉苇。舉例說明嘲玫，如果你在一個問題服務(wù)器上執(zhí)行檢查，1分鐘的值遠遠低于15分鐘的值并扇，可以判斷出你也許登錄得太晚了去团，已經(jīng)錯過了問題。

在上面的例子中穷蛹，平均負(fù)載的數(shù)值顯示最近正在上升土陪，1分鐘值高達30，對比15分鐘值則是19肴熏。這些指標(biāo)值像現(xiàn)在這么大意味著很多情況：也許是CPU繁忙鬼雀；vmstat 或者 mpstat 將可以確認(rèn)，本系列的第三和第四條命令蛙吏。

2. dmesg | tail

$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-r
ss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP cou
nters.

這個結(jié)果輸出了最近10條系統(tǒng)信息源哩⌒可以查看到引起性能問題的錯誤。上面的例子包含了oom-killer,以及TCP丟包励烦。

譯者注:除了error級的日志谓着，info級的也要留個心眼，可能包含一些隱藏信息崩侠。

3. vmstat 1

$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0

vmstat 是一個獲得虛擬內(nèi)存狀態(tài)概況的通用工具（最早創(chuàng)建于10年前的BSD）漆魔。它每一行記錄了關(guān)鍵的服務(wù)器統(tǒng)計信息。vmstat 運行的時候有一個參數(shù)1却音，用于輸出一秒鐘的概要數(shù)據(jù)改抡。第一行輸出顯示啟動之后的平均值，用以替代之前的一秒鐘數(shù)據(jù)∠灯埃現(xiàn)在阿纤，跳過第一行，讓我們來學(xué)習(xí)并且記住每一列代表的意義夷陋。

r：正在CPU上運行或等待運行的進程數(shù)欠拾。相對于平均負(fù)載來說，這提供了一個更好的骗绕、用于查明CPU飽和度的指標(biāo)藐窄，它不包括I/O負(fù)載。注: “r”值大于CPU數(shù)即是飽和酬土。

free: 空閑內(nèi)存（kb)
如果這個數(shù)值很大荆忍，表明你還有足夠的內(nèi)存空閑。包括命令7“free m”撤缴，很好地展現(xiàn)了空閑內(nèi)存的狀態(tài)刹枉。

si, so: swap入／出。如果這個值非0屈呕，證明內(nèi)存溢出了微宝。

us, sy, id, wa, st:它們是CPU分類時間，針對所有CPU的平均訪問虎眨。分別是用戶時間蟋软，系統(tǒng)時間（內(nèi)核），空閑嗽桩，I/O等待時間钟鸵，以及被偷走的時間（其它訪客，或者是Xen）涤躲。CPU分類時間將可以幫助確認(rèn)，CPU是否繁忙贡未，通過累計用戶系統(tǒng)時間种樱。等待I/O的情形肯定指向的是磁盤瓶頸蒙袍；這個時候CPU通常是空閑的，因為任務(wù)被阻塞以等待分配磁盤I/O嫩挤。你可以將等待I/O當(dāng)作另一種CPU空閑害幅，一種它們?yōu)槭裁纯臻e的解釋線索。

系統(tǒng)時間對I/O處理非常必要岂昭。一個很高的平均系統(tǒng)時間以现，超過20%，值得深入分析：也許是內(nèi)核處理I/O非常低效约啊。在上面的例子中邑遏，CPU時間幾乎完全是用戶級的，與應(yīng)用程序級的利用率正好相反恰矩。所有CPU的平均利用率也超過90%记盒。這不一定是一個問題；還需檢查“r”列的飽和度外傅。

4. mpstat P ALL 1

$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]

這個命令可以按時間線打印每個CPU的消耗纪吮，常常用于檢查不均衡的問題。如果只有一個繁忙的CPU萎胰，可以判斷是屬于單進程的應(yīng)用程序碾盟。

5. pidstat 1

$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
^C

pidstat 有一點像頂級視圖－針對每一個進程，但是輸出的時候滾屏技竟，而不是清屏冰肴。它非常有用，特別是跨時間段查看的模式灵奖，也能將你所看到的信息記錄下來嚼沿，以利于進一步的研究。上面的例子識別出兩個 java 進程引起的CPU耗盡瓷患÷饩。“％CPU” 是對所有CPU的消耗；1591% 顯示 java 進程占用了幾乎16個CPU擅编。

6. iostat xz 1

$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]

這是一個理解塊設(shè)備（磁盤）極好的工具攀细，不論是負(fù)載評估還是作為性能測試成績。

r/s, w/s, rkB/s, wkB/s: 這些是該設(shè)備每秒讀％爱态、寫％谭贪、讀Kb、寫Kb锦担〖笫叮可用于描述工作負(fù)荷。一個性能問題可能只是簡單地由于一個過量的負(fù)載引起洞渔。

await: I/O平均時間（毫秒）
這是應(yīng)用程序需要的時間套媚，它包括排隊以及運行的時間缚态。
遠遠大于預(yù)期的平均時間可以作為設(shè)備飽和，或者設(shè)備問題的指標(biāo)堤瘤。

avgqu-sz: 向設(shè)備發(fā)出的平均請求數(shù)玫芦。
值大于1可視為飽和（盡管設(shè)備能對請求持續(xù)運行，特別是前端的虛擬設(shè)備－后端有多個磁盤）本辐。

%util: 設(shè)備利用率
這是一個實時的繁忙的百分比桥帆，顯示設(shè)備每秒鐘正在進行的工作。值大于60%屬于典型的性能不足（可以從await處查看）慎皱，盡管它取決于設(shè)備老虫。值接近100% 通常指示飽和。如果存儲設(shè)備是一個前端邏輯磁盤宝冕、后掛一堆磁盤张遭，那么100%的利用率也許意味著，一些已經(jīng)處理的I/O此時占用100%地梨，然而菊卷，后端的磁盤也許遠遠沒有達到飽和，其實可以承擔(dān)更多的工作宝剖。

切記：磁盤I/O性能低并不一定是應(yīng)用程序問題洁闰。許多技術(shù)一貫使用異步I/O，所以應(yīng)用程序并不會阻塞万细，以及遭受直接的延遲（例如提前加載扑眉，緩沖寫入）。

7. free m

$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0

buffers: buffer cache,用于塊設(shè)備I/O赖钞。
cached:page cache, 用于文件系統(tǒng)腰素。

我們只是想檢查這些指標(biāo)值不為0——那樣意味著磁盤I/O高、性能差（確認(rèn)需要用iostat）雪营。上面的例子看起來不錯弓千，每一類內(nèi)存都有富余。

“-/+ buffers/cache”: 提供了關(guān)于內(nèi)存利用率更加準(zhǔn)確的數(shù)值献起。

Linux可以將空閑內(nèi)存用于緩存洋访，并且在應(yīng)用程序需要的時候收回。所以應(yīng)用到緩存的內(nèi)存必須以另一種方式包括在內(nèi)存空閑的數(shù)據(jù)里面谴餐。有一個網(wǎng)站linux ate my ram,專門探討這個困惑姻政。它還有更令人困惑的地方，如果在Linux上使用ZFS,正如我們運行一些服務(wù)岂嗓，ZFS擁有自己的文件系統(tǒng)緩存汁展，也不能在free -m 的輸出里正確反映。這種情況會顯示系統(tǒng)空閑內(nèi)存不足，但是內(nèi)存實際上可用善镰，通過回收 ZFS 的緩存妹萨。

關(guān)于 Linux 內(nèi)存管理的更多內(nèi)容，可以閱讀操作系統(tǒng)原理：How Linux Works (Memroy)炫欺。

8. sar n DEV 1

$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
^C

使用這個工具用來檢查網(wǎng)絡(luò)接口吞吐量：rxkB/s 和** txkB/s**, 作為負(fù)載的一種度量方式, 也可以用來檢查是否已經(jīng)達到某種瓶頸。

在上面的例子中熏兄，網(wǎng)卡 eth0 收包大道 22 Mbytes/s, 即176 Mbits/sec (就是說品洛，在 1 Gbit/sec 的限制之內(nèi))。此版本也有一個體現(xiàn)設(shè)備利用率的 “％ifutil” （兩個方向最大值）摩桶，我們也可以使用 Brendan的nicstat 工具來度量桥状。和 nicstat 類似，這個值很難準(zhǔn)確獲取硝清，看起來在這個例子中并沒有起作用（0.00）辅斟。

9. sar n TCP,ETCP 1

$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
^C

這是一個關(guān)鍵TCP指標(biāo)的概覽視圖。包括：
active/s: 本地初始化的 TCP 連接數(shù) ／每秒（例如芦拿，通過connect() ）
passive/s: 遠程初始化的 TCP 連接數(shù)／每秒（例如士飒，通過accept() ）
retrans/s: TCP重發(fā)數(shù)／每秒

這些活躍和被動的計數(shù)器常常作為一種粗略的服務(wù)負(fù)載度量方式：新收到的連接數(shù) (被動的),以及下行流量的連接數(shù) (活躍的)。這也許能幫助我們理解蔗崎，活躍的都是外向的酵幕，被動的都是內(nèi)向的，但是嚴(yán)格來說這種說法是不準(zhǔn)確的（例如缓苛，考慮到“本地－本地”的連接）芳撒。重發(fā)數(shù)是網(wǎng)絡(luò)或服務(wù)器問題的一個標(biāo)志；它也許是因為不可靠的網(wǎng)絡(luò)（如未桥，公共互聯(lián)網(wǎng)）笔刹，也許是由于一臺服務(wù)器已經(jīng)超負(fù)荷、發(fā)生丟包冬耿。
上面的例子顯示每秒鐘僅有一個新的TCP連接舌菜。

10. top

$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched

top命令包含了許多我們之前已經(jīng)檢查的指標(biāo)。它可以非常方便地運行淆党，看看是否任何東西看起來與從前面的命令的結(jié)果完全不同酷师，可以表明負(fù)載指標(biāo)是不斷變化的。頂部下面的輸出染乌，很難按照時間推移的模式查看山孔，可能使用如 vmstat 和 pidstat 等工具會更清晰，它們提供滾動輸出荷憋。如果你保持輸出的動作不夠快 （CtrlS 要暫停台颠，CtrlQ 繼續(xù)），屏幕將清除，間歇性問題的證據(jù)也會丟失串前。

總結(jié)

故障檢查過程中瘫里，人的作用主要是作出決策。遺忘荡碾、遺漏谨读、麻痹、松懈是每個人都會犯的錯誤坛吁，好的公司都會根據(jù)經(jīng)驗編制檢查單劳殖，提高工作效率，降低人為失誤發(fā)生的概率拨脉。出于競爭因素考慮哆姻，應(yīng)該充分重視檢查單的更新、完善玫膀、自動化矛缨，以此為基礎(chǔ)建立自己的技術(shù)壁壘。

擴展閱讀：Linux 操作系統(tǒng)

推薦：電子書《Linux Perf Master》

發(fā)表在GitBook平臺帖旨，歡迎訂閱箕昭、下載、批評指正: https://www.gitbook.com/book/riboseyim/linux-perf-master/details

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末碉就，一起剝皮案震驚了整個濱河市盟广，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌瓮钥，老刑警劉巖筋量，帶你破解...
    沈念sama閱讀 212,542評論 6贊 493
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異碉熄，居然都是意外死亡桨武，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,596評論 3贊 385
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門锈津，熙熙樓的掌柜王于貴愁眉苦臉地迎上來呀酸，“玉大人，你說我怎么就攤上這事琼梆⌒杂” “怎么了？”我有些...
    開封第一講書人閱讀 158,021評論 0贊 348
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵茎杂，是天一觀的道長错览。 經(jīng)常有香客問我，道長煌往，這世上最難降的妖魔是什么倾哺？ 我笑而不...
    開封第一講書人閱讀 56,682評論 1贊 284
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上羞海，老公的妹妹穿的比我還像新娘忌愚。我一直安慰自己，他們只是感情好却邓，可當(dāng)我...
    茶點故事閱讀 65,792評論 6贊 386
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布硕糊。 她就那樣靜靜地躺著，像睡著了一般申尤。 火紅的嫁衣襯著肌膚如雪癌幕。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,985評論 1贊 291
  • 城市分裂傳說
    那天昧穿，我揣著相機與錄音，去河邊找鬼橙喘。 笑死时鸵，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的厅瞎。 我是一名探鬼主播饰潜，決...
    沈念sama閱讀 39,107評論 3贊 410
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼和簸！你這毒婦竟也來了彭雾？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 37,845評論 0贊 268
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤锁保，失蹤者是張志新（化名）和其女友劉穎薯酝，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體爽柒，經(jīng)...
    沈念sama閱讀 44,299評論 1贊 303
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡吴菠，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,612評論 2贊 327
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了浩村。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片做葵。...
    茶點故事閱讀 38,747評論 1贊 341
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖心墅，靈堂內(nèi)的尸體忽然破棺而出酿矢，到底是詐尸還是另有隱情，我是刑警寧澤怎燥，帶...
    沈念sama閱讀 34,441評論 4贊 333
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布瘫筐，位于F島的核電站，受9級特大地震影響刺覆，放射性物質(zhì)發(fā)生泄漏严肪。R本人自食惡果不足惜，卻給世界環(huán)境...
    茶點故事閱讀 40,072評論 3贊 317
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望驳糯。 院中可真熱鬧篇梭，春花似錦、人聲如沸酝枢。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,828評論 0贊 21
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽帘睦。三九已至袍患，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間竣付，已是汗流浹背诡延。 一陣腳步聲響...
    開封第一講書人閱讀 32,069評論 1贊 267
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留古胆，地道東北人肆良。 一個月前我還...
    沈念sama閱讀 46,545評論 2贊 362
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像逸绎，于是被迫代替她去往敵國和親惹恃。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,658評論 2贊 350