满纸空言

QC35改装Type-C口----伟大的人类们

Thu, 11 Dec 2025 09:51:54 +0800

QC35II质量非常好,尤其比自家的挂脖的QC30好太多了,用了很多年也没坏,但是充电口太旧了,每次都得准备带一根线,最近查了一下,发现各地区的大神都有各自的方案,汇总了一下,并选用了方案二进行升级.

方案一:

开源PCB板项目:jamesturton/bose-qc35-usb-c: A hardware mod to use USB-C on the Bose QC 35

优点: 孔位和功能完整

缺点: 需要定制PCB板,或者从闲鱼买50一个

外网定制产品美元结算巨贵

方案二:

用 QC45 的充电板替换到 QC35

Bose QC35 II USB C 改裝 : r/bose

优点: 原厂适配(闲鱼90)

缺点: 螺丝孔位偏移, 针对蓝牙漏电问题,可能需要毁掉一个电阻

介于定制的PCB板质量未知,最终选择的第二个方案

1.加长typec母口,拆下来固定到电烙铁上,前后用钳子夹紧即可

2.电烙铁设置为350度

3.用塑料练一下手,熟悉一下

4.耳机很容易拆,耳包从一侧拽起来,里面三颗螺丝卸了金属外壳就能那下来

5.拆卸充电小板,两颗螺丝,边上的排线用镊子夹出来

6.对比一下孔位和typec的高度

7.用电烙铁烫出typec口,里面的凹槽放不进去typec母头,也需要处理一下,可以烫,也可以用壁纸刀剪断扩一下

8. 安装的时候孔位对不上,不用管,直接用螺丝拧进去就可以,原来固定排序的位置,我打了热熔胶固定一下

针对蓝牙漏电问题(充电灯一直亮),需要毁掉一个电阻,我是用镊子夹碎的

9.充电效果

10.用细砂纸修一下

Type-C快充头和USB充电头都可以充,充电和播放试了两天,一切正常

孰能生巧,上面黑色用了两个小时,银色只用了1个小时就完成了

ERROR: ‘/usr/sbin/iptables-restore -w -n‘ failed: iptables-restore v1.8.2 (nf_tables)

Fri, 17 Oct 2025 11:36:04 +0800

最近配置了防火墙端口，用firewall-cmd --reload操作无效

始终报如下的错误

ERROR: '/usr/sbin/iptables-restore -w -n' failed: iptables-restore v1.8.2 (nf_tables): line 4: RULE_REPLACE failed (No such file or directory): rule in chain INPUT line 4: RULE_REPLACE failed (No such file or directory): rule in chain OUTPUTpowershell123

解决方法

vim /etc/firewalld/firewalld.conf

找到

IndividualCalls=no#把no改为yes

按esc，输入:wq保存退出

然后重启firewalld服务

systemctl restart firewalld.servicepowershell1

重启之后即可正常执行firewall-cmd --reload

转自:ERROR: ‘/usr/sbin/iptables-restore -w -n‘ failed: iptables-restore v1.8.2 (nf_tables)_docker iptables-restore -w -n failed: iptables-res-CSDN博客

WSL下openEuler的一些配置

Fri, 10 Oct 2025 11:04:58 +0800

wsl --install
wsl --update --web-download
//将 WSL 2 设置为默认版本
wsl --set-default-version 2

wsl --shutdown

//禁用wsl
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux

查看已安装的linux系统

wslconfig /list

设置默认登陆用户

openEuler24.03.exe config --default-user root

windows安装marchaesen/vcxsrv

vim /root/.bashrc

添加:(ip是wsl能访问的windows的ip)

export DISPLAY=172.30.144.1:0.0
export LIBGL_ALWAYS_INDIRECT=1

开启最大/小化按钮

wsl访问linux下的goland效果:

修风冷冰箱的结冰问题

Wed, 14 May 2025 14:24:17 +0800

一个月后追评：一点冰都没有，应该是彻底解决了

-------------------------以下原文-------------

一周后的评论：暂时没有发现有冰，应该不会漏水了，冰箱是容声3开门

-------------------------以下原文-------------

网上常见的都是推荐1.5mm实心铜线，连接加热管到下水口可以解决冷冻室结冰问题，但考虑到铜线表面结冰形成的热阻以及缺乏有效的低温传热介质，会使其解冻效率受到一定限制。经过对比，最优解是铜管中放入汽车防冻液 ，防冻液具有较高的沸点和较低的冰点，能在较宽的温度范围内保持液态。其比热容比盐水大，吸收相同热量时温度升高幅度相对较小，可储存更多的热量。而且防冻液的导热系数比盐水略高，能更有效地将热量从加热管传递到周围环境，从而提高解冻效率。

以下是对 1.8mm 外径、壁厚 0.5mm 的铜管（内放防冻液）与 1.8mm 实心铜线在给定条件下解冻效率的对比分析：

铜管（内放防冻液）

热量传输方式：铜管本身具有良好的导热性，虽然是空心结构，但能将加热管的热量快速传递到与防冻液接触的内壁。防冻液由于比热容较大，能吸收较多热量且温度升高相对缓慢，可在低温下储存大量热能，并通过对流和传导将热量均匀地传递到铜管的各个部位，进而传递到周围的结冰区域。
低温适应性：在零下 20℃的环境中，防冻液能保持液态，不会因结冰而影响导热。而且，其冰点低于环境温度，可有效防止铜管内形成冰堵，保证热量传递的连续性。

实心铜线

