The Mirages

小小球周日买的小鸡叫叫就这4天就魂归西天了。

小小球哭的特别伤心，我从来没看到过小小球哭的如此伤心。

叫叫的死我觉得可能跟冷还是有很大关系的，毕竟帝都现在晚上屋里也就20度左右。

https://zhuanlan.zhihu.com/p/90251324

搜索了一下，发现刚出生的小鸡的生活温度是32度左右，然后是每周降低2度，一直到20度左右。而且对湿度也是有要求，帝都就比较干燥了，需要加湿才行。

于是今天晚饭后跟小小球一起把叫叫埋在了小区的花坛里，一开始挖坑的时候小小球还不怎么哭，可等把叫叫放进去之后小小球就开始大声的哭泣了。

连把土盖上也不做了，就在那里哭。我们做好了标记，可小小球还是想在那里多待一会。

回屋的路上也是一边走一边哭。

其实刚买回来那天，我们说叫叫一个人会寂寞的，叫叫还离开了自己的妈妈，它妈妈会想念它的，结果小小球也是在那边哭泣了好久。

这也说明同情心这种东西是小小球与生俱来的。真正热爱的东西你就会自然而然的产生这种感情。这可不是靠说教能感受的。

当年的夹边沟农场是右派们的坟墓，只有那些脑子活跃的人才勉强活了下来，老实巴交的都基本挂了。

现代夹边沟是老年病人的坟墓，抢救之前都会说不好意思，你要做个核酸才能抢救。我也不太懂，都是抢救了还让人等4个多小时的核酸结果，这是真紧急还是假紧急。

于是老实巴交，自认为有风度的就听话等着，结果一命呜呼了。所谓劣币消灭良币就是这个道理。

我想这些人的死亡一定不会统计在官方的死亡数字里的，只要这个不记录，那死再多也不会有人管的。毕竟为官的面子是保住了。本来死因就是基础疾病。

所以在这种非常时刻，大家都要充分的保护自己和自己的家人。

话说sy要给自己家乌龟买抗生素，结果药店说你得做核酸，还好没让乌龟做核酸。

还有大宋为了防止大家被骗，原先atm机取款不能超过xx元，柜台取款不能超过xx元，现在网络转账不能超过1万元，虽说现在说的是可疑账户，可一旦你碰上了，你想找人处理，那100%是找不到的。

就跟我这个健康宝弹窗3，至今12345没有解释，居委也说不清楚。至于后面怎么恢复的，也是无从知道。大宋就是如此的魔幻。

农村人民退休每月103元，每年还要交280元新农合。

大量农民工因为到了60岁无法进入到工地打工，一个工地上打工一个月可以赚8000元。

电子厂已经没有人去了，为什么电子厂那么内卷呢？

而工厂又嫌招不到人，这话的潜台词是招不到原因加班工资少而且听话的工人。而为什么大宋的企业都要这样呢? 主要还是老板本身也不怎么赚钱，不坑你们点怎么才能有利润呢？

而老板本身不赚钱的原因还是因为赛道的原因，现在全球最赚钱的赛道并且产业链长的行业也就剩下航空航天和芯片了。可别人也不会轻而易举的将这些赛道让给你。看看大辽收拾阿尔斯通和庞巴迪就知道了。这2个公司所在国也算是大辽自己人了吧，结果也一样收拾。 后面又收拾了一下台积电是一样的。

因为你想一旦大宋掌握这些了，等于14亿人上了一个台阶，那必然有几亿人是需要下这个台阶的。

总理说全国有6亿人月收入不足1000元，我想大概率是正确的。

一场突如其来的疫情，把魔都这个三好生的皮总算给扒开了。更是展示了魔都底层机构尸位素餐的样子给大家给展示出来了。

什么确诊了之后，居然突然整个小区放开了，什么方舱医院病人哄抢食物。这些只是我们看到的。还有一些是我们看不到的。

本来说好封闭4天，结果10天再加10天，这期间又有多少是人祸导致的无谓的的感染。要说武汉是突然，而且刚好是春节，各种跟不上，可魔都发生的时候已经过去3年了，居然还是这样拉跨。

一个核算检测的统计还是在史前时代的样子，这是库克也是这样搞的话，苹果也不是这样的苹果了。我们所谓的大数据局也不知道在干嘛了。

就说哄抢食物这个，这个大家看到的都是魔都郊区，这只能说明食物严重短缺，而什么陆家嘴街道，外滩街道都没这样的。这还全国要共同富裕呢，连同一个区共同富裕都搞不定啊。

