Linux下性能分析指南

看了很多文章，很多大牛都提到要關注自己程序的性能問題境蔼。比如說灶平，除了你的程序可以work之外，還需要考慮你的程序的cpu占用率箍土，內存占用率逢享，io占用率等。整理一下性能問題一些指標和定位方法吴藻。

cpu相關

評價指標cpu的性能分析常用的兩個指標是cpu利用率和平均負載瞒爬。

平均負載
在linux下面使用uptime命令可以查看到機器的平均負載。按照man uptime給出的定義沟堡，平均負載反應的是當前的機器的“活躍”進程數(shù)侧但。
```
$ man uptime
DESCRIPTION
     uptime  gives  a  one line display of the following information.  The current time, how long the system has been running, how
     many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes.

     This is the same information contained in the header line displayed by w(1).
```
```
$ uptime
 14:58:14 up 263 days, 18:18,  1 user,  load average: 0.93, 0.97, 1.05
```
uptime的含義：
uptime返回的是1，5航罗，15分鐘的“活躍”進程數(shù)禀横。活躍的進程的定義是：
處于R狀態(tài)的進程（處于運行狀態(tài)的進程或者是就緒狀態(tài)的進程）
處于D狀態(tài)的進程（處于等待IO的不可被信號中斷）

如果uptime高的話粥血，那么可能的情況是：
1）系統(tǒng)中有大量CPU密集型的進程柏锄，比如大量進程都在進行計算，此時的系統(tǒng)平均負載與CPU使用率的關聯(lián)就很大复亏。
2）系統(tǒng)中有大量IO密集型進程趾娃，這些進程中有很多時間都在等待IO完成，此時系統(tǒng)平均負載高但是CPU使用率并不見得就高缔御。
3）就緒隊列中有大量處于就緒狀態(tài)等待CPU資源的進程抬闷，這種情況下會導致系統(tǒng)平均負載升高，而且CPU使用率也變高耕突。

cpu利用率

cpu利用率有兩個維度笤成，一個是機器某個cpu核心的利用率，另外一個是進程的cpu利用率有勾。如果用top命令可以看到這兩個維度分別的指標疹启。下面這張圖是某個cpu核心的利用率，圖片中下面是各種進程的cpu利用率蔼卡。

下面先從機器某個核心的cpu利用率說起

1. 某個核心的cpu利用率
通過top命令喊崖，經(jīng)常可以看到機器上每個cpu核心的負載雇逞，如下圖所示荤懂。

但是，top的數(shù)據(jù)是從哪里拿到的呢塘砸？了解linux系統(tǒng)的都知道/proc/stat 這個文件記錄了每個cpu從啟動之后在各個狀態(tài)下面的節(jié)拍數(shù)节仿。

翻譯一下每列的含義：
us：CPU運行用戶空間進程的時間比例
sy：CPU運行內核進程時間比例
ni：CPU 運行低優(yōu)先級進程時間比例
id：CPU空閑狀態(tài)時間比例
iowait： CPU等待I/O操作完成的時間比例
hi：CPU 處理硬件中斷時間比例
si： CPU 處理軟中斷時間比例
steal：虛擬 CPU 被占用強制等待時間比例