热量传输方式：实心铜线的导热性能优异，凭借其较大的横截面积和纯铜材质，能迅速将加热管的热量传导至自身各处。然而，在热量向周围结冰区域传递时，主要依靠铜线表面与冰的直接接触传导，缺乏像铜管内防冻液那样的中间介质来辅助热量的均匀分布和传递。
低温影响：在零下 20℃的环境中，铜线表面容易结霜或结冰，形成的冰层会增加热阻，阻碍热量从铜线向周围冰区的传递。随着时间的推移，表面冰层逐渐增厚，会导致热量传递效率进一步降低。

对比总结

热量传递效率：铜管内的防冻液可在吸收热量后通过对流和传导在管内形成较为均匀的温度场，使得铜管整体能更高效地向周围散发热量。而实心铜线虽然初始导热快，但因表面结冰形成热阻，热量传递到结冰区域的效率会逐渐下降。因此，铜管（内放防冻液）在热量传递效率上更具优势。
解冻效果：由于铜管（内放防冻液）能够更有效地将热量传递到周围的结冰区域，且能保持热量传递的稳定性，所以在相同的时间内，铜管周围的冰融化速度会更快，解冻效果更好。而实心铜线因表面冰层的阻碍，解冻速度相对较慢。

综上所述，在给定的条件下，1.8mm 外径、壁厚 0.5mm 的铜管（用针管打入防冻液）的解冻效率要高于 1.8mm 实心铜线。

根据ntp时间差-2秒

Thu, 20 Mar 2025 18:34:33 +0800

#!/bin/bash

# 检查是否提供了NTP服务器地址
if [ $# -eq 0 ]; then
    echo "请提供NTP服务器地址"
    echo "使用方法: $0 <ntp_server>"
    exit 1
fi

ntp_server="$1"
# 获取小数点后6位，与ntp差值相同
old_time=$(date +%s%3N)

# 获取NTP时间
ntp_time=$(ntpdate -q $ntp_server |grep ntpdate |awk '{printf "%.3f", $10}')
ntp_time=${ntp_time//./}
ts=$(($old_time-2000+$ntp_time))
new_time="${ts:0:-3}.${ts: -3}"

justed_time=$(date -d "@$new_time" "+%Y-%m-%d %H:%M:%S")
echo 修改前时间: $(date "+%Y-%m-%d %H:%M:%S")
date -s "$justed_time" >/dev/null
echo "与ntp时间差: $(ntpdate -q $ntp_server |grep "ntpdate" |awk '{print $10}')"
hwclock --localtime --systohc
echo "修改后时间: $justed_time"

lvs下压测丢包优化

Wed, 19 Mar 2025 18:18:11 +0800

转自：LVS怪异网络延迟现象与GRO/LRO

LVS怪异网络延迟现象与GRO/LRO

怀疑：lvs怪异的网络延迟现象(GRO/LRO引起的)，文件上传失败(较大的request内容时，WebServer端长时间收不到请求)

ethtool -k eth0

Features for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off #GRO
large-receive-offload: off   #LRO
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off

# 设置开启gro，如果报错就说明网卡驱动本身就不支持GRO。
ethtool -K gro on

关于GRO

linux kernel 网络协议栈之GRO(Generic receive offload): https://blog.csdn.net/lucien_cc/article/details/11731463

GRO(Generic receive offload)在内核2.6.29之后合并进去的，作者是一个华裔Herbert Xu ,GRO的简介可以看这里：

http://lwn.net/Articles/358910/

先来描述一下GRO的作用，GRO是针对网络接受包的处理的，并且只是针对NAPI类型的驱动，因此如果要支持GRO，不仅要内核支持，而且驱动也必须调用相应的借口，用ethtool -K gro on来设置，如果报错就说明网卡驱动本身就不支持GRO。

GRO类似tso，可是tso只支持发送数据包，这样你tcp层大的段会在网卡被切包，然后再传递给对端，而如果没有gro，则小的段会被一个个送到协议栈，有了gro之后，就会在接收端做一个反向的操作(想对于tso).也就是将tso切好的数据包组合成大包再传递给协议栈。

网络数据包分析网卡Offload

网卡的offload概念:https://www.cnblogs.com/victor-ma/p/5363786.html

对于网络安全来说，网络传输数据包的捕获和分析是个基础工作，绿盟科技研究员在日常工作中，经常会捕获到一些大小远大于MTU值的数据包，经过分析这些大包的特性，发现和网卡的offload特性有关，本文对网卡Offload技术做简要描述。

MTU

最大传输单元，指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位）。

在以太网通信中，MTU规定了经过网络层封装的数据包的最大长度。例如，若某个接口的MTU值为1500，则通过此接口传送的IP数据包的最大长度为1500字节。

小编注：对于普通用户来说，如果你优化过迅雷的下载速度，可能通过这篇文章《合理设置MTU，提升下载速度》，对MTU的基础知识有所了解。

IP分片

当IP层需要传送的数据包长度超过MTU值时，则IP层需要对该数据包进行分片，使每一片的长度小于或等于MTU值。在分片过程中，除了对payload进行分片外，数据包的IP首部也需要进行相应的更改：

将identifier字段的值复制给每个分片；
将分片数据包的Flags中的DF位置为0；
除最后一个分片之外的其他分片，将MF位置为1；
将Fragment Offset字段设置正确的值。

MSS

最大分段长度，TCP数据包每次能够传输的最大数据分段长度，在TCP协议的实际实现中，MSS往往用MTU-(IP Header Length + TCP Header Length)来代替。

在TCP通信建立连接时，取两端提供的MSS的最小值作为会话的MSS值。

由于TCP分段有MSS值的限制，通常情况下TCP数据包经IP层封装后的长度不会大于MTU，因此一般情况下，TCP数据包不会进行IP分片。

网卡offload机制

早先TCP设计的目标是为了解决低速网络传输的不可靠性问题（拨号上网的年代），但随着互联网骨干传输速度的提升（光纤、千兆以太、万兆以太）以及用户端更可靠的访问机制的出现（ADSL等），相关的数据中心及客户端桌面环境上的TCP软件常常需要面临大量的计算需求。

当网络速度超过1Gb的时候，这些计算会耗费大量的CPU时间，有数据表明，即便使用千兆全双工网卡，TCP通信也将消耗CPU的80%的使用率（以2.4GHz奔腾4处理器为例），这样留给其他应用程序的时间就很少了，表现出来就是用户可能感觉到很慢。

小编注：当年的蠕虫病毒对CPU的影响与此近似。

为了解决性能问题，就产生了TOE技术（TCP offload engine），将TCP连接过程中的相关计算工作转移到专用硬件上（比如网卡），从而释放CPU资源。从2012年开始，这项技术开始在普通用户的网卡上应用。

随着技术的日趋成熟，目前越来越多的网卡设备开始支持offload特性，以便提升网络收发和处理的性能。本文所描述的offload特性，主要是指将原本在协议栈中进行的IP分片、TCP分段、重组、checksum校验等操作，转移到网卡硬件中进行，降低系统CPU的消耗，提高处理性能。

发送模式

**TSO （tcp-segmentation-offload） **

从名字来看很直观，就是把tcp分段的过程转移到网卡中进行。当网卡支持TSO机制时，可以直接把不超过滑动窗口大小的payload下传给协议栈，即使数据长度大于MSS，也不会在TCP层进行分段，同样也不会进行IP分片，而是直接传送给网卡驱动，由网卡驱动进行tcp分段操作，并执行checksum 计算和包头、帧头的生成工作。例如：

当TSO模式关闭时，在本地主机上（10.8.55.1）发送一个超长的HTTP请求，当TSO模式关闭时，10.8.55.1抓包，可以看到超过MSS的包被拆分为多个包。

当TSO模式开启时，10.8.55.1抓包，则为一个包。

**UFO（udp-fragmentation-offload） **

是一种专门针对udp协议的特性，主要机制就是将IP分片的过程转移到网卡中进行，用户层可以发送任意大小的udp数据包（udp数据包总长度最大不超过64k），而不需要协议栈进行任何分片操作。目前貌似没找到有支持UFO机制的网卡，主要是应用在虚拟化设备上。

**GSO（generic-segmentation-offload） **

相对于TSO和UFO，GSO机制是针对所有协议设计的，更为通用。同时，与TSO、UFO不同的是，GSO主要依靠软件的方式实现，对于网卡硬件没有过多的要求。其基本思想就是把数据分片的操作尽可能的向底层推迟直到数据发送给网卡驱动之前，并先检查网卡是否支持TSO或UFO机制，如果支持就直接把数据发送给网卡，否则的话再进行分片后发送给网卡，以此来保证最少次数的协议栈处理，提高数据传输和处理的效率。 }}}