本来以为给大辽一样，各个街道交的税收不一样，导致结果不一样。

可就算是郊区，有人要靠抢食物过活，而同样有人每天都是源源不断的送食物上门，吃不完的只能给邻居了。都这个时候了，大宋还内外有别。这些跟我小时候看的《官场现形记》没有任何区别。

要说帝都其实也一样，一个健康宝提示，就说有问题，即不告诉你因为什么，你也找不到这些有关部门，12345要么坐席忙，要么就帮你内部转达一样，也不会有其它作用，也不会告诉你多久可以处理完。我实在不明白这个弹窗提示的时候同时告知你原因，这个技术上有多难？还是说有很多秘密信息没法告知你？

看来人民的心底都是亮堂的，就算我们广播里天天说大辽各种不行的时候，浦东机场的出国留学队伍依然要排好几公里的。

买来的联想小新amd 2020版本，结果没多久发现了一个问题，就是休眠了之后经常无法正常开机。

当时找了微软支持说是amd的驱动问题，需要更新什么的。可更新了之后过几天依然有问题。

这次因为装了可恶的华宇拼音导致系统里一堆垃圾。然后想安个windows10，结果发现安装到一半居然挂了。

于是在微软官网下载了一个windows11，然后用别人的电脑（家里还有一个32位的windows xp做不了）做了一个启动u盘，一路正常安装居然都好了。

也没有什么序列号认证啥的，直接微软账号就认证通过了。

更好的是这次用了2周一次休眠死机都没有发生过。

千万不能用那个联想自己的恢复镜像，那个是把整个盘都会抹掉的，我好不容易分的D盘就没用了。

这次MU事故后，跟球球一起回顾了很多事故。什么飞机撞南极火山，法航掉海这些事故， 以及当年的723动车事故。

这些所有事故都有详细的分析。比如 723： https://baike.baidu.com/item/7%C2%B723%E7%94%AC%E6%B8%A9%E7%BA%BF%E7%89%B9%E5%88%AB%E9%87%8D%E5%A4%A7%E9%93%81%E8%B7%AF%E4%BA%A4%E9%80%9A%E4%BA%8B%E6%95%85/10805173

723事故里最不该被处理的其实是后面的发言人。当然这是个人观点。

这些事故我们时候分析都会发现其实有很多次机会都是可以避免的，经常都是几件事情叠加导致的。按照海恩法则的说法：在机械生产过程中，每发生330起意外事件，有300件未产生人员伤害，29件造成人员轻伤，1件导致重伤或死亡。

反着说就是每一起重大事故后面都会有29件轻微事故，有300个意外事件。

把这个法则挪用到互联网公司上就是说每一次线上重大事故背后都有29个轻微事故和300个问题导致的。

按这个来看，贵司这1个月10个事故，这得后面多少多少问题啊。可惜提了那么多的问题，一直供着呢。

早上看到有2个nginx服务器在6点多的时候带宽跑到100M多，整个磁盘io也都非常高。

因为现在都是vpc的服务器，内网公网都是在一个网卡上，随意一时也判断不出来到底是内网还是公网导致的。

查看对应的slb是否有异常。查看这个机器前面所有的slb发现流量都正常。

因为nginx的带宽是出口方向是100M的，那就是从本机往外传输，于是就看下nginx请求是否有异常，发现也都很正常。

查看整个集群的服务器的带宽是否有问题。发现整个集群里这个时间点只有这2个nginx的出，但是没有哪个服务器是进的。

因为这个机器对外服务端口只有web server，但是我们nginx又没有日志显示有那么多的流量。那基本可以确认是本机主动发起的对外请求。

查看本机的crontab和at是否有对应时间的。发现还是没有。

然后继续排查这个机器的登录日志，发现一个内网其他服务器的登录信息。

查看这个远程服务器的crontab是否有对应时间的。果然最后就是它了。原来它不是往其他服务器上传的，我说怎么没有找到对应流向的。

我们都知道http1.1是支持keepalive，这样就可以减少建连的次数，可以提高性能。

于是简单在单机上做了一个测试。

我们先使用一个没有keepalive的配置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

upstream test_server {
        server 127.0.0.1:8999;
        server 127.0.0.1:8997;
        keepalive 32;
}