cpu某個核心的利用率 = 1 - ((iowait時間 + idle時間）/ 總時間。
因此掉蔬，如果要計算某個時間點的cpu利用率廊宪，可以先取兩個采樣點讀取/proc/stat文件矾瘾，然后按照下面的公式計算：

CPU Usage 
 = 1 - (△idle+△iowait) / △total_time
 = 1 - (idle2+iowait2 - idle1 - iowait1) / (total_time2 - total_time1)

2. 某個進程的cpu利用率

如何計算某個進程的cpu利用率，計算的基本公式如下 = 這個進程自己的占用的cpu時間 * 核心數(shù) / cpu每個核心各種狀態(tài)的總時間箭启。寫的詳細一點壕翩，大約是：

某個進程的cpu利用率 
= （進程用戶態(tài)時間 + 內核態(tài)時間 + 用戶態(tài)等待子進程的消耗
    + 內核態(tài)等待子進程的消耗）/ cpu總時間△t

對于某個進程，可以根據(jù)其pid找到在/proc/pid/stat 找打這個進程各種狀態(tài)占用的cpu節(jié)拍數(shù)傅寡。

找到里面的關鍵幾列放妈，分別是：
utime ：用戶態(tài)時間
sttime ：系統(tǒng)態(tài)時間
cutime ：子進程用戶態(tài)時間
cstime ：子進程系統(tǒng)態(tài)時間

寫個小腳本就可以統(tǒng)計這個事情：

# 打印該進程進程用戶態(tài)時間 + 內核態(tài)時間 + 
# 用戶態(tài)等待子進程的消耗 + 內核態(tài)等待子進程的消耗 占用的時間之和
$ cat /proc/16820/stat | awk '{print "cpu_total_slice : " $14+$15+$16+$17}'
cpu_total_slice : 4405

了解了cpu利用率的原理，那就不難寫出一個類似于ps命令或top這樣的工具去統(tǒng)計某個進程的cpu利用率或者機器cpu的利用率荐操。用shell寫一個demo芜抒，驗證一下：

# 統(tǒng)計某個進程的cpu占用率
print_process_cpu_precent()
{
  cpu_total_time1=`cat /proc/stat | head -n1 |awk '{print $2+$3+$4+$5+$6+$7+$8}'`
  process_time1=`cat /proc/${PID}/stat | head -n1 | awk '{print $14+$15+$16+$17}'`
  sleep 1

  cpu_total_time2=`cat /proc/stat | head -n1 |awk '{print $2+$3+$4+$5+$6+$7+$8}'`
  process_time2=`cat /proc/${PID}/stat | head -n1 | awk '{print $14+$15+$16+$17}'`

  cpu_time=$((cpu_total_time2 - cpu_total_time1))
  process_time=$((process_time2 - process_time1))

  cpu_percent=$((100 * process_time * cpu_core_num / cpu_time))

  echo "process : $PID, cpu percent : $cpu_percent"
}

封裝成一個腳本跑起來：
https://github.com/zhaozhengcoder/CoderNoteBook/blob/master/example_code/shell/cpu.sh

通過stress命令模擬cpu和io密集型的任務來對應這個腳本統(tǒng)計的結果和pidstat，mpstat的結果對比效果準不準托启。

#產(chǎn)生一個io密集型的進程供測試
stress -i 1

$ pidstat -p 18493 1 100
04:01:48 PM     18493    0.00   36.00    0.00   36.00     0  stress
04:01:49 PM     18493    0.00   42.00    0.00   42.00     0  stress
04:01:50 PM     18493    0.00   37.00    0.00   37.00     0  stress
04:01:51 PM     18493    0.00   40.00    0.00   40.00     0  stress
04:01:52 PM     18493    0.00   37.00    0.00   37.00     0  stress
04:01:53 PM     18493    0.00   41.00    0.00   41.00     0  stress
04:01:54 PM     18493    0.00   36.00    0.00   36.00     0  stress
04:01:55 PM     18493    0.00   43.00    0.00   43.00     0  stress
04:01:56 PM     18493    0.00   40.00    0.00   40.00     0  stress
04:01:57 PM     18493    0.00   53.00    0.00   53.00     0  stress

./test_cpu.sh 18493
process : 18493, cpu percent : 40
process : 18493, cpu percent : 40
process : 18493, cpu percent : 40
process : 18493, cpu percent : 44
process : 18493, cpu percent : 37
process : 18493, cpu percent : 42
process : 18493, cpu percent : 38
process : 18493, cpu percent : 40
process : 18493, cpu percent : 44
process : 18493, cpu percent : 54  

// 總的來說還是比較接近宅倒，相差不大

mpstat -P ALL 1 100
04:05:04 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
04:05:05 PM  all    6.16    0.00    5.90    3.46    0.00    0.00    0.00    0.00   84.48
04:05:05 PM    0    2.02    0.00   42.42   53.54    0.00    0.00    0.00    0.00    2.02
04:05:05 PM    1   14.00    0.00    3.00    0.00    0.00    0.00    0.00    0.00   83.00
04:05:05 PM    2    3.19    0.00    4.26    0.00    0.00    0.00    0.00    0.00   92.55
04:05:05 PM    3   18.18    0.00    3.03    0.00    0.00    0.00    0.00    0.00   78.79
04:05:05 PM    4    6.52    0.00   13.04    0.00    0.00    0.00    0.00    0.00   80.43
04:05:05 PM    5    5.05    0.00    1.01    1.01    0.00    0.00    0.00    0.00   92.93
04:05:05 PM    6    1.01    0.00    2.02    0.00    0.00    0.00    0.00    0.00   96.97
04:05:05 PM    7    3.16    0.00    1.05    0.00    0.00    0.00    0.00    0.00   95.79
04:05:05 PM    8    5.15    0.00    3.09    0.00    0.00    0.00    0.00    0.00   91.75
04:05:05 PM    9    3.03    0.00    2.02    0.00    0.00    0.00    0.00    0.00   94.95
04:05:05 PM   10    3.23    0.00    2.15    0.00    0.00    0.00    0.00    0.00   94.62
04:05:05 PM   11   26.73    0.00    5.94    0.00    0.00    0.00    0.00    0.00   67.33
04:05:05 PM   12    3.06    0.00    0.00    0.00    0.00    0.00    0.00    0.00   96.94
04:05:05 PM   13    0.99    0.00    2.97    0.99    0.00    0.00    0.00    0.00   95.05
04:05:05 PM   14    1.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.00
04:05:05 PM   15    4.30    0.00    4.30    0.00    0.00    0.00    0.00    0.00   91.40

$ ./test_cpu.sh 18493
[cpu 1] user percent : 3, syc percent 35
[cpu 2] user percent : 13, syc percent 3
[cpu 3] user percent : 3, syc percent 5
[cpu 4] user percent : 10, syc percent 4
[cpu 5] user percent : 6, syc percent 10
[cpu 6] user percent : 5, syc percent 0
[cpu 7] user percent : 0, syc percent 0
[cpu 8] user percent : 5, syc percent 0
[cpu 9] user percent : 4, syc percent 3
[cpu 10] user percent : 0, syc percent 0
[cpu 11] user percent : 0, syc percent 10
[cpu 12] user percent : 20, syc percent 5
[cpu 13] user percent : 5, syc percent 15
[cpu 14] user percent : 1, syc percent 3
[cpu 15] user percent : 5, syc percent 10
[cpu 16] user percent : 3, syc percent 4

cpu利用率是否會把子線程的利用率計算進去？
關于cpu利用率驾中，cpu的利用率是否會包含子線程占用cpu的比例么唉堪？比如對于如下的進程，ps看到的cpu利用率是多少呢肩民？ 測試結果如下唠亚，cpu的占用率是包含自己的子線程的。
```
void threadfunc1()
{
    int val = 1;
    for (int i = 0; i < max_print_times;)
    {
        val = (val + 1) * val;
    }
}

int main()
{
    std::thread t1(threadfunc1);
    t1.join();   
    return 0;
}
```

關于查看線程的一些命令

# 查看進程下面有幾個線程
$ pstree -p 1
init(1)─┬─init(7)───zsh(8)───pstree(103)
      └─{init}(6)

# 顯示系統(tǒng)的線程
$ ps -efT 
$ top 命令之后持痰，輸入H

# 查看一個進程下那個子線程的cpu比較高
$ top -H -p 5680
 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                           
 5681 user+  20   0   26116   1128    924 R 99.9  0.0   8:23.30 a.out                                                                             
 5680 user+  20   0   26116   1128    924 S  0.0  0.0   0:00.00 a.out

在日常的開發(fā)中灶搜，我常用top命令看一下各種進程的狀態(tài)。如果是想確定某個操作是否會影響cpu的性能工窍。我一般會top -b > profile.log, 然后觸發(fā)某個操作割卖，最后打開統(tǒng)計的log，觀察這段時間內性能指標的各種變化患雏。如果可以確定是某個進程的話鹏溯，也可以使用pidstat -p xxxx 1的方式觀察。

內存相關

相關指標
可以用free淹仑，top命令看到關于內存的指標：

$free -g
              total        used        free      shared  buff/cache   available
  Mem:             15           1           9           1           4          12
  Swap:             0           0           0

$top
VIRT    RES    SHR   %MEM

VIRT: 進程申請的虛擬內存
RES : 進程當前占用的物理內存（不包括共享內存）
SHR : 進程當前占用的共享內存
%MEM : 進程當前先用的物理內存的比例 （RES/物理內存）

關于VIRT丙挽，需要注意的是進程malloc內存之后，并不會立刻使VIRT升高匀借，只用寫內存的時候颜阐，才會是VIRT升高。換句話說吓肋，malloc的時候凳怨，不會立刻給進程分配內存，只有寫入的時候，才會觸發(fā)分配（cow機制）肤舞。
做一個對比的測試紫新，下面這兩段代碼占用的內存（VIRT占用）完全不一樣。區(qū)別只是一個申請了內存之后李剖，什么都沒有做弊琴，另外一個是申請之后，對內存進行了寫入杖爽。

const long mem_size = 10 * 1024* 1024;
int times = 10;
for (int i = 0; i <times; i++)
{
  int * mem_arr = new int[mem_size];
  for (int j = 0; j < mem_size; j++)
  {
    mem_arr[j] = j;
  }
}

const long mem_size = 10 * 1024* 1024;
int times = 10;
for (int i = 0; i <times; i++)
{
    int * mem_arr = new int[mem_size];
    // for (int j = 0; j < mem_size; j++)
    // {
    //     mem_arr[j] = j;
    // }
}

常用的定位內存問題的命令：

查看當前機器內存占用的情況
free -g 

top 命名輸入之后，輸入M（按照內存占用高低排序）

觀察機器內存的變化
$ 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
 0  0      0 11327748 2178472 1960200    0    0     0     5    0    0  0  0 100  0  0
 0  0      0 11327768 2178472 1960200    0    0     0     0  875  890  0  0 100  0  0
 0  0      0 11327628 2178472 1960200    0    0     0     0  857  906  0  0 100  0  0
 0  0      0 11327628 2178472 1960200    0    0     0    96  845  896  0  0 100  0  0

buff和cache是什么含義紫皇？
在日常的開發(fā)中慰安，如果打開打開一個大文件再次打開會更快一些。linux在內存和磁盤之后聪铺，構建了buff和cache來作為緩存化焕。以前一直有一個錯誤印象，cache是讀緩存铃剔，buff是寫緩存撒桨。準確的說，cache是讀寫文件系統(tǒng)的緩存键兜，buff是寫磁盤系統(tǒng)的緩存凤类。
```
# 清空緩存
$ echo 3 > /proc/sys/vm/drop_caches

寫文件
$ dd if=/dev/urandom of=/tmp/file bs=1M count=50
讀文件
$ dd if=/tmp/file of=/dev/null

寫磁盤
$ dd if=/dev/urandom of=/dev/sdb1 bs=1M count=2048
讀磁盤：
$ dd if=/dev/sda1 of=/dev/null bs=1M count=1024

# 使用vmstat觀察cache和buff的變化
vmstat -1
```

oom問題
比如某個進程申請的內存過大（或者是由于bug導致申請多過的內存），導致機器沒有內存的時候普气，會出現(xiàn)oom谜疤。oom發(fā)生的時候，并不一定會kill正在申請內存的進程现诀，而是會根據(jù)每個進程的score分數(shù)去kill掉一個夷磕。于是就會出現(xiàn)是服務a的bug，瘋狂申請內存仔沿，最后導致oom去kill了服務b坐桩。這個問題不難理解，有的時候出現(xiàn)某個服務莫名其妙的掛了封锉，邏輯上并沒有什么錯誤绵跷，可以排查一下是否是oom導致。
```
cat /var/message/log | grep "Out of memory"
```
舉一個自己遇到的關于內存的問題：有一個物理機部署某個進程啟動的時候烘浦，在init的邏輯在讀取一個系統(tǒng)文件時候抖坪，返回了false，導致進程啟動失敗闷叉。排查過程：
```
- 查看日志擦俐，發(fā)現(xiàn)是init階段某個系統(tǒng)調用失敗，導致init失敗

- 使用strace 啟動
trace -o out.txt -e trace=all ./xxxx 

- 在日志中看到如下錯誤：
open("/usr/bin/sd-agent/checks.py", O_RDONLY|O_LARGEFILE) = -1 ENOMEM (Cannot allocate memory)

- 看提示是內存分配失敗握侧，使用free -g查看可用內存蚯瞧，可用內存不足嘿期。

- 最終排查下來，這類問題的學名稱為：
fork/clone failures with ENOMEM

- 解決辦法除了讓物理機保持足夠的可用內存之外
還可以臨時修改了linux vm分配內存的策略埋合，vm overcommit 修改為1备徐。

https://stackoverflow.com/questions/1367373/python-subprocess-popen-oserror-errno-12-cannot-allocate-memory
```

io相關

基本指標:
io利用率：指的是磁盤處理 I/O 的時間百分比
io吞吐量：每秒的 I/O 請求大小，比如xxMB每秒
IOPS：每秒的 I/O 請求數(shù)

常用命令：

iotop
pidstat -d 1
lsof -p 18940

如何定位高io的進程甚颂？

// 測試代碼如下蜜猾，死循環(huán)打印日志到文件
while(1)
{
  LOG(INFO) << "this is infor message";
  LOG(ERROR) << "this is error message";
}

iostat看到io的利用率升高：

iostat -d -x 1
%util 升高
wkB/s 有數(shù)據(jù)在寫入磁盤

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00   50.00     0.00 20480.00   819.20     0.88   17.60    0.00   17.60   2.64  13.20
vdb               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

iotop命令

Total DISK READ :       0.00 B/s | Total DISK WRITE :      16.40 M/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:      15.69 M/s
TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                          
26098 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.01 % [kworker/4:2]
11106 be/4 root        0.00 B/s    3.92 K/s  0.00 %  0.00 % sap1007
13627 be/4 user_zhao 0.00 B/s   16.39 M/s  0.00 %  0.00 % ./test
  1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % systemd

如何定位到具體進程：

# 找到在io的進程
$ pidstat -d 1   
11:02:54      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
11:02:55     1000      8721      0.00  18459.41      0.00  test

如果定位到具體的io的文件：

$ lsof -p 8721
test    8721 user_zhao    4w   REG  252,1 369094695 1444369  /home//src/test_ERROR20210525-110157.8721

$strace -p 8721
write(4, "E0525 11:26:09.772125 11740 test"..., 68) = 68
write(5, "E0525 11:26:09.772125 11740 test"..., 68) = 68
write(3, ":48] this is error glog message\n"..., 4096) = 4096
write(2, "E0525 11:26:09.772125 11740 test"..., 68) = 68
gettid()                                = 11740
gettid()                                = 11740

$ pstack 8721
#0  0x00007fcb3ede0850 in __write_nocancel () from /lib64/libc.so.6
#1  0x00007fcb3ed6cfb3 in _IO_new_file_write () from /lib64/libc.so.6
#2  0x00007fcb3ed6d74f in __GI__IO_file_xsputn () from /lib64/libc.so.6
#3  0x00007fcb3ed6303d in fwrite () from /lib64/libc.so.6
#4  0x00007fcb3fb05b36 in ?? ()
#5  0x0000000001304800 in ?? ()
#6  0x00007fcb3fb10606 in ?? ()
#7  0x000000000000003f in ?? ()
#8  0x0000000060ac6edb in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x00000000013047a8 in ?? ()
#11 0x00007fff26baba10 in ?? ()
#12 0x9a65cc0f603d7500 in ?? ()
#13 0x0000000000000000 in ?? ()

網(wǎng)絡相關

todo

從進程的角度分析

上面是站在系統(tǒng)的角度去分析cpu，內存振诬，io等各種系統(tǒng)指標蹭睡。另外一個中情況是我想看某個進程做什么，他的cpu赶么，io肩豁，內存是什么樣，它打開哪些文件辫呻，進行了哪些系統(tǒng)調用清钥，哪些熱點函數(shù)導致了cpu負載的上升等诸衔。

# 查看進程的各種性能指標
pidstat -p xxx

# 查看進程的系統(tǒng)調用
strace -p xxxx

# 查看進程當前的調用棧
pstack -p xxxx

# 查看進程的打開文件表
lsof -p xxxxx

# strace根據(jù)線程
strace -p PID后加上-f殴穴，多進程和多線程都可以跟蹤厘贼。

計算機各種操作耗時

其他補充

熱點函數(shù)定位
發(fā)現(xiàn)某個進程cpu過載后污呼，要如何定位到具體是哪段邏輯導致的呢切揭？可以使用perf工具在進一步定位問題聊记。故意寫一段大循環(huán)的邏輯楼熄，使用perf命令進行定位熱點函數(shù)拗盒。對于下面的一段代碼進行分析础钠，完整的代碼：
https://github.com/zhaozhengcoder/CoderNoteBook/blob/master/example_code/linux_perf_example/perf_demo.c 使用perf命令對進程進行采樣恰力，找到熱點函數(shù)。

perf 常用的命令：
```
sudo perf record -F 99 -a -g ./demo1
# -F 99 
表示采樣的頻率 
# -a
錄取所有CPU的事件
# -g
使能函數(shù)調用圖功能
-o  指定錄取保存數(shù)據(jù)的文件名
-g  使能函數(shù)調用圖功能
-C 錄取指定CPU的事件

# 生成報告的預覽
perf report
```

perf report的輸出可以看到在執(zhí)行過程中旗吁，每個函數(shù)的占比踩萎。可以看到在下圖中很钓，main香府，func1，func2函數(shù)占了很高的比例码倦。

# 產(chǎn)生比較詳細的報告 
sudo perf report -n --stdio

如果是一個已經(jīng)啟動好的進程企孩，也可以attach上去進行分析分析

sudo perf record -F 99 -p 4989 -g 

# -p 
指明進程的pid

畫火焰圖

git clone --depth 1 https://github.com/brendangregg/FlameGraph.git

# 到處out.perf 文件
sudo perf script > out.perf

# 折疊調用棧
FlameGraph/stackcollapse-perf.pl out.perf > out.folded

# 生成火焰圖
$ FlameGraph/flamegraph.pl out.folded > out.svg

剛才是一個簡單的例子，也可以用perf去觀測一下nginx work的進程袁稽，生成火焰圖勿璃。

# 壓測一下
ab -n 10000 -c 10 http://127.0.0.1/

參考：

perf 分析
http://senlinzhan.github.io/2018/03/18/perf/
一個不錯的git rep
https://github.com/lidaohang/quick_location

最后編輯于：2022.07.10 17:12:20

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子补疑，更是在濱河造成了極大的恐慌歧沪，老刑警劉巖，帶你破解...
沈念sama閱讀 216,496評論 6贊 501
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件莲组，死亡現(xiàn)場離奇詭異诊胞，居然都是意外死亡，警方通過查閱死者的電腦和手機锹杈，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 92,407評論 3贊 392
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門撵孤，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人竭望，你說我怎么就攤上這事早直。” “怎么了市框？”我有些...
開封第一講書人閱讀 162,632評論 0贊 353
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長糕韧。經(jīng)常有香客問我枫振，道長，這世上最難降的妖魔是什么萤彩？我笑而不...
開封第一講書人閱讀 58,180評論 1贊 292
?港島之戀（遺憾婚禮）
正文為了忘掉前任粪滤，我火速辦了婚禮，結果婚禮上雀扶，老公的妹妹穿的比我還像新娘杖小。我一直安慰自己，他們只是感情好愚墓，可當我...
茶點故事閱讀 67,198評論 6贊 388
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布予权。她就那樣靜靜地躺著，像睡著了一般浪册。火紅的嫁衣襯著肌膚如雪扫腺。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 51,165評論 1贊 299
城市分裂傳說
那天村象，我揣著相機與錄音笆环，去河邊找鬼。笑死厚者，一個胖子當著我的面吹牛躁劣，可吹牛的內容都是我干的。我是一名探鬼主播库菲，決...
沈念sama閱讀 40,052評論 3贊 418
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼账忘，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起闪萄，我...
開封第一講書人閱讀 38,910評論 0贊 274
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤梧却，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后败去，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體放航，經(jīng)...
沈念sama閱讀 45,324評論 1贊 310
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內容為張勛視角年9月15日...
茶點故事閱讀 37,542評論 2贊 332
?白月光啟示錄
正文我和宋清朗相戀三年圆裕，在試婚紗的時候發(fā)現(xiàn)自己被綠了广鳍。大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 39,711評論 1贊 348
活死人
序言：一個原本活蹦亂跳的男人離奇死亡吓妆，死狀恐怖赊时，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情行拢，我是刑警寧澤祖秒，帶...
沈念sama閱讀 35,424評論 5贊 343
?日本核電站爆炸內幕
正文年R本政府宣布，位于F島的核電站舟奠，受9級特大地震影響竭缝，放射性物質發(fā)生泄漏。R本人自食惡果不足惜沼瘫，卻給世界環(huán)境...
茶點故事閱讀 41,017評論 3贊 326
男人毒藥：我在死后第九天來索命
文/蒙蒙一抬纸、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧耿戚，春花似錦湿故、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 31,668評論 0贊 22
一樁弒父案坛猪，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至皂股，卻和暖如春砚哆，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背屑墨。一陣腳步聲響...
開封第一講書人閱讀 32,823評論 1贊 269
情欲美人皮
我被黑心中介騙來泰國打工躁锁，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人卵史。一個月前我還...
沈念sama閱讀 47,722評論 2贊 368
代替公主和親
正文我出身青樓战转，卻偏偏與公主長得像，于是被迫代替她去往敵國和親以躯。傳聞我的和親對象是個殘疾皇子槐秧，可洞房花燭夜當晚...
茶點故事閱讀 44,611評論 2贊 353