FastEDA

Rhel Centos 7/8性能优化脚本

Wed, 15 Apr 2026 14:26:46 +0800

以下两个脚本用于对RHEL CENTOS 7/8系列 Linux 服务器进行全栈性能调优，可显著提升 CPU、内存、磁盘 I/O 及网络吞吐效率。针对 EDA 计算服务器（芯片设计仿真场景），脚本的价值尤为突出：通过设置 performance CPU 调度器、优化 I/O 调度、降低内存延迟及合理配置 THP，能有效缩短仿真任务的编译与运行时间，提升大规模并行计算的资源利用率。脚本执行前会自动备份原配置，建议在测试环境验证后再部署到生产EDA集群。

RHEL 8 优化脚本 (rhel8_optimize.sh)

模块	优化项	参数/配置	效果说明
内存管理	降低 Swap 倾向	vm.swappiness = 10	减少磁盘交换，优先使用物理内存
	脏页写回控制	vm.dirty_ratio = 40 vm.dirty_background_ratio = 10	提升写入吞吐，减少 IO 抖动
	内存压缩 (zswap)	启用 zswap，压缩器 lz4	减少内存换页，提升内存效率
	watermark 缩放	vm.watermark_scale_factor = 200	提前唤醒 kswapd，减少直接内存回收
网络栈	TCP 缓冲区扩大	net.core.rmem_max = 16MB net.ipv4.tcp_rmem = 4096 87380 16MB	提升大流量网络吞吐能力
	BBR 拥塞控制	net.ipv4.tcp_congestion_control = bbr net.core.default_qdisc = fq	高延迟/丢包环境下显著提升吞吐
	TCP Fast Open	net.ipv4.tcp_fastopen = 3	减少 TCP 握手延迟
	TIME_WAIT 复用	net.ipv4.tcp_tw_reuse = 1	加速端口回收
I/O 调度	调度器设置	SSD/NVMe: none HDD: mq-deadline	SSD 最低开销，HDD 降低寻道延迟
	预读缓冲	SSD: 256KB HDD: 2048KB	优化顺序读写性能
	udev 持久化	创建 60-io-scheduler.rules	重启后 I/O 调度器配置自动生效
THP	透明大页	madvise	减少内存碎片，提升大内存访问效率
	systemd 持久化	创建 disable-thp.service	重启后 THP 配置自动生效
CPU/调度	CPU 调度器	performance governor	固定最高频率，降低任务调度延迟
	进程调度迁移成本	kernel.sched_migration_cost_ns = 5000000	减少 CPU 间进程迁移
文件系统	最大文件描述符	fs.file-max = 2097152	支持大量并发文件打开
	inotify 限制	fs.inotify.max_user_watches = 524288	支持大量目录/文件监控
系统服务	禁用不必要服务	postfix, cups, bluetooth, rpcbind, cockpit 等	释放系统资源，减少后台干扰
tuned	自定义性能配置	custom-performance profile	统一管理 CPU/磁盘/网络调优参数
引导参数	内核启动选项	idle=poll intel_idle.max_cstate=0 transparent_hugepage=madvise	降低 CPU 唤醒延迟，减少电源状态切换
加密策略	Crypto 策略提示	可切换 DEFAULT:SHA1	降低 TLS 握手开销（可选）

下载地址：

rhel8_optimize.zip

RHEL 7 优化脚本 (rhel7_optimize.sh)

模块	优化项	参数/配置	效果说明
内存管理	降低 Swap 倾向	vm.swappiness = 10	减少磁盘交换，优先使用物理内存
	脏页写回控制	vm.dirty_ratio = 40 vm.dirty_background_ratio = 10	提升写入吞吐，减少 IO 抖动
	内存过量分配	vm.overcommit_memory = 1	提高内存密集型应用的内存分配成功率
网络栈	TCP 缓冲区扩大	net.core.rmem_max = 16MB net.ipv4.tcp_rmem = 4096 87380 16MB	提升大流量网络吞吐能力
	TIME_WAIT 复用	net.ipv4.tcp_tw_reuse = 1	加速端口回收，提升连接建立效率
	TCP Fast Open	net.ipv4.tcp_fastopen = 3	减少 TCP 握手延迟
I/O 调度	调度器设置	SSD: deadline HDD: deadline	降低磁盘延迟，提升响应速度
	预读缓冲	SSD: 256KB HDD: 2048KB	优化顺序读写性能
THP	透明大页	madvise	减少内存碎片，提升大内存访问效率
CPU/调度	CPU 调度器	performance governor	固定最高频率，降低任务调度延迟
	进程调度迁移成本	kernel.sched_migration_cost_ns = 5000000	减少 CPU 间进程迁移，提升缓存命中
文件系统	最大文件描述符	fs.file-max = 2097152	支持大量并发文件打开
	inotify 限制	fs.inotify.max_user_watches = 524288	支持大量目录/文件监控
系统服务	禁用不必要服务	postfix, cups, bluetooth, abrt 等	释放系统资源，减少后台干扰
引导参数	内核启动选项	idle=poll intel_idle.max_cstate=0 transparent_hugepage=madvise	降低 CPU 唤醒延迟，减少电源状态切换

下载地址：

rhel7_optimize.zip

说明：在拥塞控制方面，如果是纯局域网，可以不做调整，尤其是针对与8系列的BBR

工具跑完job后退出报error：malloc_consolidate(): unaligned fastbin chunk detected

Tue, 24 Mar 2026 18:24:13 +0800

工具跑完job后退出报如下error： malloc_consolidate(): unaligned fastbin chunk detected *** Got signal 6 (Aborted). Cleaning up... 卡在这里不动了。。。 A服务器：dell服务器，rocky linux 8.10，软件版本和环境一致。报这个error B服务器：联想服务器，rocky linux 8.10，软件版本和环境一致。未报这个error 唯一的区别在于服务器品牌不同。哪位大佬知道什么原因？