server {
    listen 8998;
      server_name _;
    access_log /opt/server/nginx/log/8998-access.log main;
    error_log /opt/server/nginx/log/8998-error.log;

      location / {
        proxy_pass http://test_server;
#        proxy_http_version 1.1;
#        proxy_set_header Connection "";
      }
}



server {
    listen 8999;
      server_name _;
    access_log /opt/server/nginx/log/8999-access.log main;
    error_log /opt/server/nginx/log/8999-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}
server {
    listen 8997;
      server_name _;
    access_log /opt/server/nginx/log/8997-access.log main;
    error_log /opt/server/nginx/log/8997-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}

测试结果如下：

1
2
3
4
5
6
7
8
9

$ wrk -t1 -c32 -d60s http://127.0.0.1:8998/
Running 1m test @ http://127.0.0.1:8998/
  1 threads and 32 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.61ms    2.14ms  76.87ms   99.52%
    Req/Sec    21.31k     2.22k   26.73k    69.00%
  1272221 requests in 1.00m, 260.85MB read
Requests/sec:  21202.84
Transfer/sec:      4.35MB

我们再打开keepalive的设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

upstream test_server {
        server 127.0.0.1:8999;
        server 127.0.0.1:8997;
        keepalive 32;
}

server {
    listen 8998;
      server_name _;
    access_log /opt/server/nginx/log/8998-access.log main;
    error_log /opt/server/nginx/log/8998-error.log;

      location / {
        proxy_pass http://test_server;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
      }
}



server {
    listen 8999;
      server_name _;
    access_log /opt/server/nginx/log/8999-access.log main;
    error_log /opt/server/nginx/log/8999-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}
server {
    listen 8997;
      server_name _;
    access_log /opt/server/nginx/log/8997-access.log main;
    error_log /opt/server/nginx/log/8997-error.log;

      location / {
        return 200 '{"status":"OK","entities":[]}';
      }
}

这次测试结果如下：

1
2
3
4
5
6
7
8
9

$ wrk -t1 -c32 -d60s http://127.0.0.1:8998/
Running 1m test @ http://127.0.0.1:8998/
  1 threads and 32 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   817.00us    3.10ms 107.27ms   99.47%
    Req/Sec    49.73k     6.16k   74.11k    75.50%
  2968158 requests in 1.00m, 608.58MB read
Requests/sec:  49468.57
Transfer/sec:     10.14MB

这周真算是波澜壮阔的一周。
周一周二的全面下跌，大有崩溃之势。而到了周三周四又是全面收复失地。

可实际上中概互联这些算最高点开始都已经打一折了，好多都是0.5折，0.1折了。就算现在一天涨50%，那也就是从0.1折变成0.2折，从0.5折涨到一折。

但是周一周二真的是底部吗？有过08年和15年的股民肯定知道这只是前菜。只有你哪天看到狂拉银行股的时候，那才算是最悲观的时候。但是市场的最低往往还要往后继续延后。

就算是2015年千股跌停，但是市场一直到2018年底才是最最低的那个底。因为这些都是有惯性的。

2000年纳斯达克一泻千里，但是最低的那个底一直到2002年才出现。

其实最快的是08年的崩溃，我从其他资料也看到了，在2006年有人就已经开始做空了，2007年大部分泡沫也都已经破裂了，只是雷曼本身作为一个标志性事件，然后就是几万亿的资金进入。

因此跟年初说的一样，这次最快到2023年都是底，躺平就行了。

nginx connection limit模块是用来限制整体的连接数。这个贵司是用来限制单个nginx最大连接数。一旦超过了就限制重新连接，默认就返回503了。

这个阿里云slb也是这样的策略。

但是我们碰到了一点问题。突然有一台服务器reload之后，发现很多503返回了。可查了一下当时该机器的连接数，并没有超过我们设置的限定数。但其他服务器的却没有问题。

配置如下：

1
2
3

#整个整体连接数限制：
  limit_conn_zone all zone=allserver:10m;
  limit_conn allserver 50000;

而且每次reload之后我们会清理的对应shutting down的进程。 后来只能通过restart nginx来处理。于是我们就进行了测试。

这里使用了wrk来进行测试，主要是ab无法保证连接。

1
2
3
4
5

git clone https://github.com/wg/wrk.git wrk
cd wrk
make
sudo cp wrk /usr/bin/
wrk -t1 -c6 -d300s http://127.0.0.1:8998/

为了验证效果，我们把连接数设置为5.

1
2
3

#整个整体连接数限制：
  limit_conn_zone all zone=allserver:10m;
  limit_conn allserver 5;