求赞美苏州评弹的优美句子

求赞美苏州评弹的优美句子

1. 描写评弹的句子

我喜欢听这，吴语软侬的苏州评弹。

尤其是那三弦琵琶的，悠扬的丝弦声和清丽委婉的，吴语软侬的唱腔，令我赏心悦目。苏州评弹，把江南水乡水的清韵，味渗入到，弹词丝弦音韵的骨髓里，化作评弹的灵魂。

使我感到，欣赏评弹艺术音韵中，如同喝了一大碗江南水乡，特酿的存年米酒来，味清香四溢，鲜亮甘纯，人微酡沉醉。

苏州评弹和刺绣、苏州园林，被称为苏州三绝。这三绝无论这，评弹刺绣园林艺术的塑造，都是这样精美清新秀丽，使人感受到苏州人，聪慧智巧和这，艺术的无穷的魅力。

在这月夜江南小河边，潺潺流水声中的茶楼里，喝着春茶听着这，清音雅乐般的评弹来，那不知有多惬意哟！在白天铺着青石板的，水乡小镇上徜徉在店铺里，欣赏着精细雅致的、惟妙惟肖的苏绣画品里。或是带上家人流连在，这清泉流韵，千姿百态的亭台楼阁，琪花瑶草和山石奇叠，相趣成荫的苏州园林中，真让人领受到，苏州三绝的艺术魅力，而使人惊叹万分来。

（二）苏州评弹，最最令我赞赏的，应是她的角色塑造。

也许这么说并不确切，有人可能会说我外行：苏州评弹只是评书、弹词而已，谈不上角色不角色，弹词演员不过是，在演绎故事和角色。其实我的赞赏，也正是因此而生的。

别的形式的评书、鼓书、快书、琴书，等等讲说者、演绎者大多停留在，说“书”的层面，但苏州弹词的表演者，在说“书”的同时，也进入了，“角”的内心世界、倾诉者“角”的内在情感。就以我所看到的《雷雨》为例，许多的细节和情节，简直让人分不清，他们到底是在“说书”，还是在“演戏”。

语气语调的把握、人物情感的揣度、场景环境的拟设……叹为观止呀！有的时候，我就有一种错觉，演绎者是在演绎故事吗？他们不是在，明明宣泄自己的情感、表达自己的诉求吗？戏里戏外，无障碍出入，只有嘴上功夫，没有高超的“演”技，应是无法做到的。演绎者们在“演戏”时，是绝对不操吴语的，纯正的普通话！相信不懂苏州话的观众，也会喜欢的。

（三）据民间传说，在三月春天的江南，桃红柳绿，碧水青青，小桥流水人家的苏州。这位乾隆皇帝爷乔装打扮，坐在小舟中，在船桨的欸乃声里，在潺潺流水的小河里，望着河两岸那粉墙灰瓦，雕梁花窗的茶楼里，传来的丝丝缕缕的，清丽委婉的声音所吸引，细细打听那是茶楼里，在传唱这苏州评弹呢。

于是那位皇帝爷趋之入座，捧着苏州东西洞庭山上，新采摘的“碧螺春”新茶，的听着苏州城里的名家，说唱评弹艺人王周士的弹唱。被他那悠扬顿挫，吴语软侬，清丽悠婉的弹唱功夫所折服。

在这大弦嘈嘈切切，小弦错错杂杂，如大珠小珠落玉盘的，声韵所迷倒。如醉如痴，不厌其烦，听了一遍又一遍，竟流连忘返。

虽然乾隆听不懂词句，但被那眉飞色舞，声韵俱到的评弹神韵，和表演艺术的魅力，所倾倒！觉得余音绕梁，回味三省，总觉得不过瘾，于是招王周士进京，专门为他，在后宫中演唱评弹，听得高兴之余忘乎所以，破例赐予七品官衔。可见这位帝王，对苏州评弹的喜爱了。

2. 求几句赞美苏州的优美的佳句

上有天堂，下有苏杭

姑苏城外寒山寺，夜半钟声到客船。

苏湖熟，天下足

送人游吴

【唐】杜荀鹤

君到姑苏见，人家尽枕河。

古宫闲地少，水巷小桥多。

夜市卖菱藕，春船载绮罗。

遥知未眠月，乡思在渔歌。《和梦得夏至忆苏州呈卢宾客》

