如何理解linux的平均負(fù)載？

學(xué)習(xí)倪鵬飛老師linux性能優(yōu)化實(shí)踐的筆記轿曙，文中大量內(nèi)容來源于老師的文檔材料，如果喜歡請移步文末截圖中的二維碼支持老師的課程：

一般在我們發(fā)現(xiàn)系統(tǒng)有問題的時候僻孝，大家的第一反應(yīng)肯定都是看下當(dāng)前的CPU使用狀態(tài)导帝，看下當(dāng)前的內(nèi)存使用狀態(tài)，看下當(dāng)前的磁盤使用狀態(tài)穿铆。那么不可避免的大家肯定會使用top這個命令,那么我們今天看下top中的load值是如何計(jì)算的您单。

top

首先，我們簡單的理解下這個指標(biāo)
load average: 0.00, 0.01, 0.05
load average 有3個指標(biāo)荞雏，分別是,1分鐘平均負(fù)載睹限、5分鐘平均負(fù)載、15分鐘平均負(fù)載讯檐，我們可以根據(jù)這三個指標(biāo)羡疗，看到我們當(dāng)前的系統(tǒng)負(fù)載整體是下降的，還是上升的别洪。

好叨恨，理解了3個指標(biāo)的含義后，我們來看下這3個指標(biāo)是如何計(jì)算的挖垛。
平均負(fù)載是指單位時間內(nèi)痒钝，系統(tǒng)處于可運(yùn)行狀態(tài)和不可中斷狀態(tài)的平均進(jìn)程數(shù)，他和CPI使用率并沒有直接的關(guān)系痢毒，那么可運(yùn)行狀態(tài)和不可中斷狀態(tài)怎么理解呢送矩？

可運(yùn)行狀態(tài)：指正在使用CPU或者正在等待CPU的進(jìn)程，也就是我們常用ps aux命令看到的處于R(running,runnable)狀態(tài)的進(jìn)程哪替。

可運(yùn)行狀態(tài)

不可中斷狀態(tài)：指進(jìn)程正處于內(nèi)核態(tài)關(guān)鍵流程中的進(jìn)程栋荸，并且這些流程是不可被打斷的，比如最長久的是等待硬件設(shè)備的I/O響應(yīng)凭舶，也就是我們在ps aux命令中看到的D(Uniterruptible,Disk Sleep)狀態(tài)的進(jìn)程晌块。

比如，當(dāng)一個進(jìn)程向磁盤寫數(shù)據(jù)時帅霜，為了保證數(shù)據(jù)的一致性匆背，在得到磁盤回復(fù)前，它是不能被其他進(jìn)程或者中斷打斷的身冀，這個時候的進(jìn)程就處于不可中斷狀態(tài)钝尸，如果此時的進(jìn)程被打斷了括享，就容易出現(xiàn)磁盤數(shù)據(jù)與進(jìn)程數(shù)據(jù)不一致的問題。

所以珍促，不可中斷狀態(tài)铃辖，實(shí)際上是系統(tǒng)對進(jìn)程和硬件設(shè)備的一種保護(hù)機(jī)制。

因此踢星，你可以簡單的理解為澳叉，平均負(fù)載其實(shí)就是平均活躍進(jìn)程數(shù)隙咸，平均活躍進(jìn)程數(shù)沐悦，直觀上的理解就是單位時間內(nèi)的活躍進(jìn)程數(shù)。但他實(shí)際上是活躍進(jìn)程數(shù)的指數(shù)衰減平均值五督。這“指數(shù)衰減平均”可以不用計(jì)較藏否，只是一種更快速的計(jì)算方式，你可以把它直接當(dāng)成活躍進(jìn)程數(shù)的平均值即可充包。

既然平均的是活躍進(jìn)程數(shù)副签，那么最理想的就是每個CPU上剛好運(yùn)行著一個進(jìn)程，這樣每個CPU都得到了充分的利用基矮，比如當(dāng)平均負(fù)載為2時淆储，意味著什么呢？

CPU核心數(shù)家浇，指邏輯CPU本砰，即一個CPU不開超線程時為2個物理核心，開了超線程后就變成了4個邏輯核心钢悲。
在只有2個CPU核心的系統(tǒng)上点额，意味著所有CPU核心數(shù)都剛好被完全占用。
在有4個CPU核心的系統(tǒng)上莺琳，意味著CPU有50%的空閑还棱。
而在只有2個CPU核心的系統(tǒng)中，則意味著有一半的進(jìn)程競爭不到CPU惭等。