关于Xlink停止维护与FTU时代开启的通知

Wed, 18 Mar 2026 09:47:09 +0800

自Xlink发布以来，我们经历了4年的时间，从Xlink 1.0到Xlink 4.0，我们经历了发布、改版、优化、创新等各项工作。

一、Xlink基于vnc+容器实现了远程桌面的自动化管理功能，但是由于vnc协议的问题，在性能上始终有些解不开的答案，同时由于EDA行业的特殊性，vnc跳转无法有效的支持LSF的bsub -Ip功能。只能使用XF来提交job。

在Xlink上，我们做了大量的工作，但是后续的开发已经无法有效解决实际问题，因此我们决定放弃vnc方案，改用其他开源组件作为后续开发的依据，在后续开发的基础上，我们将基于vnc的xlink命名为ftu/v1协议版本。

但是Xlink依旧作为半开源项目继续开放使用，且提供持续的技术支持，只是不再更新版本，针对BUG和补丁需要用户自行负责。

****** FTU为 Fasteda Turbo Unit的简称(EDA 连接高速连接单元)。

二、在Xlink开发和改版优化的同时，我们开发了ftu 2.0版本，这个版本是基于xpra实现的。我们称之为ftu/v2协议。

Ftu2.0版本经过开发、优化、测试后，我们同样发现了一些难以解决的问题，例如无法有效的将xpra进行打包分发，无法有效的进行二次编译开发。虽然在连接能力上已经实现了，但是经过深思熟虑，我们还是决定不做2.0的版本发布。同时基于2.0版本开发自有协议的快速连接工具。

三、Ftu3.0基于自有协议 ftu/v3进行开发。我们制作了客户端模块(launcher和ftu-client)、App(ftu_app)、及服务端模块(ftu-agent和ftu-server)五大模块

模块介绍

组件	文件	运行位置	职责
App (管理端)	ftu_app	管理服务器	用户认证、会话管理、Web UI、WS代理
ftu-agent	ftu-agent	每台节点服务器	节点注册、启动/停止 ftu-server、CONNECT隧道
ftu-server	ftu-server	节点服务器（由agent启动）	桌面采集、FTU/3协议服务端、Web桌面(HTTPS)
ftu-client	ftu-client	用户客户端（由launcher启动）	FTU/3协议客户端、渲染远程桌面
launcher	launcher.py	用户客户端	解析链接、建立隧道、启动ftu-client

在安全机制上，我们采用了分组加密、多重密钥和握手的方式

安全性介绍

函数/方法	签名	说明
FTU/3 握手加密		X25519 ECDH + HKDF-SHA256 → AES-256-GCM；每帧独立随机 IV；零明文密码传输
PSK 扩展		REMOTEX_SECRET 设置时，DH shared secret 与 PSK 混合再 HKDF；未持有 PSK 的客户端 GCM tag 验证失败
隧道 URL 加密		路径和 auth 参数均 AES-128-CBC 加密；密钥从变量获取
ConnectionToken		一次性 token（validity=300s），validate_web_token 每次验证后刷新过期时间
TLS（Web 模式）		ftu-server 生成自签名 RSA-2048 证书；ws_proxy 以 CERT_NONE 方式连接（内网场景）

客户端兼容性

平台	兼容	描述
Windows	兼容	以开发windows版本的客户端，支持非管理员的msi与exe，与支持管理员模式(Alluser)的msi与exe
Linux	兼容	当前适配RHEL8与UBUNTU
Macos	未兼容	暂时未开放客户端
信创(ARM)	半兼容	只具备显示和操作功能
信创(龙芯)	未兼容	暂时未开放客户端

三种连接模式

direct 模式

launcher → agent (CONNECT) → ftu-server:tcp_port

📌 适合 launcher 与 agent 在同一内网，无需经过 app 中转。

redirect 模式

launcher → app (CONNECT hop1) → agent (CONNECT hop2) → ftu-server:tcp_port

📌 适合 launcher 只能访问 app，agent 与 app 在同一内网。

web 模式

浏览器 ws://app/web/<sid>/<token>

→ ws_proxy 验证 token → CONNECT 到 agent→ TLS wrap → WS 握手到 ftu-server:web_port

📌 无需安装客户端，任意支持 WebSocket 的现代浏览器可用。

在暴露外网或者VPN的情况下，我们支持以APP为跳板，只需要开放APP独立端口的情况下就支持所有用户接入，不在需要针对node节点暴露单独的端口。

四、关于版本发布

Ftu协议虽然已经到了ftu/v3,但是ftu软件将以初始版本1.0.0作为发布信息，因此请注意：用户手册及软件版本标注不同，但是适用性没有问题。

所以：各位，敬请期待！！！

FTU预览页面：https://www.fasteda.cn/ftu.html

解决Kerberos用户因内核密钥配额不足无法登录问题

Wed, 21 Jan 2026 09:08:16 +0800

问题概述

在使用RPM(Redhat,Centos,Rocky)系统时，Kerberos用户可能会遇到登录失败的问题，错误信息显示为"Disk quota exceeded"。这个错误源于内核密钥环的配额限制，当用户的Kerberos票据尝试存储在内核密钥环时，由于配额不足而导致认证失败。

错误现象

登录过程中，系统日志（通常是/var/log/sssd/krb5_child.log）会记录以下关键错误：

[map_krb5_error](0x0020):1853: [122][Disk quota exceeded]
[create_ccache](0x0020):1025: [122][Disk quota exceeded]

当然，如果使用systemctl命令也可以看到类似错误:

systemctl status sssd

根本原因分析

Linux内核密钥环服务用于在内核中缓存加密密钥、身份验证令牌和跨域用户映射等信息。每个用户的密钥使用受到两个内核参数的限制：