忆在苏州日，常谙夏至筵。粽香筒竹嫩，炙脆子鹅鲜。

水国多台榭，吴风尚管弦。每家皆有酒，无处不过船。

交印君相次，褰帷我在前。此乡俱老矣，东望共依然。

洛下麦秋月，江南梅雨天。齐云楼上事，已上十三年。再游姑苏玉芝观

【唐】许浑

高梧一叶下秋初，迢递重廊旧寄居。

月过碧窗今夜酒，雨昏红壁去年书。

玉池露冷芙蓉浅，琼树风高薜荔疏。

明日挂帆更东去，仙翁应笑为鲈鱼。

3. 赞美平江的句子

这条平江古街，我在苏州七天，竟然游了三次，小桥流水的诗情画意，车行船橹的悠闲怡然，才子佳人的风流韵事，苏州评弹的浅语软唱，都体验尽兴了。

再游平江前，一夜的蚊子，将我折腾至凌晨五点才睡，七点又准时起床，真担心自己今天体力不支。不过一天下来，发现行走在如诗的江南里，却是没有一点倦意，真是江南好，瞌睡都可少啊。

早上陪客人吃早餐，说起我昨天的人力三轮及平江古街，客人一听，饶有兴致，说自己虽是苏州人，却还没坐过那平江上的手摇船呢。于是，草餐后，效仿我的昨日之旅，叫了两辆人力三轮，朝平江古街出发。

平江路是苏州的一条历史老街，是一条沿河的小路，其河名为平江河。宋元时候苏州又名平江，以此名路。河路都不阔，河上行走的是摇橹船，路上仅可过黄包车而已。故有同一路上，“水陆并行，河街相邻”，这是很典型的水乡特色。

在苏州最古老的城市地图宋代《平江图》上，就有平江路这条街道，是当时苏州东半城的主干道，800年来，平江路不但河流形态、街道建制与原先基本相仿，而且还分明的保留着“水路并行，河街相邻”的水乡格局。小桥流水、粉墙黛瓦，房屋的体量、街道的宽度和河道，比例

恰当，显示出疏朗淡雅的风格；平江路两边小巷特别是东边，还较好地保留了多条水巷，是今天苏州古城最有水城原味的一处古街区，与观前街一巷之隔，但其清静古朴的生活气息与咫尺外的鼎沸喧哗迥然两个世界。

平江路南起干将东路，北越白塔东路和东北街相接，古名叫做“十泉里”，较早出现了1834年的《吴门表隐》中，说道：“平江路古名十泉里，有古井十口，华阳桥南一，奚家桥南一，苑桥北一”，很详尽。平江路是沿河的路，这条路我去走的时候，看看地图，全长是1606米，也就是三里路长，两侧的横街窄巷就多了，比如狮子寺巷、传芳巷、东花桥巷、曹胡徐巷、大新桥巷、卫道观前、中张家港、大儒巷、萧家巷、钮家巷、悬桥巷等等。

平江双桥

清晨的阳光斜斜的照在流水翠柳上，一路走过昨日的风景，我们直奔手摇船的小码头而来。150元一艘手摇船，三个人坐上去，宽敞舒适。船夫一边摇船，一边讲解平江的历史、发展、以及那些和爱情有关的事，又给我们唱了几曲当地小调，甚至还给我们介绍了他的博客，真是不可貌相啊！只是说唱到中途，他明确告诉我们，上岸时，希望给点辛劳费的哦！

船在水上，人在画中，小桥流水，倒映着斑驳旧影，垂柳依依，掩映着白墙黑瓦。悠悠水乡，多少沧桑，古朴幽静，船橹摇荡。我们在船上看古街的风景，游人在古街倚栏看我们，不时有外国游客SAY HELLO，举起相机，对准我们美丽的船摇手。

下船之后，我们继续步行平江路。看到很多地方在小规模施工建房，却听说必须是“修旧如旧”的要求。沿街不少老宅实已作酒吧、会所，只是外表并不张扬，悄悄掩隐在木制门板之下，乍看起来与普通民居并无二致，只有从格外精致的雕花门廊上可以窥出些端倪。不时可见外国游客步行路上，或是乘坐人力车，观赏着如诗如画的水乡风景。又有许多美术学生，寻一处古树脚下，对着小桥流水，静心描绘。更有多对新人，身着古装旗袍，在这里拍摄结婚照，演一回江南才子遇佳人，将这美丽的情节，定格为人生记忆的永久画面。也有一两家古琴馆，默默的临平江之水，幽静的处平江古街，却不闻琴声，只有沿路走过的小店里，播放着苏州评弹的曲子，在依依的柳枝里，在悠悠的流水上，飘摇出古老的江南风情，传唱着才子佳人的动人故事。