接收模式

**LRO（large-receive-offload） **

在网卡驱动层面上将接受到的多个TCP数据包聚合成一个大的数据包，然后上传给协议栈处理。这样可以减少协议栈处理的开销，提高系统接收TCP数据的能力和效率。

**GRO generic-receive-offload **

基本思想和LRO类似，只是改善了LRO的一些缺点，比LRO更加通用。目前及后续的网卡都采用GRO机制，不再使用LRO机制。

**RSS（Receive Side Scaling） **

具备多个RSS队列的网卡，可以将不同的网络流分成不同的队列，再将这些队列分配到多个CPU核心上进行处理，从而将负荷分散，充分利用多核处理器的能力，提交数据接收的能力和效率。

[转]2.6.29-2.6.39之间的kernel不要在LVS Director的网卡开启GRO

(2014-04-29 10:35:49)

原文地址：
- http://www.sbear.cn/archives/599
- http://blog.sina.com.cn/s/blog_6c2e6f1f0101kwlk.html

我还没有遇到，并且在服务器上看默认也是关闭的，暂且记录下来

ethtool -k eth0

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off

uname -a
Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux

在 LVS 下，POST 请求总是 socket timeout ，而直接 POST 到 real server 没有问题。

Linux 在 2.6.29 的时候，引入了一个 GRO (Generic receive offload) 。

MTU 一般都是 1500 字节，如果一个包超过了 MTU ，就会被分片。

1500 这个数字，估计是基于当时的网络环境制定的，而现在，10Gbps 的网卡都普遍使用了，可能就不太适用了。如果 10Gbps 的网卡满载地来跑，一个完整的数据包会被分片 800w 片。

我们可以通过调整 client 和 server 端的 MTU 令到分片尽可能减少，提高吞吐量。但是，如果 client 端（例如用户）不受我们控制呢，那我们就无法提高性能了。于是有人想到通过网卡的行为来间接实现相当于提高 MTU 的作用，这就是 GRO [1] 。

GRO 就是在网卡中将满足一定的条件（比较严格）的包，将分片的包组装合并了，才一次性交给上面的协议栈。现在的网卡一般都支持了，除了网卡支持，还要驱动也支持才可以。如果网卡和驱动都支持，那么在 2.6.29 以后的 kernel，都会默认开启。

ethtool -k eth0查看是否有 generic-receive-offload: on，如果是 off ，也不一定是不支持，可以通过ethtool -K eth0 gro on来尝试开启。

但是 GRO 和 LVS 协作得并不好，具体表现就是，POST 数据到 LVS 很慢。

抓包看我的 POST 请求，握手阶段用了较长时间，出现了数次 incorrect 后才真正开始传输。
POST 小于 MTU 的数据，并不会触发这个问题，而 POST 大于 MTU 的数据，就会。证明了这里肯定是 GRO 惹的祸。