kernel.keys.maxkeys：用户可以拥有的最大密钥数量
kernel.keys.maxbytes：用户密钥可以消耗的最大字节数

当Kerberos客户端（krb5_child）尝试为用户创建凭证缓存时，如果当前用户的密钥使用已达到上述任一限制，就会触发"Disk quota exceeded"错误。

诊断步骤

1. 检查用户密钥使用情况

$ grep $(id -u $USER_NAME) /proc/key-users

输出示例：

1002:    13 13/13 13/200 3997/4000

各字段含义：

第一列：UID
倒数第二列：当前用户拥有的密钥数/最大允许密钥数（kernel.keys.maxkeys）
最后一列：当前用户密钥消耗的字节数/最大允许字节数（kernel.keys.maxbytes）

2. 查看系统所有用户的密钥使用排名

$ sort -k 5 -rn /proc/key-users

输出示例：

   0:   466 465/465 171/1000000 6789/25000000
1002:    13 13/13 13/200 3997/4000
1001:    15 15/15 15/200 2000/4000
...

从输出可以看出，UID 1002用户的字节使用量已接近上限（3997/4000），需要增加配额。

解决方案

解决方案1：增加内核密钥配额

1.1 临时增加kernel.keys.maxkeys

将用户可以拥有的最大密钥数增加到400：

# sysctl -w kernel.keys.maxkeys=400

1.2 永久增加kernel.keys.maxkeys

编辑/etc/sysctl.conf文件，添加或修改以下行：

kernel.keys.maxkeys = 400

然后重新加载配置：

# sysctl -p

1.3 临时增加kernel.keys.maxbytes

将用户密钥可以消耗的最大字节数增加到20000：

# sysctl -w kernel.keys.maxbytes=20000

1.4 永久增加kernel.keys.maxbytes

编辑/etc/sysctl.conf文件，添加或修改以下行：

kernel.keys.maxbytes = 20000

然后重新加载配置：

# sysctl -p

解决方案2：更改Kerberos凭证缓存类型

对于RHEL 8及更高版本，建议使用KCM（Kerberos Cache Manager）作为凭证缓存后端。

作为替代方案，可以使用FILE类型的缓存。编辑/etc/krb5.conf文件，将：

default_ccache_name = KEYRING:persistent:%{uid}

替换为：

default_ccache_name = FILE:/tmp/krb5cc_%{uid}

清理现有票据（可选）

如果需要清理当前用户的现有Kerberos票据：

$ kdestroy -A

解决方案3：配置SSSD KCM

步骤1：安装SSSD KCM组件

# 安装sssd-kcm软件包
dnf install sssd-kcm
或者
yum install sssd-kcm

如果系统中已安装该软件包，系统会提示已安装最新版本。

步骤2：配置Kerberos使用KCM缓存

编辑或创建KCM配置文件：

# vim /etc/krb5.conf.d/kcm_default_ccache

确保文件内容包含以下配置：

# 启用KCM凭证缓存需要启用KCM socket和服务：
#   systemctl enable sssd-kcm.socket sssd-secrets.socket
#   systemctl start sssd-kcm.socket   
## 要禁用KCM凭证缓存，请注释以下行。
[libdefaults]
    default_ccache_name = KCM:

关键配置说明：

default_ccache_name = KCM: 指定使用KCM作为默认的凭证缓存后端
冒号(:)是必须的，表示使用默认的KCM缓存

步骤3：检查主Kerberos配置文件

确保/etc/krb5.conf文件开头包含以下includedir指令：

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

检查方法：

# 查看/etc/krb5.conf文件开头部分head -10 /etc/krb5.conf
# 如果缺少includedir行，可以添加
vim /etc/krb5.conf

注意：这些includedir行应放在[libdefaults]部分之前，以确保正确加载配置文件。

步骤4：启用并启动KCM服务

# 启用KCM socket（开机自启动）
systemctl enable sssd-kcm.socket
# 启动KCM socket
systemctl start sssd-kcm.socket
# 检查服务状态
systemctl status sssd-kcm.socket

步骤5：重启SSSD服务

# 重启SSSD服务以应用更改
systemctl restart sssd
# 检查SSSD服务状态
systemctl status sssd

最佳实践建议

监控密钥使用：定期检查/proc/key-users，了解系统中各用户的密钥使用情况
合理设置配额：根据实际使用需求调整配额，避免设置过大影响系统安全
使用KCM缓存：在RHEL 8+系统中优先考虑使用KCM作为缓存后端
日志监控：定期检查/var/log/sssd/krb5_child.log日志文件，及时发现配额问题

总结

Kerberos用户因内核密钥配额不足无法登录的问题通常可以通过增加配额或更改缓存类型来解决。系统管理员应根据实际情况选择合适的解决方案，并建立适当的监控机制，确保系统的稳定运行和用户的正常访问。

Fasteda-Flexnet-Log-Analysis,Flex日志分析工具

Mon, 05 Jan 2026 12:46:25 +0800

FlexNet License 使用统计工具适用说明

工具概述

本工具是一款专门用于分析FlexNet License服务器日志的桌面应用程序。通过解析日志文件，可以统计用户对许可证的使用情况，包括使用时长、Session数量、按天统计等信息，帮助管理员了解许可证使用状况，优化许可证资源分配。

主要功能

1. 多文件支持（新版）

支持同时选择多个日志文件进行分析
自动合并多个文件中的数据
显示各文件的分析统计信息

2. 用户分析

单个用户分析：分析指定用户的使用情况
所有用户分析：批量分析所有用户的使用情况
用户自动扫描：自动从日志文件中提取所有用户列表

3. 统计分析维度

总体统计：总使用时长、Session数、使用许可证数量等
许可证统计：按许可证统计使用时长和Session数
按天统计：每日使用情况统计
详细记录：显示每个Session的详细时间信息