4. 高分 求一篇赞美 苏州 的文

苏州缘

十多年前，读了余秋雨的《白发苏州》，一直向往苏州，想亲聆吴中地区的吴侬软语。

这次借考察之机，游览了苏州，如愿以偿。

中午时分，我们来到寒山寺。这一座普普通通的寺院，面河靠城，因唐代诗人张继《夜泊枫桥》一诗而名闻千古，列为中国十大名寺之一，至今游人络绎不绝。摩肩接踵的游客，怀着同样的心情，拜谒了张继雕像，听导游说，上去摸一摸，文运旺，财运好，大家竞争着去抚摸，从右手开始，头部、左手，竟然摸出一条黑亮的痕迹。看来大家对导游的话深信不疑。大运河滚滚不息，而张继千年不语，不知这位哲者在思考着什么！

一拨游人走了，又一拨游人来到。大家好象都在寻找张继当年的吟咏，而不是来看这座古寺。没有几个人进寺去敬香献礼，大家都围在寒山寺周围参观，品评题写在墙壁上的《夜泊枫桥》诗句。

游人争着站在张继雕像前留影，好象要在光影中汲取诗人灵气，演绎千古师生之情，写出惊心动魄的千古名句。

远眺虎丘塔。在阳光中，隐隐看到虎丘塔斜斜地立在一座山丘上。这座江南名塔埋藏着许多典故，我看不出个所以然，便不再关注。

苏州河流多，桥也多。河道中慢悠悠行驶的小舫，好象是周作人所写的“乌篷船”，但又不象。河道纵横交叉，穿街越巷，每一条水道都相通，水上交通主要靠轻便的小舫。市民摇着小舫出行，慢吞吞地荡行在小河中，只见船动，不见水流。有河必有桥，三五里一座石拱桥，桥身桥柱都是石头，保持着古典风格。河桥是苏州城一道特殊的风景。

苏州建城置郡自春秋时期，曾为帝都红粉，辉煌一时，见证了残酷的吴越战争，历经2500多年的历史风霜，至今仍然焕发出生命的光彩。苏州与名人结缘，历代达官贵人，文人谪客，或是江南红粉，踏遍了苏州的山山水水，留下富有情趣的吟咏和故事。闻名而来的人，一为羡慕苏州之名，二为疗养，放松心情。苏州好象一位慈善的老人，接待了历代贬谪而来的官僚和潦倒的文人，可谓中国文化的后院。

历史冷落了苏州，自为吴国都城后，江南名城苏州不再受到历史的青睐，游移在帝王们的视野之外。苏州毕竟不同于各个皇城，她位于江南水乡泽国，汲取天地之灵气，天生丽质，出污泥而不染，依然秀丽如初，吸引王公贵族和达官贵人来游览。今天，苏州深厚的文化积淀，依然保持着历代以来的魅力，吸引了国内外一拨又一拨游客。大家来去匆匆，就为目睹苏州的风采，感受中国文化浸染的古城之韵。

晚上，我们相邀去观前街逛逛，三个一伙，五个一群，混入市民行列。可怎么侨装，都暴露我们外地游客的身份，完全不同于慢悠悠的苏州人。街上行人，一派悠闲的样子，一边散步，一边与同行者聊天，吴侬细语。特别是老年人聊天，语音清越，声调悠悠，娓娓而道，情彩生动。观前街是购物步行街，商号店铺林立，处处可见叫卖声，“大减价”“大拍卖”的牌子立在门口，吸引行人停步购物。走了几家服装店，没看中，出来看街头风景。

第二天，我们游览了狮子林园林。