没有 google 到最根本的原因，但也有一些说法 [2] ，就是 GRO 和 LVS 之间的兼容没有做好，直到 2.6.39 已经修复了这个问题。

LVS、Nginx压测与性能调优:https://www.jianshu.com/p/853d3b160f92

现在大多数网卡都具有LRO/GRO功能，即 网卡收包时将同一流的小包合并成大包 （tcpdump抓包可以看到>MTU 1500bytes的数据包）交给内核协议栈；
LVS内核模块在处理>MTU的数据包时，会丢弃；
因此，如果我们用LVS来传输大文件，很容易出现丢包，传输速度慢；
解决方法，关闭LRO/GRO功能，命令：（注意查看命令是小k，修改命令是大K）
ethtool -k eth0 查看LRO/GRO当前是否打开
ethtool -K eth0 lro off 关闭GRO
ethtool -K eth0 gro off 关闭GRO

经验主义一点，就是 LVS 的 director 一律关闭网卡的GRO。

ethtool -k eth0 gro off

这个情况我遇到的，一般发生在内网 POST 的时候，而用户 POST 给我的情况太慢的不太多，也有可能是他们网络根本就慢，手机的网络环境变数太多，而我暂时也没有办法把他们过滤出来一一查看。我猜想，是因为内网的网络环境正好符合了 GRO 的 merge 的条件，GRO 起作用了，所以我的 POST 很慢。而用户的请求不符合条件，所以还是比较正常的。

Reference:
- http://lwn.net/Articles/358910/
- http://archive.linuxvirtualserver.org/html/lvs-users/2011-05/msg00004.html

LVS、Nginx压测与性能调优

LVS、Nginx压测与性能调优:https://www.jianshu.com/p/853d3b160f92

可能的性能因素

硬件方面

CPU、内存、网卡。

其中最主要的是CPU和网卡，短连接业务场景下cpu软中断(si)可能成为性能瓶颈；网卡的最大流量值也可能限制负载均衡器性能的发挥，如常见的千兆网卡，理论最大数据传输速率为1000Mb/s，即125MB/S。LVS对于内存消耗并不多，Nginx相对会消耗内存一些，不过内存一般不会成为瓶颈。

系统方面

Linux系统默认有许多限制，对于在业务流量较大的情况下发挥负载均衡器的性能有很大影响。常见的如：服务端可接受的最大连接数、可接受的最大半连接数、本地可用端口范围、time-wait连接数、可打开的最大文件句柄数、网卡等待队列大小等。

软件方面

LVS的hash table值，Nginx的nginx.conf调优等。

网络方面

负载均衡器和真实服务器都是通过网络进行通信，如果条件允许，最好将它们置于同机房、同网段下，减小网络时延带来的影响。

系统参数调优

网卡多队列与CPU核绑定

网卡多队列是一种硬件技术，即一个物理网卡可以有多个队列通道，需要多队列网卡驱动支持。默认情况下各个队列的请求都是由cpu0核处理，所以很容易因为cpu0核si(软中断)满造成性能瓶颈，用top可以看到软中断(si)集中在单个核上。

多队列网卡在系统中有多个中断号，通过CPU核绑定，将各个中断号对应的网卡队列绑定到指定的CPU核处理，这样可以发挥多核CPU的优势，将中断请求分摊到多个cpu核上，提升cpu处理性能。

配置方法：

# 检查系统是否已开启irqbanlance服务，如果有，则关闭该服务，手动进行cpu核绑定。
ps -ef | grep irqbalance

# 检查网卡是否支持多队列
# 检查是否存在 MSI-X: Enable+ Count>0，如果存在，说明网卡支持多队列。
lspci -vvv | grep -A 30 "Ethernet controller"

# 查询网卡各队列对应的中断号
# 可以看到对应网卡有多个队列，分别对应中断号187~194。
cat /proc/interrupts | grep eth0

# 将各队列绑定到指定的CPU核
# PS: 这里传入的值为16进制。转换为2进制后对应绑定的cpu核。
# 如：echo 80 >  cat /proc/irq/194/smp_affinity
# 16进制80转换为2进制为1000 0000，表示将中断号194绑定到cpu7核上面。
echo 1 > /proc/irq/187/smp_affinity
echo 2 > /proc/irq/188/smp_affinity
echo 4 > /proc/irq/189/smp_affinity
echo 8 > /proc/irq/190/smp_affinity
echo 10 > /proc/irq/191/smp_affinity
echo 20 > /proc/irq/192/smp_affinity
echo 40 > /proc/irq/193/smp_affinity
echo 80 > /proc/irq/194/smp_affinity

做了网卡多队列与CPU核绑定后，两次查看CPU软中断状态，中断处理分摊到了cpu0~7核，处理能力得到提升。

关注系统链接跟踪表大小

系统链接跟踪表记录了经过系统转发的连接信息，通过加载nf_conntrack模块启用，对于iptables、SNAT/DNAT等功能是必须启用链接跟踪表的。

但是如果链接跟踪表的值设置的太小，容易造成链接跟踪表满导致丢包的问题。所以需要关注系统的链接跟踪表最大值和当前值的大小，当二者相等时，说明表满，系统会drop新的连接请求。

ps: 链接跟踪表设置大一些虽然不会造成丢包，但是在业务量很大的情况下，如果表过大（上百万的级别），系统查询链接跟踪表会消耗大量的cpu资源，可能会导致系统挂死。

#查询系统链接跟踪表最大值、当前值
#如果链接跟踪表最大值为65536就太小了，很容易造成丢包。
sysctl -a | grep -E 'nf_conntrack_max|nf_conntrack_count'