平均負(fù)載多少時合理珍手？

在評估這個值的時候，首先我們要看下當(dāng)前有多少個邏輯CPU辞做，一般我們直接看/proc/cpuinfo的數(shù)據(jù)即可

[root@localhost ~]# cat /proc/cpuinfo |grep "model name"|wc -l
16

那么比如我這臺機(jī)器珠十，看到的就是16個邏輯核心了。
有了CPU個數(shù)凭豪，我們就可以判斷出焙蹭，當(dāng)平均負(fù)載比CPU個數(shù)還大的時候，系統(tǒng)已經(jīng)出現(xiàn)了過載嫂伞。

不過這個觀察也是要評估多個指標(biāo)的孔厉，我們要同時用1分鐘5分鐘15分鐘的值來大概的估算這個設(shè)備的負(fù)載是呈現(xiàn)上升或者下降的趨勢拯钻，其實(shí)最好的方式是通過監(jiān)控的手段，采集足夠多的load值撰豺，這樣可以更精準(zhǔn)的知道自己設(shè)備的負(fù)載情況粪般。

平均負(fù)載與CPU使用率

在日常使用中，我們經(jīng)常容易把平均負(fù)載和CPU使用率混淆污桦，這里我們做下區(qū)分亩歹。
可能我們會有疑惑，既然平均負(fù)載代表的是活躍進(jìn)程數(shù)凡橱，那么平均負(fù)載搞了小作，不就意味著CPU使用率高了嗎？

這里我們還得回到平均負(fù)載的含義上來稼钩，平均負(fù)載是指單位時間內(nèi)顾稀，處于可運(yùn)行狀態(tài)和不可中斷狀態(tài)的進(jìn)程數(shù)，所以坝撑，他不僅包擴(kuò)了正在使用CPU的進(jìn)程静秆，還包括等待CPU和等待I/O的進(jìn)程。

而CPU使用率巡李，是單位時間內(nèi)CPU繁忙情況的統(tǒng)計(jì)抚笔，和平均負(fù)載并不一定完全對應(yīng)。比如：

CPU密集型進(jìn)程侨拦，使用大量CPU會導(dǎo)致平均負(fù)載升高殊橙，此時這兩者是一致的。
I/O 密集型進(jìn)程阳谍，等待I/O也會導(dǎo)致平均負(fù)載升高蛀柴，但是CPU使用率不一定很高。
大量等待CPU的進(jìn)程調(diào)用也會導(dǎo)致平均負(fù)載升高矫夯，此時的CPU使用率也會比較高鸽疾。

平均負(fù)載案例分析

這里會用到2個工具，stress和sysstat
stress是一個Linux系統(tǒng)壓力測試工具训貌，這里我們用作異常進(jìn)程模擬平均負(fù)載升高的場景制肮。

sysstat是一個linux性能工具，用來監(jiān)控和分析系統(tǒng)的性能递沪，以下案例中會用到這個包的2個命令mpstat和pidstat豺鼻。

mpstat 是一個常用的多核CPU性能分析工具用來實(shí)時查看每個CPU的性能指標(biāo)，一級所有CPI的平均指標(biāo)款慨。
pidstat 是一個常用的進(jìn)程性能分析工具儒飒，用來實(shí)時查看進(jìn)程的CPU、內(nèi)存檩奠、I/O以及上下文切換等性能指標(biāo)桩了。

場景1：CPU密集型進(jìn)程

我們打開終端一運(yùn)行stree命令附帽，模擬一個CPU使用率100%的場景：

[root@localhost ~]# stress --cpu 1 --timeout 600
stress: info: [5399] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

我們打開終端二，查看CPU負(fù)載的上升狀態(tài)

[root@localhost ~]# uptime
 01:50:42 up 1 day,  1:42,  3 users,  load average: 0.68, 0.22, 0.11
[root@localhost ~]# uptime
 01:50:45 up 1 day,  1:42,  3 users,  load average: 0.71, 0.23, 0.12
[root@localhost ~]# uptime
 01:51:10 up 1 day,  1:43,  3 users,  load average: 0.81, 0.29, 0.14
[root@localhost ~]# uptime
 01:54:58 up 1 day,  1:47,  4 users,  load average: 1.03, 0.68, 0.33

一段時間后井誉，我們發(fā)現(xiàn)1分鐘的平均load值超過了1蕉扮，為啥？ 設(shè)備上還有些其他進(jìn)程運(yùn)行啊颗圣。