狮子林园林是人造的山水风景，消遣休闲胜地，传为一太监所建。这些石头经能工巧匠精心设计，衔接组合，含蓄内敛，重叠幽深，布置得很有玄机。小桥弯折，流水柔柔，怪石嶙峋，错落有致。小径弯曲伸舒，上下交叉纵横，回转顾盼，处处异景纷呈。园中人头攒动，小径上人影憧憧。进去了，才知道这个园子好象一个迷宫，小径弯弯曲曲，忽上忽下，一会儿钻洞，一会儿攀登。看到对方就在头顶上，攀援上去了，却看到人站在对面山石上，隔着几重山石，幽趣顿生。我紧跟着同伴在园林游览，刚走一会儿却不见人了，爬上高处看，原来他们从另一条小径穿越上了另一座山峰。我站起来观看整个园林全景，园子不大，弯弯曲曲向前伸延，处处是峰回路转，曲径通幽。微风吹来，凉爽生津，刚刚冒出来的热汗消失了。此时，我想如能邀几个知交好友，在这里品茗论道，读书作文，何偿不是人间一件乐事！

苏州城有水无山，按中国传统文化理论来说，有智而无仁，未免令人遗憾。兴建园林，创造山水风光，把太湖石和苏州的水进行艺术剪接和粘贴，组合新的文化审美空间，既是艺术，又是娱乐休闲胜地，此乃一举两得之美事。当年那位退休来苏州居住的老太监，可能没有想到，他捐建狮子林，给苏州城创造了一座文化瑰宝，是功德无量的，后人将如何景仰如何颂扬他。这需要多宽广的胸怀和人格魅力呀！

站在狮子林高处，我心飘然，熏熏欲醉。来到这个人间天堂，忘却世间的一切烦恼，洗涤凡虑，排除俗念，真是个修行的风水宝地！

5. 求一篇赞美苏州的诗歌

千古名园点绿尘，

假山真水秀泉吟。

雕梁画柱无心赏，

凤竹青青诱客魂

或者

、[诗情画意] 二泉映月（外一首）[推荐]

1、二泉映月 丝弦无心，拉痛了多少魂灵 ----题记 惠山，巍峨的手柄 二泉，柔情的弦 坐在水畔光滑的石上 你紧闭双眼 是眉的渴望 还是睫的渴望 颤抖的手指 在两根头发上轻轻拉响 音 。诗情画意] 二泉映月

一切都被夜色浸透 世界在一只面具的后面 为自己设置重重陷阱 为夜画出狼群的嗷叫 而心依然默默前行 从一条路 到另一条路 反复辨认自己的掌纹 难以掩饰的痛苦 无法放逐的屈辱 拧紧 如两根颤弦 两只失 。 今夜没有月光 月光都去了天下第二泉 拟或你我的枕边 月光在弦上游走 辗转摩擦 一支泪流满面的曲子 钻木取火 点燃了一泓清泉 却点不燃你的苦难 眸子依然黑暗无光 窗外的飘零细雨 轻摇我无梦的床 我知 。 月者 月是夜的眼眸 时而，妩媚 时而，清澈 时而，含蓄 比花的翅膀还会飞翔 云间穿梭抚摸着游子的心 轮回的欲念撕裂着渴爱的心 只是月圆何时 只可待，只可忆 二 泉 映 月 吾师 而今你的身影是否 依旧倒映在凄清的夜色里 牵引着二胡 以那阙全新的行路难 更加沉重地叩击着 昏暗的街巷上长长的石板路 把生命的刚韧注入一张弓 命运在两根悬丝之上绷紧再绷紧 澎 。

解Bug之路——Nginx 502 Bad Gateway

转载：https://www.cnblogs.com/alchemystar/p/13409534.html

前言

事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。

Bug现场

首先，这个问题其实并不难解决，但是这个问题引发的现象倒是挺有意思。先描述一下现象吧，笔者要对自研的dubbo协议隧道网关进行压测(这个网关的设计也挺有意思，准备放到后面的博客里面)。先看下压测的拓扑吧:

为了压测笔者gateway的单机性能，两端仅仅各保留一台网关，即gateway1和gateway2。压到一定程度就开始报错，导致压测停止。很自然的就想到，网关扛不住了。

网关的情况

去Gateway2的机器上看了一下，没有任何报错。而Gateway1则有大量的502报错。502是Bad Gateway，Nginx的经典报错，首先想到的就是Gateway2不堪重负被Nginx在Upstream中踢掉。