4. 时间范围筛选

支持自定义日期范围筛选
提供快速选择按钮：

今天
本周
本月
上月

支持清空日期范围（分析所有数据）

5. 数据导出

可将分析结果导出为文本文件
包含所有统计维度的完整报告

安装与运行

系统要求

操作系统：Linux（需安装Python环境），Redhat 7.X以上操作系统
Python版本：Python 3.6+
内存：建议至少2GB RAM
磁盘空间：至少50MB可用空间

使用步骤

步骤1：选择日志文件

点击"添加文件"按钮
选择要分析的FlexNet License日志文件（可多选）
支持.log文件和所有其他文本格式文件
点击"清空列表"可重新选择文件

步骤2：扫描用户

点击"扫描用户"按钮
程序会自动从选择的日志文件中提取所有用户
用户列表将显示在下拉框中

步骤3：设置分析参数

选择用户：从下拉列表中选择要分析的用户
设置日期范围：

手动输入格式：YYYY-MM-DD
或使用快速选择按钮

设置最小时长：过滤过短的Session（单位：秒）
设置输出文件：可选，用于保存分析报告

步骤4：开始分析

单个用户分析：点击"开始分析"按钮
批量用户分析：点击"分析所有用户"按钮
分析过程中可点击"停止分析"按钮中断

步骤5：查看结果

分析完成后，结果将显示在右侧面板中：

总体统计：基础统计信息
许可证统计：按许可证的详细使用情况
按天统计：每日使用情况
详细记录：每个Session的详细信息

步骤6：导出报告

点击"导出报告"按钮
选择保存位置和文件名
报告将保存为文本文件

日志文件格式要求

支持的日志格式

本工具支持FlexNet License服务器的标准日志格式，主要识别以下行类型：

1.TIMESTAMP行：确定日期

11:18:58 (xxxxx) TIMESTAMP 11/5/2024

2.OUT行：许可证检出记录

11:19:03 (hspice) OUT: "hspice" user1@hostname

3.IN行：许可证归还记录

12:30:15 (hspice) IN: "hspice" user1@hostname

文件位置

FlexNet License日志通常位于：

ps -ef|grep lmgrd  ，查看 -l 部分位置

可以同时分析多个日志文件，如按日期分割的日志文件

技术说明

数据处理逻辑

Session配对：程序会自动匹配OUT和IN记录，形成一个完整的Session
时长计算：计算每个Session的持续时间
过滤机制：可过滤掉时长小于设定阈值的Session
跨文件合并：当选择多个文件时，程序会自动合并所有数据

性能注意事项

大文件处理：对于超过100MB的日志文件，分析可能需要较长时间
内存使用：分析过程中会缓存所有Session数据，大文件分析时内存使用较高
进度提示：分析过程中有进度条显示当前状态

常见问题解答

Q1: 为什么分析结果显示无数据？

A: 可能原因：

选择的用户在当前日志时间段内没有使用记录
日期范围设置不正确
最小时长设置过高，过滤了所有Session
日志文件格式不兼容

Q2: 如何分析多个月的日志数据？

A: 有两种方式：

将各月的日志文件全部选择，程序会自动合并分析
清空日期范围设置，分析所有数据

Q3: 为什么有些Session没有匹配上？

A: 可能原因：

日志文件不完整，缺少OUT或IN记录
Session跨越多天，但日志被分割为多个文件
时间格式解析错误

Q4: 分析所有用户很慢怎么办？

A: 建议：

设置合适的日期范围，减少分析数据量
先分析单个用户确认日志文件有效
对于非常大的日志文件，考虑按时间段分割

Q5: 导出的报告文件在哪里？

A: 报告文件保存在您指定的位置，默认情况下与程序在同一目录下。

高级功能

1. 自定义时间范围

支持精确到天的范围筛选
可分析任意时间段的数据

2. Session过滤

可设置最小时长过滤无意义的短暂使用
默认过滤60秒以下的Session

3. 跨文件Session跟踪

支持跨多个日志文件的Session配对
保持未结束Session的状态跟踪

4. 批量分析

一次性分析所有用户的使用情况
生成用户使用排名统计

注意事项

日志文件编码：建议使用UTF-8编码的日志文件
时间一致性：确保日志中的时间格式正确
文件权限：确保程序有权限读取日志文件
数据安全：本工具不修改原始日志文件，只进行读取分析
资源占用：分析大型日志文件时，建议关闭其他大型应用程序

技术支持

如有问题或建议，请联系：

工具名称：FlexNet License 使用统计工具
开发者：Fasteda.cn
版本：1.0.0.0
更新日期：2026年1月5日

免责声明：本工具仅用于辅助分析，分析结果仅供参考。对于因使用本工具而产生的任何直接或间接损失，开发者不承担任何责任。建议在重要决策前，手动验证关键数据。

支持如下功能：

1、载入日志

2、自动分析涉及用户

3、按日期分析，自动选择日期，手动输入日期

4、按用户分析

5、按所有用户分析

6、按用户分析可导出分析结果

可统计内容如下：

1、分析所有用户，可统计各用户的总使用时长和session总数：

2、分析单个用户，可统计信息如下：

当前程序暂时不开源，预计半年后开源，如果有问题，请随时留言。

当前工具只支持Linux版本。程序在Rhel7.9上进行编译。如果您无法使用，请告知操作系统版本信息。

下载地址1.0.0.0：

Fasteda-Flexnet-Log-Analysis-rhel7.zip

2026年1月6日更新：1.1.0.0版本。更新内容：

优化算法

增加多日志载入支持

下载地址1.1.0.0：

Fasteda-Flexnet-Log-Analysis-multi.zip

技术支持

如有问题或建议，请联系：

工具名称：FlexNet License 使用统计工具
开发者：Fasteda.cn
版本：1.1.0.0
更新日期：2026年1月6日