net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_count = 0
net.nf_conntrack_max = 65536

关闭网卡LRO、GRO特性

现在大多数网卡都具有LRO/GRO功能，即网卡收包时将同一流的小包合并成大包（tcpdump抓包可以看到>MTU 1500bytes的数据包）交给内核协议栈；

LVS内核模块在处理>MTU的数据包时，会丢弃；

因此，如果我们用LVS来传输大文件，很容易出现丢包，传输速度慢；

解决方法，关闭LRO/GRO功能，命令：（注意查看命令是小k，修改命令是大K）

# 查看LRO/GRO当前是否打开
ethtool -k eth0|grep offload

tcp-segmentation-offload: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on        #GRO
large-receive-offload: off [fixed] #LRO
rx-vlan-offload: on [fixed]
tx-vlan-offload: on [fixed]

# 关闭LRO/GRO
ethtool -K eth0 lro off
ethtool -K eth0 gro off

增大网卡的ring buffer值

# 查看TX/RX
ethtool -g eth0

Ring parameters for eth0:
Pre-set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     256
RX Mini:    0
RX Jumbo:   0
TX:     256

# 修改、查看
ethtool -G eth0 rx 4096
ethtool -G eth0 tx 4096
ethtool -g eth0

内核参数

# 增大网卡等待队列大小
# netdev_max_backlog参数表示每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。当网卡流量很大时，可以调大这个参数值。
sysctl -w net.core.netdev_max_backlog=262144

# 增大服务端全连接队列大小
# somaxconn参数表示服务端已完成3次握手连接的队列大小，即单个服务可建立的tcp连接最大值。当需要增大服务端处理并发连接的能力时，需要调大该参数值。
sysctl -w net.core.somaxconn=262144

# 增大服务端半连接队列大小
# tcp_max_syn_backlog参数表示服务端接收syn消息队列的大小。如果该队列未满，则响应(syn,ack)消息；否则将丢弃客户端的syn包。
sysctl -w net.ipv4.tcp_max_syn_backlog=262144

# 增大系统可用的本地端口范围
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 增大系统time_wait状态连接数限制
# tcp_max_tw_buckets表示系统允许存在的time_wait状态连接数。Time wait状态是tcp断连中一个正常的状态，它存在的作用主要包括：
# 确保tcp连接可靠的断开和旧连接的报文在网络中彻底消失。
# 如果这个值过小，则客户端不会进入time_wait状态，而是直接从FIN_WAIT状态结束。这时候服务端最后一次挥手的FIN消息会以收到RST结束，可能会导致服务端断连异常。
sysctl -w net.ipv4.tcp_max_tw_buckets=262144

# 启用time_wait状态连接复用
# 增大tcp_max_tw_buckets值有一个负面影响，就是系统time_wait状态连接过多，将可用端口耗尽，导致没有足够的可用端口新建连接。
# 这时候可以启用time_wait状态连接复用。注意需要同时启用时间戳tcp_timestamps。（注意开启tcp_timestamps后要确认关闭tcp_tw_recycle）
sysctl -w net.ipv4.tcp_timestamps=1
sysctl -w net.ipv4.tcp_tw_reuse=1

# 增大系统最大文件句柄数
# fs.file-max表示系统整体允许打开的最大文件句柄数。这个值一般只需关注一下，如果配置过小，可以增大。
sysctl -a | grep fs.file-max

# 增大系统进程最大文件句柄数
# ulimit -n查询的结果表示单个进程允许打开的最大文件句柄数，可用ulimit -n xxx调大该参数值。
ulimit -n
ulimit -n xxx

# 注意这只是在当前shell下生效的，系统重启后会丢失，
# 需要同时修改/etc/security/limits.conf中的nofile值。其中，* 这行的配置表示对非root用户生效。
    *  soft nofile 1024000
    *  hard nofile 1024000
    root soft nofile 1024000
    root hard nofile 1024000

增大ipvs模块hash table的大小

ipvs模块hash table默认值为2^{12=4096，改为2}20=1048576。

可以用ipvsadm -l命令查询当前hash table的大小:

IP Virtual Server version 1.2.1 (size:4096)

修改方法：在/etc/modprobe.d/目录下添加文件ip_vs.conf，内容如下，并重新加载ipvs模块。

options ip_vs conn_tab_bits=20

Nginx参数调优

Nginx的参数配置都在nginx.conf文件中。

#配置worker进程数等于系统cpu核数，并配置cpu核绑定。
#这里比较方便的是配置为auto，但是根据实际的系统情况指定worker进程数和手动绑定cpu核可能性能会更高一些，比如避开中断irq处理的cpu核，将worker进程绑定到其它空闲的cpu核上。
worker_processes auto;
worker_cpu_affinity auto;

#使用epoll模型
use epoll;

#关闭TCP的Nagle算法:Nagle算法规定了一个TCP连接中最多只能存在一个未被确认的小包，这可能会和系统的延迟ACK机制产生冲突，造成较为严重的时延。
tcp_nodelay on;

#增大单个worker进程的文件句柄数限制
worker_rlimit_nofile 1024000;

#增大单个worker进程的最大并发连接数限制
#这里的最大并发连接包括前后端的连接，且该参数值不能大于worker_rlimit_nofile。
worker_connections 1024000;

硬件与网络配置调优

对物理网卡做多网卡绑定

采用mode 0或mode 4对多块物理网卡做绑定，提升网卡整体的传输速率。如将两块传输速率为1000MB/S的网卡做mode0绑定，则理论上bond网卡的传输速率为2000MB/S。

将负载均衡器和真实服务器放在一个局域网内

负载均衡器和真实服务器靠网络传输数据，如果条件允许，将它们放在一个局域网内，避免数据传输走路由器传输。