打開終端三喳钟，查看CPU使用狀態(tài)

[root@localhost ~]# mpstat -P ALL 5
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)


01:53:08 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
01:53:13 AM  all    6.24    0.00    0.01    0.00    0.00    0.00    0.01    0.00    0.00   93.73
01:53:13 AM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.20    0.00    0.00   99.80
01:53:13 AM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    2    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    4    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    5    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    6    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    8    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    9    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   10    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   11    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   12    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   13    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   14    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   15  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

這里我們可以看到，在CPU15上 CPU的使用率一直處于100%狀態(tài)在岂，使用這個工具可以持續(xù)看到狀態(tài)的變化奔则。

從終端二中可以看到，1分鐘的平均負(fù)載慢慢會增加到1洁段，而從終端三中可以看到应狱，正好有一個CPU的使用率為100%共郭，但他的iowait為0祠丝，這說明，平均負(fù)載的升高正是由于CPU使用率為100%除嘹。

那么写半，到底是哪個進(jìn)程導(dǎo)致了CPU使用率為100%呢？你可以使用pidstat來查詢：

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:00:20 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
02:00:25 AM     0      8451  100.00    0.00    0.00  100.00     2  stress
02:00:25 AM     0      8456    0.00    0.20    0.00    0.20     3  pidstat
02:00:25 AM     0      8457    0.20    0.20    0.00    0.40    15  client

Average:      UID       PID    %usr %system  %guest    %CPU   CPU  Command
Average:        0      8451  100.00    0.00    0.00  100.00     -  stress
Average:        0      8456    0.00    0.20    0.00    0.20     -  pidstat
Average:        0      8457    0.20    0.20    0.00    0.40     -  client

從這里尉咕，可以明顯看到叠蝇，stress進(jìn)程的CPU使用率為100%。

場景二：I/O 密集型進(jìn)程

首先還是運(yùn)行stress命令年缎，但這次模擬I/O壓力悔捶，即不停的執(zhí)行sync：
打開終端一，執(zhí)行stress

[root@localhost ~]# stress -i 1 --timeout 3600
stress: info: [8817] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

打開終端二

[root@localhost ~]# uptime
 02:02:36 up 1 day,  1:54,  4 users,  load average: 0.83, 0.85, 0.56
[root@localhost ~]# uptime
 02:05:27 up 1 day,  1:57,  4 users,  load average: 0.99, 0.92, 0.63

這里单芜，也會看到蜕该，load會不斷的升高

打開終端三

[root@localhost ~]# mpstat -P ALL 5
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)
Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    0.05    0.00    5.93    0.34    0.00    0.00    0.05    0.00    0.00   93.63
Average:       0    0.16    0.00    0.48    0.00    0.00    0.00    0.14    0.00    0.00   99.22
Average:       1    0.03    0.00    0.09    0.01    0.00    0.00    0.03    0.00    0.00   99.84
Average:       2    0.03    0.00    0.09    0.00    0.00    0.00    0.01    0.00    0.00   99.88
Average:       3    0.09    0.00    0.23    0.00    0.00    0.00    0.03    0.00    0.00   99.65
Average:       4    0.13    0.00    0.53    0.00    0.00    0.00    0.05    0.00    0.00   99.29
Average:       5    0.02    0.00    0.05    0.00    0.00    0.00    0.05    0.00    0.00   99.88
Average:       6    0.02    0.00    0.35    0.00    0.00    0.00    0.08    0.00    0.00   99.56
Average:       7    0.02    0.00    0.04    0.00    0.00    0.00    0.03    0.00    0.00   99.90
Average:       8    0.02    0.00    0.14    0.00    0.00    0.00    0.04    0.00    0.00   99.80
Average:       9    0.10    0.00    0.28    0.00    0.00    0.00    0.03    0.00    0.00   99.59
Average:      10    0.09    0.00    0.34    0.00    0.00    0.00    0.05    0.00    0.00   99.52
Average:      11    0.01    0.00    0.06    0.00    0.00    0.00    0.03    0.00    0.00   99.90
Average:      12    0.03    0.00   33.73    1.96    0.00    0.00    0.05    0.00    0.00   64.23
Average:      13    0.02    0.00    0.04    0.00    0.00    0.00    0.02    0.00    0.00   99.92
Average:      14    0.03    0.00    2.43    0.12    0.00    0.00    0.04    0.00    0.00   97.37
Average:      15    0.04    0.00   56.38    3.30    0.00    0.00    0.17    0.00    0.00   40.12