禁用系统的核心转储（core dump）功能

Mon, 05 Jan 2026 08:46:53 +0800

Coredump核心转储是在程序崩溃时生成的内存镜像文件，用于调试，但在生产环境中通常会禁用以避免磁盘空间占用和安全风险。

下面的方法，可以完全禁止掉Coredump功能

1. bash ulimit软硬限制core为0

ulimit -c 0        # 当前shell会话中禁用core dump
ulimit -S -c 0     # 仅设置软限制
ulimit -H -c 0     # 设置硬限制（需要root权限）

作用：对当前shell及后续进程禁用核心转储。
永久生效：需要将 ulimit -c 0 添加到 ~/.bashrc 或 /etc/profile 中。

2. csh limit软硬限制core为0

limit coredumpsize 0

注意：一定是CSH模式下才有limit命令

作用：在C shell中禁用核心转储。
永久生效：添加到 ~/.cshrc 或 /etc/csh.cshrc。

3. systemctl disable abrtd --now

systemctl disable abrtd --now

作用：

abrtd（Automatic Bug Reporting Tool）是收集崩溃报告的服务。
disable 禁止开机自启，--now 立即停止服务。

注意：在RHEL/CentOS/Fedora中常见，禁用后不会自动收集崩溃报告。

4. kernel.core_pattern = |/bin/false

echo "kernel.core_pattern = |/bin/false" >> /etc/sysctl.conf
sysctl -p

作用：

core_pattern 定义core文件的生成方式，|/bin/false 表示将core数据通过管道传递给 /bin/false（立即丢弃）。
这是全局生效的，优先级高于ulimit。

注意：使用 |/bin/false 或 |/usr/bin/logger -t core_dump（仅记录日志）是常见做法。

5. systemd-coredump配置

# /etc/systemd/coredump.conf
[Coredump]
Storage=none

systemctl daemon-reexec

作用：

配置systemd不存储核心转储文件（Storage=none）。
daemon-reexec 重新加载systemd管理器配置。

注意：此配置仅影响由systemd管理的服务，不影响用户会话。

验证是否生效

# 检查core_pattern
sysctl kernel.core_pattern
# 检查当前shell的core限制
ulimit -c
# 测试生成core（应失败）
sleep 10 &
kill -SIGSEGV $!  # 触发段错误
ls core* 2>/dev/null || echo "No core dump generated"

注意事项

权限要求：除ulimit用户级设置外，其他操作均需root权限。
安全影响：禁用core dump可能增加故障排查难度，建议在测试环境保留调试能力。
优先级：kernel.core_pattern 的设置会覆盖ulimit的限制。
系统差异：不同发行版可能使用不同的崩溃收集工具（如Ubuntu用apport）。

如果需要临时启用core dump进行调试，可以：

ulimit -c unlimited
sysctl -w kernel.core_pattern=core.%p

NVIDIA OpenGL over RDP 补丁详解

Mon, 05 Jan 2026 08:37:53 +0800

问题背景

RDP (Remote Desktop Protocol) 默认使用微软的显示驱动程序
消费级 GeForce/RTX 显卡在 Windows 远程桌面中：

OpenGL 版本被限制在 1.1（非常古老）
无法使用硬件加速的 OpenGL
影响大量专业应用（CAD、3D建模、科学计算等）

解决方案

NVIDIA OpenGL over RDP 补丁（nvidiaopenglrdp.exe）：

让消费级显卡在 RDP 会话中也能使用完整的 OpenGL 4.6+
绕过微软的 OpenGL 1.1 限制
支持 GeForce、TITAN、RTX 等消费级显卡

安装步骤

1. 下载准备

访问：https://developer.nvidia.com/nvidia-opengl-rdp
需要注册 NVIDIA 开发者账号（免费）
登录后下载对应版本：

nvidiaopenglrdp_x64.exe（64位系统）
nvidiaopenglrdp_x86.exe（32位系统）

2. 安装条件

Windows Server 或 Windows 10/11 专业版/企业版
已安装 NVIDIA 显卡驱动
系统支持远程桌面服务

3. 安装命令

# 以管理员身份运行
nvidiaopenglrdp_x64.exe

# 静默安装（无人值守）
nvidiaopenglrdp_x64.exe /s

4. 验证安装

ls "C:\Windows\System32\DriverStore\FileRepository\nvoclock.inf_*"

注意：用powershell 执行此命令

技术原理

补丁通过以下方式工作：

替换/添加驱动文件：

nvoglv64.dll（OpenGL ICD 驱动程序）
修改 nv_dispig.inf
添加 nvoclock.inf

注册表修改：

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\xxxx
RDPID: REG_BINARY (启用RDP加速)

3.启用WDDM远程显示驱动：

让NVIDIA驱动在远程会话中接管OpenGL调用

应用场景

1. 远程工作站

适用领域:
  - 建筑/工程 CAD: AutoCAD, Revit
    - 3D建模渲染: Blender, Maya, 3ds Max ，
    - 科学计算: MATLAB, Octave
    - GIS系统: ArcGIS, QGIS
    - 医学影像: 3D Slicer, OsiriX

2. 云游戏/云应用

3. 虚拟桌面基础设施 (VDI)

Add-VMGpuPartitionAdapter -VMName "WorkstationVM"
Set-VMGpuPartitionAdapter -VMName "WorkstationVM" -MinPartitionVRAM 1GB

验证脚本

创建一个测试脚本 test_opengl_rdp.ps1：