那么，就先看看Gateway2的负载情况把，查了下监控，发现Gateway2在4核8G的机器上只用了一个核，完全看不出来有瓶颈的样子，难道是IO有问题？看了下小的可怜的网卡流量打消了这个猜想。

Nginx所在机器CPU利用率接近100%

这时候，发现一个有意思的现象,Nginx确用满了CPU!

再次压测，去Nginx所在机器上top了一下，发现Nginx的4个Worker分别占了一个核把CPU吃满-_-!

什么，号称性能强悍的Nginx竟然这么弱，说好的事件驱动\epoll边沿触发\纯C打造的呢？一定是用的姿势不对！

去掉Nginx直接通信毫无压力

既然猜测是Nginx的瓶颈,就把Nginx去掉吧。Gateway1和Gateway2直连，压测TPS里面就飙升了，而且Gateway2的CPU最多也就吃了2个核，毫无压力。

去Nginx上看下日志

由于Nginx机器权限并不在笔者手上，所以一开始没有关注其日志，现在就联系一下对应的运维去看一下吧。在accesslog里面发现了大量的502报错，确实是Nginx的。又看了下错误日志，发现有大量的

Cannot assign requested address

由于笔者读过TCP源码，一瞬间就反应过来，是端口号耗尽了！由于Nginx upstream和后端Backend默认是短连接，所以在大量请求流量进来的时候回产生大量TIME_WAIT的连接。

而这些TIME_WAIT是占据端口号的，而且基本要1分钟左右才能被Kernel回收。

cat /proc/sys/net/ipv4/ip_local_port_range3276861000

也就是说，只要一分钟之内产生28232(61000-32768)个TIME_WAIT的socket就会造成端口号耗尽，也即470.5TPS(28232/60),只是一个很容易达到的压测值。事实上这个限制是Client端的,Server端没有这样的限制，因为Server端口号只有一个8080这样的有名端口号。而在upstream中Nginx扮演的就是Client,而Gateway2就扮演的是Nginx

为什么Nginx的CPU是100%

而笔者也很快想明白了Nginx为什么吃满了机器的CPU,问题就出来端口号的搜索过程。

让我们看下最耗性能的一段函数:

int __inet_hash_connect(...){// 注意，这边是static变量static u32 hint;// hint有助于不从0开始搜索，而是从下一个待分配的端口号搜索u32 offset = hint + port_offset;.....inet_get_local_port_range(&low, &high);// 这边remaining就是61000 - 32768remaining = (high - low) + 1......for (i = 1; i <= remaining; i++) {port = low + (i + offset) % remaining;/* port是否占用check */....goto ok;}.......ok:hint += i;......}

看上面那段代码，如果一直没有端口号可用的话，则需要循环remaining次才能宣告端口号耗尽，也就是28232次。而如果按照正常的情况，因为有hint的存在，所以每次搜索从下一个待分配的端口号开始计算，以个位数的搜索就能找到端口号。如下图所示:

所以当端口号耗尽后，Nginx的Worker进程就沉浸在上述for循环中不可自拔，把CPU吃满。

为什么Gateway1调用Nginx没有问题

很简单，因为笔者在Gateway1调用Nginx的时候设置了Keepalived，所以采用的是长连接，就没有这个端口号耗尽的限制。

Nginx 后面有多台机器的话

由于是因为端口号搜索导致CPU 100%,而且但凡有可用端口号，因为hint的原因，搜索次数可能就是1和28232的区别。

因为端口号限制是针对某个特定的远端server:port的。所以，只要Nginx的Backend有多台机器，甚至同一个机器上的多个不同端口号，只要不超过临界点，Nginx就不会有任何压力。

把端口号范围调大

比较无脑的方案当然是把端口号范围调大，这样就能抗更多的TIME_WAIT。同时将tcp_max_tw_bucket调小，tcp_max_tw_bucket是kernel中最多存在的TIME_WAIT数量，只要port范围 - tcp_max_tw_bucket大于一定的值，那么就始终有port端口可用，这样就可以避免再次到调大临界值得时候继续击穿临界点。

cat /proc/sys/net/ipv4/ip_local_port_range2276861000cat /proc/sys/net/ipv4/tcp_max_tw_buckets20000

开启tcp_tw_reuse

这个问题Linux其实早就有了解决方案，那就是tcp_tw_reuse这个参数。

echo '1' > /proc/sys/net/ipv4/tcp_tw_reuse

事实上TIME_WAIT过多的原因是其回收时间竟然需要1min，这个1min其实是TCP协议中规定的2MSL时间，而Linux中就固定为1min。

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT  * state, about 60 seconds*/

2MSL的原因就是排除网络上还残留的包对新的同样的五元组的Socket产生影响，也就是说在2MSL(1min)之内重用这个五元组会有风险。为了解决这个问题，Linux就采取了一些列措施防止这样的情况，使得在大部分情况下1s之内的TIME_WAIT就可以重用。下面这段代码，就是检测此TIME_WAIT是否重用。

__inet_hash_connect|->__inet_check_establishedstatic int __inet_check_established(......){....../* Check TIME-WAIT sockets first. */sk_nulls_for_each(sk2, node, &head->twchain) {tw = inet_twsk(sk2);// 如果在time_wait中找到一个match的port,就判断是否可重用if (INET_TW_MATCH(sk2, net, hash, acookie,saddr, daddr, ports, dif)) {if (twsk_unique(sk, sk2, twp))goto unique;elsegoto not_unique;}}......}

而其中的核心函数就是twsk_unique，它的判断逻辑如下:

int tcp_twsk_unique(......){......if (tcptw->tw_ts_recent_stamp &&    (twp == NULL || (sysctl_tcp_tw_reuse &&     get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {       // 对write_seq设置为snd_nxt+65536+2       // 这样能够确保在数据传输速率<=80Mbit/s的情况下不会被回绕      tp->write_seq = tcptw->tw_snd_nxt + 65535 + 2......return 1;}return 0;}

上面这段代码逻辑如下所示:

在开启了tcp_timestamp以及tcp_tw_reuse的情况下,在Connect搜索port时只要比之前用这个port的TIME_WAIT状态的Socket记录的最近时间戳>1s,就可以重用此port,即将之前的1分钟缩短到1s。同时为了防止潜在的序列号冲突，直接将write_seq加上在65537,这样，在单Socket传输速率小于80Mbit/s的情况下，不会造成序列号重叠(冲突)。同时这个tw_ts_recent_stamp设置的时机如下图所示:

所以如果Socket进入TIME_WAIT状态后，如果一直有对应的包发过来，那么会影响此TIME_WAIT对应的port是否可用的时间。开启了这个参数之后,由于从1min缩短到1s,那么Nginx单台对单Upstream可承受的TPS就从原来的470.5TPS(28232/60)一跃提升为28232TPS，增长了60倍。如果还嫌性能不够，可以配上上面的端口号范围调大以及tcp_max_tw_bucket调小继续提升tps,不过tcp_max_tw_bucket调小可能会有序列号重叠的风险，毕竟Socket不经过2MSL阶段就被重用了。

不要开启tcp_tw_recycle

开启tcp_tw_recyle这个参数会在NAT环境下造成很大的影响，建议不开启。

Nginx upstream改成长连接

事实上，上面的一系列问题都是由于Nginx对Backend是短连接导致。Nginx从 1.1.4 开始，实现了对后端机器的长连接支持功能。在Upstream中这样配置可以开启长连接的功能:

upstream backend {    server 127.0.0.1:8080;# It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker         process can open. The connections parameter should be set to a number small enough to let upstream servers process new incoming connections as well.    keepalive 32;     keepalive_timeout 30s; # 设置后端连接的最大idle时间为30s}

这样前端和后端都是长连接，大家又可以愉快的玩耍了。

由此产生的风险点

由于对单个远端ip:port耗尽会导致CPU吃满这种现象。所以在Nginx在配置Upstream时候需要格外小心。假设一种情况，PE扩容了一台Nginx,为防止有问题，就先配一台Backend看看情况，这时候如果量比较大的话击穿临界点就会造成大量报错(而应用本身确毫无压力，毕竟临界值是470.5TPS(28232/60))，甚至在同Nginx上的非此域名的请求也会因为CPU被耗尽而得不到响应。多配几台Backend/开启tcp_tw_reuse或许是不错的选择。

总结

应用再强大也还是承载在内核之上，始终逃不出Linux内核的樊笼。所以对于Linux内核本身参数的调优还是非常有意义的。如果读过一些内核源码，无疑对我们排查线上问题有着很大的助力，同时也能指导我们避过一些坑！