性能分析工具

# 分析cpu性能
# sar和mastat需要安装sysstat工具包。
top       #按1可以看到每个cpu核的cpu使用情况，同时还能看到各个进程的情况。
sar -u 1  #每隔1秒打印出当前cpu的整体使用情况。
mpstat -P ALL 1 #每隔1秒打印出所有cpu核的使用情况。

# 分析网卡流量
# 每隔1秒打印出所有网卡的流量传输情况。
sar -n DEV 1

# 查看网卡配置,注意这里的单位是小b。
ethtool xxx

# 查看bond网卡绑定模式
cat /proc/net/bonding/xxx

性能压测工具

这里介绍一个很好用的http压测工具：wrk。

安装方法

git clone https://github.com/wg/wrk

make

ln -s xxx/wrk /usr/sbin/wrk

使用方法

使用方法: wrk <选项> <被测HTTP服务的URL>

Options:

-c, --connections  跟服务器建立并保持的TCP连接数量 
-d, --duration     压测时间         
-t, --threads      使用多少个线程进行压测 
-s, --script       指定Lua脚本路径     
-H, --header       为每一个HTTP请求添加HTTP头     
--latency          在压测结束后，打印延迟统计信息 
--timeout          超时时间   
-v, --version      打印正在使用的wrk的详细版本信息

代表数字参数，支持国际单位 (1k, 1M, 1G)
代表时间参数，支持时间单位 (2s, 2m, 2h)

示例

wrk默认为http长连接。

使用10个线程、1000个长连接对指定URL压测60s，并打印时延信息。

wrk -t10 -c1000 -d60s --latency "http://xxx/test.html"

Requests/sec: 149863.60  # 每秒的请求数，即QPS
Transfer/sec: 67.02MB    # 每秒传输的字节数

指定头域实现http短连接测试。

wrk -t10 -c1000 -d60s -H "Connection: Close" --latency “http://xxx/test.html”

注意压测客户端也会遇到性能问题，也需要对其进行性能调优。

拾光坞配置windows的docker

Fri, 28 Feb 2025 17:11:20 +0800

创建的时候配置路径，此步必须配置，折腾了好久

映射8006端口

真慢。。。不好用，还是用ubuntu吧

科幻一角(转)

Thu, 16 Jan 2025 10:04:35 +0800

转自：cent

　　理论太枯燥了，以下是我平时的一些科幻构思,全是与人工生命有关的，因本人文笔太差，只能给出个草草的框架，我的基本想法是希望有文笔好的网友们能将它们补充成文，发到哪里都没关系，但我希望最好发在我的论坛里，然后我把作者和文章直接贴在这个栏目里，(注:前三个构思曾发表在96年第二期的科幻世界上)。也欢迎大家把自已的科幻构思发给我或贴在论坛里，然后我开个“网友构思”贴出来。

☆绑架
当生命可能以信息方式传递，队长带人在地底打算拦截敌方将领的中微子波，以实现绑架其之目的，但接收器坏了，最后队长决定用自已的大脑来接收这个信息，于是，当信号被拦截后，队长就变成了敌人的将领......
(自评：这算是生命复制的一个插曲吧，“我”为什么不是“你”？，区别只是脑细胞的排列方式不一样而已。)

☆左和右
左和右是某个蓝球队里的主力，他们两人的配合天衣无缝，只有有他们同时上场，球队就战无不胜。一个偶然的机会，人们发现了他们的秘密：原来他们本来就是一个人。
(自评：生命存在的形式可以多种多样，如果一脑多体也满有趣的。)

☆我的爸爸
在不远的将来，机器智能延生后，人类被限制生育，只能领养机器人小孩作为自已的子女，担负着教育这些小孩的任务。“我”就是这样的一个机器人小孩。有一天，“我”的爸爸带着“我”去幼儿游乐园玩，结果爸爸的大脑无法适应专为机器人小孩设计的游戏，死于“意外的事故”中。从此，所有幼儿游乐园门口都立了一个标志：所有带子女来的家长们请注意，不得进入园内，以免发生意外”......
(自评：很多人下意识的观点是机器人不可能越过人，我写这个构思就是想强调这种观点与可能出现的将来的反差。)

☆一亿亿个声音
他是工厂流水线上的一个普通工人，作为旧式的机器人，受到许多限制，生活极其枯燥：每天准时上下班，定期领到属于自已的润滑油，更烦人的是，周围的人太多了，拥挤不堪，甚至在公园里都排着队。（原因：因为按照生命保护组织公约，所有生命都有生存权，最后机器人越造越多，地球就越来越挤。）他讨厌这个拥挤的世界，于是，他开始策划一个大胆的行动：离开这个星球，离开乏味的生产线......经过千辛万苦，付出了巨大的代价之后，他终于乘着飞船来到了一个遥远的全新的星球，这个星球的表而一无所有，除了沙漠还是沙漠，“终于可以安静地一个人生活了。”——他很满意这个地方。突然，他脚下的沙粒发出了一亿亿个声音，原来，这里的每一个沙粒都是一个机器生命。
(自评：是个笑话，笑笑而已)