# PowerShell脚本检测RDP会话中的OpenGL能力$session = qwinstaif ($session -match "rdp-tcp") {
    Write-Host "当前处于RDP会话中" -ForegroundColor Green    
    # 检测NVIDIA驱动
    $nvidia = Get-WmiObject Win32_VideoController | Where-Object {$_.Name -like "*NVIDIA*"}
    if ($nvidia) {
        Write-Host "检测到NVIDIA显卡: $($nvidia.Name)" -ForegroundColor Green        
        # 检查OpenGL支持
        $opengl = Test-Path "C:\Windows\System32\OpenGL32.dll"
        if ($opengl) {
            Write-Host "OpenGL驱动已安装" -ForegroundColor Green        }
    }}# 使用wmic检查wmic path win32_videocontroller get name, driverversion, adaptercompatibility

常见问题解决

1. 安装后仍显示OpenGL 1.1

# 解决方案：
# 1. 重启系统
# 2. 检查驱动签名
bcdedit /set nointegritychecks off
bcdedit /set testsigning off

2. 多用户会话问题

# Windows Server需要配置GPU分区
# 启用Windows Server桌面体验功能
Install-WindowsFeature Server-Gui-Mgmt-Infra

3. 性能优化

# 调整RDP设置以提高图形性能
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "MaxMonitors" -Value 4
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "MaxXResolution" -Value 4096

注意事项

许可限制：消费级显卡不支持多用户并发（需要Quadro/Tesla）
Windows版本：确保Windows版本支持WDDM 2.0+
驱动兼容性：补丁需要与NVIDIA驱动版本匹配
安全考虑：在公网使用RDP时，务必启用网络级认证(NLA)

配置zulip使用LDAP(域控)认证以及一些初始设置

Thu, 11 Dec 2025 09:04:57 +0800

在使用zulip的时候，尤其是内网环境，通常使用windows AD或者ldap进行认证。

而网络上的教程配置通常无法成功，下面将描述笔者在实际生产环境配置zulip的LDAP认证的配置及其他的一些初始设置，只供参考

一、LDAP配置

配置文件：/etc/zulip/settings.py

1、打开LDAP功能，去掉LDAP功能前面的注释符号

 "zproject.backends.ZulipLDAPAuthBackend",

2、配置基本认证功能

AUTH_LDAP_SERVER_URI = "ldap://fasteda.cn:389"
# AD服务器地址+端口（389是LDAP默认端口）
AUTH_LDAP_BIND_DN = "CN=zulip,CN=Users,DC=fasteda,DC=cn"
# 绑定的服务账号DN（用于查询用户），此处需要在AD的Users目录创建一个zulip的账号
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "dc=fasteda,dc=cn", ldap.SCOPE_SUBTREE, "(sAMAccountName=%(user)s)"
)
# 搜索根节点（AD域的根）
# 搜索范围：SUBTREE=递归搜索所有子节点
# 匹配规则：Windows AD的登录名（sAMAccountName）
LDAP_APPEND_DOMAIN = "fasteda.cn"
# 自动给用户名追加域名（如user → user@fasteda.cn）

配置文件：/etc/zulip/zulip-secrets.conf(密码需要写在这个文件中，而不是上面的文件)

增加一行

auth_ldap_bind_password = zulip账号的密码

3、重启zulip服务

su - zulip -c '/home/zulip/deployments/current/scripts/restart-server'

二、其他一些配置

1、修改默认头像

mkdir -p /home/zulip/local-static/
# 创建本地静态文件目录（若不存在）
# 在这个目录下放置一个default-avatar.png图像文件作为默认头像
chown zulip:zulip /home/zulip/local-static/default-avatar.png
chmod 644 /home/zulip/local-static/default-avatar.png
# 设置正确的权限
修改配置文件：/etc/zulip/settings.py
enable_gravatar = False
# 禁用 Gravatar 头像服务（默认是 true，改为 false）default_avatar_uri = '/local-static/default-avatar.png'# 配置本地默认头像路径（取消注释并启用）

2、修改上传文件大小显示

修改配置文件：/etc/zulip/settings.py

MAX_FILE_UPLOAD_SIZE=2000
# 将默认可上传文件限制为2GB

同时还需要修改：/etc/nginx/nginx.conf

client_max_body_size 2000m;
# 与上面的相呼应

3、重启zulip服务和nginx服务

su - zulip -c '/home/zulip/deployments/current/scripts/restart-server'
systemctl restart nginx

先写这些，后续再补充

2026年1月12日补充

Zulip遇到磁盘满，即使清理了磁盘依旧无法启动。可以按照如下方法操作

rabbitmqctl restart_vhost

命令查看报一个62xxxxx的文件夹

找到那个62xxxxxx，删掉。重启zulip即可

多网卡，多VLAN，多网段路由(route)配置方案

Tue, 18 Nov 2025 08:46:34 +0800

在我们日常运维中，有时候难免会遇到某个设备必须为多个网段提供服务的情况。这种情况有时候是设备唯一，也有可能是服务唯一，也或许是配置较为复杂，数据量较大导致的。而这种情况下，如果遇到多个区域之间有隔离，那么就必须设置多网卡的形式。

但是我们知道，默认路由是具有唯一性的，就是 “0.0.0.0/0.0.0.0 GW 网关地址 ” 如果想走其他通路，就必须手动设置路由。

网络结构如下：

有3个区域分别是：

10.0.X.X
10.1.X.X
10.2.X.X

每个网段都有大量的vlan，这些vlan以24为子网掩码，以254为网关。例如：

10.0.1.0/24   10.0.1.254
10.0.10.0/24 10.0.10.254
10.0.100.0/24 10.0.100.254

10.1.1.0/24   10.1.1.254
10.1.10.0/24 10.1.10.254
10.1.100.0/24 10.1.100.254

10.2.1.0/24  10.2.1.254
10.2.10.0/24 10.2.10.254
10.2.100.0/24 10.2.100.254

有一台mirrors服务器，这个服务器存放了大量本地存储的mirror库。那么如何让三个网段都能联通这个服务器呢。