這里看到，CPU的use使用不是很高洲鸠，反而sys使用的比較高堂淡，分布在了2個CPU上，約等于100%
同時可以看到iowait的值也升高了一些扒腕，由于我的設(shè)備全是ssd磁盤绢淀，所以這個io的性能可能會稍微好一些。

從以上操作中瘾腰，我們看到1分鐘的平均負(fù)載會慢慢的增加皆的，其中一個CPU的系統(tǒng)CPU使用率提升到了56，同時iowait也提升到了3蹋盆，這說明平均負(fù)載的升高是由于系統(tǒng)資源使用和iowait導(dǎo)致费薄。

這里更新了最新版的sysstat包

[root@localhost ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-12.1.1-1.x86_64.rpm
[root@localhost ~]# rpm -Uvh sysstat-12.1.1-1.x86_64.rpm

那么到底是哪個進(jìn)程内狗，導(dǎo)致系統(tǒng)CPU使用率特別高，及iowait特別高呢义锥？

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:34:53 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:34:58 AM     0       730    0.00    0.20    0.00    0.00    0.20    12  xfsaild/vda6
02:34:58 AM     0      1471    0.00    0.20    0.00    0.00    0.20    10  kworker/10:2
02:34:58 AM     0      3042    0.00    0.40    0.00    0.00    0.40     7  kworker/7:1H
02:34:58 AM     0     11617    0.00    1.59    0.00    0.00    1.59     2  kworker/u32:1
02:34:58 AM     0     15272    0.00   91.43    0.00    0.40   91.43     7  stress
02:34:58 AM     0     15273    0.00    0.20    0.00    0.00    0.20    14  kworker/u32:0
02:34:58 AM     0     15274    0.20    0.40    0.00    0.00    0.60     5  pidstat

通過以上的信息柳沙，可以很清晰的看到，是由于stress進(jìn)程出現(xiàn)了大量的系統(tǒng)使用拌倍。

場景三：大量進(jìn)程的場景

當(dāng)系統(tǒng)中運(yùn)行進(jìn)程超出CPU運(yùn)行能力時赂鲤，就會出現(xiàn)等待CPU的進(jìn)程。
我們打開終端一：使用stress模擬24個進(jìn)程：

[root@localhost ~]# stress -c 24 --timeout 3600
stress: info: [11726] dispatching hogs: 24 cpu, 0 io, 0 vm, 0 hdd

打開終端二：看下當(dāng)前的負(fù)載值

[root@localhost ~]# uptime
 02:20:36 up 1 day,  2:12,  4 users,  load average: 17.22, 5.98, 2.61
[root@localhost ~]# uptime
 02:20:52 up 1 day,  2:13,  4 users,  load average: 18.72, 6.86, 2.95
[root@localhost ~]# uptime
 02:24:03 up 1 day,  2:16,  4 users,  load average: 23.77, 14.94, 6.85

打開終端三：看下進(jìn)程的資源使用信息

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:28:14 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:28:19 AM     0        43    0.00    0.20    0.00    0.00    0.20     7  ksoftirqd/7
02:28:19 AM     0      2292    0.20    0.00    0.00    0.00    0.20    11  dstat
02:28:19 AM     0     11727   48.81    0.00    0.00   44.05   48.81     5  stress
02:28:19 AM     0     11728   44.64    0.00    0.00    0.00   44.64    12  stress
02:28:19 AM     0     11729   41.27    0.00    0.00   49.60   41.27    11  stress
02:28:19 AM     0     11730   46.03    0.00    0.00   41.27   46.03     2  stress
02:28:19 AM     0     11731   59.92    0.00    0.00   30.16   59.92    15  stress
02:28:19 AM     0     11732   47.62    0.00    0.00   25.60   47.62    13  stress
02:28:19 AM     0     11733   65.67    0.00    0.00   22.02   65.67     2  stress
02:28:19 AM     0     11734   41.67    0.00    0.00   50.40   41.67    10  stress
02:28:19 AM     0     11735   54.17    0.00    0.00   32.34   54.17    15  stress
02:28:19 AM     0     11736   42.06    0.00    0.00   50.20   42.06     6  stress
02:28:19 AM     0     11737   35.91    0.00    0.00   29.96   35.91     3  stress
02:28:19 AM     0     11738   50.20    0.00    0.00    5.16   50.20    10  stress
02:28:19 AM     0     11739   42.06    0.00    0.00   49.60   42.06     6  stress
02:28:19 AM     0     11740   58.73    0.00    0.00   34.92   58.73     4  stress
02:28:19 AM     0     11741   46.63    0.00    0.00   13.49   46.63     1  stress
02:28:19 AM     0     11742   43.45    0.00    0.00   50.79   43.45    14  stress
02:28:19 AM     0     11743   44.05    0.00    0.00   45.24   44.05     7  stress
02:28:19 AM     0     11744   56.55    0.00    0.00   12.70   56.55     0  stress
02:28:19 AM     0     11745   46.23    0.00    0.00   49.80   46.23     5  stress
02:28:19 AM     0     11746   49.40    0.00    0.00   41.27   49.40    11  stress
02:28:19 AM     0     11747   43.65    0.00    0.00   49.40   43.65    14  stress
02:28:19 AM     0     11748   59.33    0.00    0.00    0.99   59.33     8  stress
02:28:19 AM     0     11749   46.43    0.00    0.00   45.24   46.43     4  stress
02:28:19 AM     0     11750   51.19    0.00    0.00   24.60   51.19     9  stress
02:28:19 AM     0     14276    0.00    0.40    0.00    0.20    0.40    10  pidstat

我們發(fā)現(xiàn)柱恤，運(yùn)行的24個stress進(jìn)程数初，出現(xiàn)了資源爭搶的問題，既然出現(xiàn)了資源爭搶梗顺，就會出現(xiàn)等待時間wait泡孩。

思考：
iowait多少算高？
注意寺谤，iowait不等于cpu wait?

課程原始地址

最后編輯于：2018.11.24 03:01:23

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

人面猴
序言：七十年代末仑鸥，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子变屁，更是在濱河造成了極大的恐慌眼俊，老刑警劉巖，帶你破解...
沈念sama閱讀 207,248評論 6贊 481
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件粟关，死亡現(xiàn)場離奇詭異疮胖，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)闷板，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 88,681評論 2贊 381
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門澎灸，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人遮晚，你說我怎么就攤上這事性昭。” “怎么了鹏漆？”我有些...
開封第一講書人閱讀 153,443評論 0贊 344
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵巩梢，是天一觀的道長。經(jīng)常有香客問我艺玲，道長括蝠，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 55,475評論 1贊 279
?港島之戀（遺憾婚禮）
正文為了忘掉前任饭聚，我火速辦了婚禮忌警，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己法绵，他們只是感情好箕速，可當(dāng)我...
茶點(diǎn)故事閱讀 64,458評論 5贊 374
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著朋譬，像睡著了一般盐茎。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上徙赢，一...
開封第一講書人閱讀 49,185評論 1贊 284
城市分裂傳說
那天字柠，我揣著相機(jī)與錄音，去河邊找鬼狡赐。笑死窑业，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的枕屉。我是一名探鬼主播常柄，決...
沈念sama閱讀 38,451評論 3贊 401
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼搀擂！你這毒婦竟也來了西潘？” 一聲冷哼從身側(cè)響起，我...
開封第一講書人閱讀 37,112評論 0贊 261
萬榮殺人案實(shí)錄
序言：老撾萬榮一對情侶失蹤哥倔，失蹤者是張志新（化名）和其女友劉穎秸架，沒想到半個月后揍庄，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體咆蒿，經(jīng)...
沈念sama閱讀 43,609評論 1贊 300
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 36,083評論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年蚂子，在試婚紗的時候發(fā)現(xiàn)自己被綠了沃测。大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點(diǎn)故事閱讀 38,163評論 1贊 334
活死人
序言：一個原本活蹦亂跳的男人離奇死亡食茎，死狀恐怖蒂破，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情别渔，我是刑警寧澤附迷，帶...
沈念sama閱讀 33,803評論 4贊 323
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站哎媚，受9級特大地震影響喇伯，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜拨与，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 39,357評論 3贊 307
男人毒藥：我在死后第九天來索命
文/蒙蒙一稻据、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧买喧，春花似錦捻悯、人聲如沸匆赃。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,357評論 0贊 19
一樁弒父案今缚，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽算柳。三九已至，卻和暖如春姓言，著一層夾襖步出監(jiān)牢的瞬間埠居，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 31,590評論 1贊 261
情欲美人皮
我被黑心中介騙來泰國打工事期，沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留滥壕，地道東北人。一個月前我還...
沈念sama閱讀 45,636評論 2贊 355
代替公主和親
正文我出身青樓兽泣，卻偏偏與公主長得像绎橘，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子唠倦，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 42,925評論 2贊 344