☆等待花开
<上篇>一个空旷的山谷里，一个人坐在那里，等待一朵花开，他已经等了三十天了,──只因为他喜欢，因为他有足够的时间。
<下篇>花开了，他欣赏。就在这时，天突然变黑了。他意识里的最后一个念头是：“我被淘汰了”。
(自评：这篇文章按我的文笔是绝对写不出来的，我只能把握它的意境。上篇是纯散文风格，写得越优美、越闲散越好，等待花开虽然没什么大的意义，但全命即已永生，时间也就无限。一切琐碎的小事都有足够的时间和心情将它做得完美。下篇纯属狗尾续貂，只是考虑到太单调的文章也许没人会看而续作。下篇的背景是这样的，两百年前，地球上发生了一场战争，“正义”的一方为了“所有生命都有生的权力”而建立了一个生命保护组织，敌对方的口号是“弱肉强食，适者生存”。战争以“正义”一方获胜为终，败者被逐出银河系。从此，地球上所有生命开始亨有“永生”。两百年后，永生的人们被卷土重来的敌方消灭。主题：生命永远在进化。)

☆绿袖子
一场残酷的战争正在进行。他发现了前方的目标：一颗间谍卫星。他开始加速，准备将它摧毁。就在这时，他听到了那熟悉的旋律，从那哼唱的节奏中，他分辨出那是自已的妹妹！（补充：战争爆发后，人作为无需教育的廉价知识库，大脑中的信息被复制到各种武器中，成为武器的控制系统的一部分。）他毅然决定毁灭自已......第二天，某国发表一则内部新闻：一枚UF3970型导弹在巡航时发生不明原因的爆炸，据悉与收到的一段神密电波有关。
（自评：生命一旦成为武器的一部分，不知道会不会有感情？实在可悲)

☆少了点什么
自从参加了那次旅行之后，他总觉有什么地方不对，但又不知是什么。他在最近总是做一些自己意想不到的事，或是有时自己和自已聊上几个小时！更要紧的事，他总觉得少了点什么，少了一样重要的东西......经过一翻追寻之后，他才发现了真相：一年前，他和妻子参加了一个流行的“愉快旅行”，这种旅行是通过将他们（注：他们是机器人）的脑信息发送到另一个星球，再在那边将他们复制出来的方式进行。只是轮到他们时出了一点意外，他和妻子的脑信息被复制到了一个脑中而竟然没人发现，而且，为了保证唯一性，他们的原件已被销毁，这就是他为什么觉得有些不太对的原因：少掉的是他的妻子!
（自评：如何保持智能体的唯一性？有没有必要销毁原件？理论上来说，当两个同样智能体延生的那一刻，他们已经是两个人了，因为他们的脑细胞排列方式将会由于接触到不同的环境而改变。可是如果两个生命体相似度达到99.9%，会不会其中一个自杀也无所谓呢？机器智能对生死的看法也许与人不同。)

☆没有副作用
某人发明了一种没有副作用且便宜的"毒品"，从此，每个人都不再努力工作，除了挣到足够生存的钱，他们所有的作为就是吸毒，社会因此陷入瘫痪。
（自评：太简单的内容，而且现实中也不可能有这种毒品，但对于机器智能来说却是可能的，一定区域内的神经元兴奋将引起愉悦的感觉，生物就是因为有愉悦和痛苦的感觉而生存进化，但将来是否会人为地制造这种兴奋并将之作为生命的唯一追求？）

☆蝴蝶
小蝶是个蝴蝶一样的女孩，她喜欢蝴蝶。有一天，男友给她带来一个新的蝴蝶，她很开心。一个偶然的机会，她发现这是只有古代才有的蝴蝶，她去问男友，男友很无奈，带她去看一台机器，这是一个时间机器，可以回到从前去抓蝴蝶......其实，小蝶早已在车祸中死去，现在的她只是生活在虚拟世界的模拟人。她自已却不知道。男友不小心造了个古代的蝴蝶给她，为了圆谎，只她再造一个时间机器出来，否则现实中那来的时间机器！
（自评：一个关于时间机器的想法，现在看来有点过时了，可是96年我最想写的就是这篇。）