通过搜索引擎，我们搜索到很多关于静态路由的设置方法。但是你会发现，这些仅仅是一些基础而已。

具体如何设置，请看以下操作：

一、确定一个基础网段

这个网段就是你mirrors服务器的主区域。例如我们选择10.0.X.X网段为主区域。设置IP地址如下：

10.0.1.200/24 10.0.1.254 同时通过10.0网段的交换机或者防火墙配置其他vlan与这个IP地址的互通。

其网卡名为ens160(假设)

二、增加网卡，可以是内置网卡，也可以是外置网卡。配置IP，注意此处的子网掩码需要遵循大网段原则。

例如10.1网段，我们不能因为配置了10.1.1.200这个IP，就配置24的子网掩码，我们要兼顾10.1网段下其他vlan

因此10.1网段的IP配置为：

10.1.1.200/16 无网关

其网卡名为ens192(假设)

三、增加网卡配置10.2网段

同10.1网段一样，配置10.2网段的IP地址，配置如下：

10.2.1.100/16 无网关

其网卡名为ens224(假设)

四、手动配置路由进行测试

为10.1网段增加路由，命令如下

route add -net 10.1.0.0/16 gw 10.1.1.254 ens192

为10.2网段增加路由，命令如下

route add -net 10.2.0.0/16 gw 10.2.1.254 ens224

此处需要注意配合上面配置的IP地址，如果你在配置IP的时候的子网掩码与配置路由时候的子网掩码不一致，会报错如下

Network unreachable 网络不可达

五、为什么要这么配置。

1、主网卡（ens160）绑定基础网段（10.0.X.X），带网关保证自身网络连通性，同时依托交换机 / 防火墙配置，覆盖该网段下所有 VLAN 互通。

2、额外网卡（ens192、ens224）采用 / 16 子网掩码，直接覆盖对应大网段（10.1.X.X、10.2.X.X）的所有 VLAN，无需单独配置每个 VLAN 的 IP。

3、静态路由明确绑定 “目标网段 - 网关 - 网卡”，解决默认路由唯一性问题，让不同网段流量走对应网卡通路。

4、子网掩码选择：/16 掩码可覆盖 10.X.0.0-10.X.255.255 的所有地址，刚好匹配每个区域下的大量 VLAN，避免逐 VLAN 配置 IP 的繁琐。

5、网关配置原则：仅主网卡设网关（10.0.1.254），额外网卡不设网关，防止路由冲突；静态路由中指定的网关（10.1.1.254、10.2.1.254），是对应网段的统一出口。

6、路由绑定目的：通过 “route add” 命令明确流量走向，确保 10.1.X.X 网段流量走 ens192 网卡、10.2.X.X 网段流量走 ens224 网卡，避免流量误走主网卡导致网络不可达。

六、具体配置如下：

1、配置主网卡（ens160，10.0.X.X 网段）

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes  # 主网卡作为默认路由
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens160
DEVICE=ens160
ONBOOT=yes
IPADDR=10.0.1.200
PREFIX=24  # 子网掩码255.255.255.0（/24）
GATEWAY=10.0.1.254  # 主网段网关
DNS1=8.8.8.8  # 可选，根据实际环境配置

2、配置 10.1.X.X 网段网卡（ens192）

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=no  # 非默认路由
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens192
DEVICE=ens192
ONBOOT=yes
IPADDR=10.1.1.200
PREFIX=16  # 子网掩码255.255.0.0（/16，覆盖10.1.0.0-10.1.255.255）
# 不配置GATEWAY，避免路由冲突

3、配置 10.2.X.X 网段网卡（ens224）

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=no  # 非默认路由
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=ens224
DEVICE=ens224
ONBOOT=yes
IPADDR=10.2.1.100
PREFIX=16  # 子网掩码255.255.0.0（/16，覆盖10.2.0.0-10.2.255.255）
# 不配置GATEWAY，避免路由冲突

4、配置静态路由（永久生效）

# 10.1.X.X网段路由（通过ens192网卡，网关10.1.1.254）
cat > /etc/sysconfig/network-scripts/route-ens192 << EOF
10.1.0.0/16 via 10.1.1.254 dev ens192
EOF
# 10.2.X.X网段路由（通过ens224网卡，网关10.2.1.254）
cat > /etc/sysconfig/network-scripts/route-ens224 << EOF
10.2.0.0/16 via 10.2.1.254 dev ens224
EOF

5、重启网络服务生效

# CentOS 7systemctl restart network# CentOS 8/RHEL 8nmcli connection reload
nmcli connection up ens160
nmcli connection up ens192
nmcli connection up ens224

6、检查 IP 配置是否正确

ip addr show ens160  # 确认10.0.1.200/24、网关存在
ip addr show ens192  # 确认10.1.1.200/16、无网关
ip addr show ens224  # 确认10.2.1.100/16、无网关

7、检查路由表是否生效

route -n  # 查看所有路由，应包含： 
# 10.0.0.0/24  via 0.0.0.0  dev ens160 （主网段直连） 
# 10.1.0.0/16  via 10.1.1.254  dev ens192 （静态路由） 
# 10.2.0.0/16  via 10.2.1.254  dev ens224 （静态路由） 
# 0.0.0.0/0    via 10.0.1.254  dev ens160 （默认路由）

8、从各网段的主机测试到服务器的连通性（例如）：

# 在10.0.10.XXX主机上 
ping -c 3 10.0.1.200 
 # 在10.1.100.XXX主机上 
ping -c 3 10.1.1.200 
 # 在10.2.10.XXX主机上 
ping -c 3 10.2.1.100

七、常见报错排查手册

1. 报错：`Network unreachable`（配置路由时）

