必须用sysctl net.core.somaxconn或cat /proc/sys/net/core/somaxconn查运行时值，这才是唯一可信依据；再结合ss -ltn看Send-Q、netstat -s查listen overflows计数，才能确认是否真正生效。
怎么确认某个内核参数修改后是否真正生效
改完 sysctl -w net.core.somaxconn=65535 后，不能只信命令没报错——得验证它是否被内核实际采纳。常见错误是参数名拼错、值超出范围、或该参数根本不可写（比如某些只读参数会静默失败）。
用以下方式交叉验证：
• 直接读 /proc/sys/ 对应路径：cat /proc/sys/net/core/somaxconn，输出必须和你设的值一致
• 再跑一次 sysctl net.core.somaxconn，看等号右边是不是新值
• 如果返回 No such file or directory，说明参数名不存在或路径写错（注意点号变斜杠）
• 若值没变，可能是权限问题：非 root 用户执行 sysctl -w 会失败，且不提示
哪些工具能反映参数修改后的实时性能变化
内核参数本身不输出“性能报告”，它只是开关或阈值。要看到影响，得靠观测下游行为：
• ss -s：查当前 socket 统计，比如改了 net.core.somaxconn 后，观察 listen 队列溢出数（dropped 字段）是否下降
• netstat -s | grep -i "listen.*overflows"：TCP listen overflow 计数，修改前/后对比是否有减少
• dmesg -T | tail -20：看最近有没有 possible SYN flooding 或 nf_conntrack: table full 这类告警，它们直接受 net.ipv4.tcp_syncookies、net.netfilter.nf_conntrack_max 控制
• cat /proc/net/snmp | grep Tcp：关注 TcpExtListenOverflows 和 TcpExtListenDrops 这两个计数器，它们是内核统计的真实 drop 情况
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
为什么不能依赖“修改成功”就认为性能变好了
参数调大 ≠ 性能提升，甚至可能引入新问题：
• net.ipv4.tcp_mem 设太高，会挤占其他内存用途，导致 page cache 不足、IO 变慢
• vm.swappiness=0 在内存吃紧时可能触发 OOM killer，而不是平滑 swap
• net.ipv4.tcp_tw_reuse=1 在 NAT 环境下会导致连接重置（尤其客户端复用端口时）
• 多数网络参数（如 net.core.netdev_max_backlog）只有在真实压测流量打满队列时才显效果，空载下看不出区别
关键点：必须在**相同负载、相同观测窗口**下对比修改前后的指标，否则数值波动会被误读为参数作用
永久生效后如何避免重启才生效的误解
sudo sysctl --system 执行后，参数立即生效，不需要重启。但很多人误以为改了 /etc/sysctl.conf 就自动加载——其实不会。
• 修改配置文件后，必须手动运行 sudo sysctl --system（或 sudo sysctl -p）才加载
• --system 会按顺序加载 /etc/sysctl.conf 和 /etc/sysctl.d/*.conf，后者优先级更高
• 加载失败时，sysctl --system 会报错并停在第一个出错行，比如某行语法错（多空格、缺等号）、参数不存在，后续配置全被跳过
• 验证是否全部加载成功：用 sysctl --show-config 查看哪些参数被显式覆盖，再逐个比对值
/proc/net/snmp 的计数器里、dmesg 的警告中、以及压测时 ss -s 的溢出数字上——没有“一键生成报告”的魔法命令，只有对照改前改后数据的手动比对。 