☆复仇
现实中他卑微而穷困，可是在虚拟的社会中，他有钱有地位受人尊重，当虚拟中的他被人“杀”了之后，他十分痛苦，为了复仇，他找到了那个杀他的人，犯下了一桩实实在在的罪行。
(自评：只想说明一个道理，在精神领域，虚幻和现实实际上没有区别，就算是虚幻的，也是有物质支持的，纯粹的虚幻是不存在的。）

☆混沌
<上篇>午后的校园洒满了阳光，他向窗外望去，一切都是那么熟悉，又那么陌生......“有间工厂出了点问题，你去处理一下。”他来到了这间工厂，这是一个全自动工厂，从接订单、生产、直到出货全过程都是由电脑控制。所有有订单都是计算机从网上接收，但最近几周来，工厂发生一件奇怪的事，生产线上经常无故生产出一些零件。通常工厂里开玩笑将没有订单就生产出来的产品叫接到了上帝的订单，但这一次却有点超乎寻常，这些零件是如此多，如此复杂，而且没有人认得是用在什么上的。他开车返回时要了这样一个零件。快到家所在的城市时，城市上空爆炸了一颗核弹。天空中到处飞着奇怪的飞行物。他明白了，这些飞行物就是那些工厂里造出来的。
<下篇>核爆炸之后，地球被核灰笼罩，残存的人们也将逐渐死去。他们慢慢知道了原因，一些研究人工智能的业余爱好者将通过将许多强大的计算机联网的方式来试验人工智能，但他们没有想到，从他们成功的那一刻起，计算机就开始了保护自已的行动。它控制了自动工厂生产出大量的飞行器，这里一种可以飞行的武器。并引爆了世界上大多数的核弹。幸存下来的他和其它科学家一起，认为只有造出一个更强大的并行的机器智能才有可能拯救人类，这是唯一的希望。时间一天天进去，进度却很慢。终于，飞行器们逼近了研究室，绝望的他自杀了。他认输了，人类终于输给机器。奇迹发生在他死后，由于他的血将上亿个电子神经元短路，使原先有规律排列的神经元陷入混沌，极短时间内，“雨人”（这个人工神经网络的名称)在信息库教育机器下有了意识。很快一切逆转，飞行器们被消灭，人类被保护，他的脑信息也被复原到一个虚拟世界中——这就是开头他回想到的内容。
(自评：也许清晰的算法对模式识别之类有用，对于造人却力不从心，不是什么都能用公式来描述的。最后重申研究造人的目的：“研究怎么造人，并不是为了造人而造人，而是未雨绸缪，防止技术的进展超出人类控制它的能力”，至于文中有两种不同类型的机器智能，纯属一相情愿的猜测。）

linux抗掉电方案

Mon, 16 Dec 2024 18:15:10 +0800

经验证以下方法治标不治本,并且在鲲鹏cpu下会导致系统异常

正确做法: Raid卡加装电容(电池) 或主板加装电容(电池)(鲲鹏服务器自带主板电容) 物理解决

-----------------------以下原文----------------------

异常断电导致的系统损坏：

通过修改/etc/fstab文件来设置只读挂载。

将原本的挂载选项（如defaults）修改为ro（read - only）

像这样的条目：/dev/sda1 /boot ext4 ro 0 0。这样设置后，系统启动后，

正常情况下就不会有写操作到 boot 分区，在一定程度上可以避免因意外断电导致的写入中断而损坏 boot 分区。

对于 XFS 文件系统

挂载选项优化：在/etc/fstab中，为 XFS 分区添加logbufs=8（假设系统内存足够）这样的参数。例如，/dev/sda2 /data XFS logbufs=8 0 0。logbufs参数用于设置文件系统日志缓冲区的数量，增加缓冲区数量可以在一定程度上缓冲掉电时的日志写入操作，提高文件系统的抗掉电能力。

vim /etc/fstab
UUID=8a1817ec-bfce-491c-9897-1ecee761d9f2  /boot xfs ro,noatime,nodiratime,logbufs=8 0 0

分析参数组合的合理性
- ro（只读）参数：
  - 将/boot分区挂载为只读模式可以在一定程度上防止意外的写入操作，减少因意外断电导致文件系统损坏的风险。对于/boot分区，这个设置在某些情况下是合理的，因为在系统正常运行期间，/boot分区主要用于引导系统，通常不需要频繁写入。
- loop参数：
  - 在这里使用loop参数是不太合适的。loop参数主要用于将文件当作块设备进行挂载，通常用于挂载磁盘镜像文件等特殊情况。在挂载正常的/boot分区（基于 XFS 文件系统）时，不应该使用这个参数，它可能会导致挂载错误或异常行为。
- noatime,nodiratime参数：
  - 这些参数是有益的。noatime会避免在读取文件时更新文件的访问时间，nodiratime会避免在读取目录时更新目录的访问时间。这两个参数可以减少磁盘的写入操作，对于/boot分区来说，可以进一步降低因写入操作而在掉电时损坏文件系统的风险。
- nobarrier参数：
  - 使用nobarrier参数需要谨慎。虽然它可以提高写入性能，因为它禁用了确保数据写入完整性的屏障机制，但这同时也增加了数据丢失的风险。对于/boot分区，如果数据完整性非常重要（毕竟它关乎系统的引导），可能不太适合使用这个参数，除非有其他可靠的数据保护措施，如 UPS（不间断电源）等。
- logbufs=8参数：
  - 设置logbufs=8对于 XFS 文件系统的/boot分区来说，可以增加日志缓冲区的数量，有助于在掉电等意外情况发生时保存更多的日志信息，从而提高文件系统的恢复能力，这是一个有助于提高抗掉电性能的参数。
建议的配置修改
- 可以考虑去掉loop参数，并且谨慎考虑nobarrier参数是否真的适合/boot分区。修改后的/etc/fstab条目可能如下：
  - UUID=8a1817ec-bfce-491c-9897-1ecee761d9f2 /boot xfs ro,noatime,nodiratime,logbufs=8 0 0
- 这样的配置在保证/boot分区主要以只读方式挂载（减少意外写入）的同时，利用noatime、nodiratime和logbufs=8参数来优化性能和提高抗掉电能力。不过，在修改/etc/fstab后，需要仔细测试系统的引导过程和/boot分区相关功能是否正常，因为错误的/etc/fstab配置可能会导致系统无法正常启动。

模拟断电破坏的Linux文件系统

Fri, 13 Dec 2024 15:39:43 +0800

破坏Linux文件系统

最直接的方法是破坏文件系统的元数据，使得文件系统在下次尝试挂载时无法正确读取。你可以使用 debugfs 或者 xfs_db（对于 XFS 文件系统）等工具来修改文件系统的超级块或其他关键结构。然而，这种方法非常激进，通常只用于测试目的。

方法一：

使用 `debugfs`（适用于 ext2/ext3/ext4 文件系统）

sudo debugfs -w /dev/sdXn
debugfs:  clri <inode_number>
debugfs:  quit

这将清除指定的 inode，可以是一个重要的系统文件，如 /etc/passwd 的 inode，从而导致系统无法正常启动。

使用 `xfs_db`（适用于 XFS 文件系统）

sudo xfs_db -x /dev/sdXn
xfs_db> sb
xfs_db> w
xfs_db> q

直接执行会报xfs_db: /dev/sda2 contains a mounted filesystem

先umount /boot 卸载分区再执行

这将打开 XFS 文件系统的超级块编辑器，允许你手动修改超级块内容。请不要随意更改任何值，除非你知道你在做什么。

方法二：

此方法最快，但修复难度大

lsblk -f 查看boot分区是sda几

dd if=/dev/zero of=/dev/sda2 bs=1k count=10