原因 1：网卡 IP 的子网掩码与路由网段不匹配（如网卡用 / 24，路由用 / 16）。排查：ip addr检查网卡 PREFIX 是否为 / 16（10.1 和 10.2 网段），路由网段是否为 10.1.0.0/16 和 10.2.0.0/16。解决：确保网卡子网掩码（/16）包含路由网段（10.1.0.0/16）。
原因 2：路由网关不在网卡所在网段内。排查：10.1.1.254 是否在 ens192 的 / 16 网段（10.1.0.0-10.1.255.255），10.2.1.254 是否在 ens224 的 / 16 网段。解决：网关必须属于网卡 IP 所在的大网段（如 10.1.1.254 属于 10.1.0.0/16）。

2. 报错：某网段主机无法 ping 通服务器

原因 1：服务器对应网卡未启用。排查：ip link show ens192（或 ens224），确认状态为UP。解决：nmcli connection up ens192启用网卡。
原因 2：静态路由未生效。排查：route -n是否存在 10.1.0.0/16 和 10.2.0.0/16 的路由条目。解决：检查/etc/sysconfig/network-scripts/route-ens192配置是否正确，重启网络服务。
原因 3：交换机 / 防火墙隔离。排查：服务器本地能 ping 通对应网段网关（如 10.1.1.254），但主机不能 ping 通服务器，可能是中间设备 ACL 限制。解决：联系网络团队开放服务器 IP 与对应网段的互通规则。

3. 报错：默认路由冲突（多网关导致网络混乱）

原因：额外网卡（ens192/ens224）配置了 GATEWAY，与主网卡默认路由冲突。
排查：cat /etc/sysconfig/network-scripts/ifcfg-ens192确认无 GATEWAY 配置。
解决：删除额外网卡的 GATEWAY 配置，仅保留主网卡的默认路由。

通过以上配置和排查，可确保三个网段的主机正常访问 mirrors 服务器。若遇特殊网络环境（如 VLAN 标签、bonding 等），需额外配置对应参数（如VLAN=yes、MASTER=bond0等）。

使用LSF_HOSTS解决动态提交节点的反向解析

Wed, 22 Oct 2025 14:27:59 +0800

前言：在LSF系统管理中，正反向IP地址解析是LSF集群各节点通信的重要组成部分，缺少正反向解析的LSF集群将无法提交JOB，亦无法执行JOB。

在LSF软件默认缺省的情况下，LSF解析通常遵守以下顺序

1、默认系统hosts文件，即 /etc/hosts

2、 LSF自带的解析文件，在LSF_CONFIGDIR目录中

3、默认系统DNS，即 /etc/resolv.conf中配置的DNS服务器

其中，1与2的格式相同，如下：

IPaddress  hostname alias_hostname

在大规模、超大规模的LSF集群中，通常使用DNS作为正反向解析的依据。但是由于DNS的不确定性，尤其是在动态提交节点的情况下，每个提交节点都需要在DNS上注册正反向解析记录，因此可能存在DNS更新不及时或者注册不成功的情况。

在这种情况下，可通过LSF自带的解析文件形式补充DNS记录，实现动态提交节点的正反向解析补充。

一、在LSF_CONFIGDIR目录中创建一个HOSTS文件，并赋予777的权限

#cd /xxx/lsf/conf/
#touch lsf_hosts
#chmod 777 lsf_hosts

二、在一个公共目录创建一个自动更新的脚本update_lsf_hosts.csh

#!/bin/csh -f
 
set TARGET_IP = `/sbin/ip a s |grep 10.1 |awk -F " " '{print $2}'|awk -F "/" '{print $1}'`
#此处用来获取IP地址
set TARGET_HOST = `hostname`
#此处用来获取主机名
set HOSTS_FILE = "/xx/lsf/conf/lsf_hosts"
#此处定义lsf_hosts文件位置
set DNS_NAME = `echo $TARGET_IP $TARGET_HOST`
此处组合IP地址和主机名为hosts格式
#echo $DNS_NAME
 
if ( !( $TARGET_HOST =~ "*fasteda*" )  ) then
#此处需要用户自行判断主机名的信息
    exit 0
endif 
#判断主机名在lsf_hosts文件中是否存在，进行下面的操作

if ( `grep -c "$DNS_NAME" "$HOSTS_FILE"` > 0 ) then
       echo "${TARGET_IP} ${TARGET_HOST}"
#    echo "EXIST  $TARGET_IP $TARGET_HOST"
    exit 0
endif
 
#echo "NOT found host ,start work..."
#由于sed命令需要文件所在目录的写权限，因此采用下面的方法进行删除与替换
set TEMP_FILE = `mktemp`
 
cat $HOSTS_FILE |grep -v -E "$TARGET_IP|$TARGET_HOST" >  $TEMP_FILE
 
echo $DNS_NAME >> $TEMP_FILE
 
cat $TEMP_FILE > $HOSTS_FILE
 
echo "You First use this  system"
echo "Please wait 30s .............."

三、将此脚本赋予权限，并设置到用户的默认csh文件中进行source操作

#chmod 755 update_lsf_hosts.csh
#echo “source /xxx/update_lsf_hosts.csh” > /home/xxx/.cshrc

注意：这里是一个实例，如果是统一的cshrc文件，那最好了，直接写在这个文件中

用户在下次启动动态节点的时候，将自动将IP与hostname关系写入到/xx/lsf/conf/lsf_hosts文件中，并且lsf会优先DNS读取这个文件。

实例效果如下：

#cat /xx/lsf/conf/lsf_hosts
10.1.1.58 sub01.fasteda.cn
10.1.1.56 sub02.fasteda.cn
10.1.1.78 sub03.fasteda.cn
10.1.1.54 sub04.fasteda.cn
10.1.1.79 sub05.fasteda.cn

同时，本内容适用于缺少DNS服务器，但是需要使用动态节点的情况。当然，具备管理员权限的节点，可以使用EGO的方式，原理差不多。