diff --git a/docs/zh/faq/_menu.md b/docs/zh/faq/_menu.md new file mode 100644 index 0000000000000000000000000000000000000000..67f9142dcb5747933830739bc8cf0fdee2c67a18 --- /dev/null +++ b/docs/zh/faq/_menu.md @@ -0,0 +1,62 @@ +--- +label: '常见问题' +children: + - label: '通用' + children: + - label: '社区通用' + href: './general/general_faq.md' + - label: '特性通用' + href: './general/project_intro_faq.md' + - label: '服务器' + children: + - label: '系统管理' + href: './server/administration_faq.md' + - label: '系统性能' + href: './server/system_management_faq.md' + - label: '系统安装（服务器）' + href: './server/installation_faq1.md' + - label: '系统安装（树莓派）' + href: './server/installation_faq2.md' + - label: '迁移' + href: './server/imigration_faqs.md' + - label: '可信计算' + href: './server/trusted_computing_faqs.md' + - label: 'A-Tune' + href: './server/atune_faqs.md' + - label: '内核热升级' + href: './server/kernel_faqs.md' + - label: 'SysCare' + href: './server/syscare_faqs.md' + - label: '应用开发' + href: './server/applicationdev_faqs.md' + - label: '云原生' + children: + - label: 'iSulad' + href: './cloud/isula_faqs.md' + - label: 'Docker' + href: './cloud/docker_faqs.md' + - label: '容器镜像构建' + href: './cloud/isula_build_faqs.md' + - label: 'Kubernetes' + href: './server/kubernetes_faqs.md' + - label: 'Kmesh' + href: './server/kmesh_faqs.md' + - label: '虚拟化' + children: + - label: '虚拟化' + href: './virtualization/virt_faqs.md' + - label: '社区工具' + children: + - label: 'isocut' + href: './community_tools/isocut_faqs.md' + - label: 'DDE' + href: './community_tools/dde_faqs.md' + - label: 'patch-tracking' + href: './community_tools/patch_tracking_faqs.md' + - label: 'xfce' + href: './community_tools/xfce_faqs.md' + - label: '技术案例' + children: + - label: '案例汇总' + href: './caselibrary/caselibrary_menu.md' +--- diff --git a/docs/zh/faq/cloud/docker-faqs.md b/docs/zh/faq/cloud/docker_faqs.md similarity index 100% rename from docs/zh/faq/cloud/docker-faqs.md rename to docs/zh/faq/cloud/docker_faqs.md diff --git a/docs/zh/faq/cloud/isula-build-faqs.md b/docs/zh/faq/cloud/isula_build_faqs.md similarity index 100% rename from docs/zh/faq/cloud/isula-build-faqs.md rename to docs/zh/faq/cloud/isula_build_faqs.md diff --git a/docs/zh/faq/cloud/isula-faqs.md b/docs/zh/faq/cloud/isula_faqs.md similarity index 100% rename from docs/zh/faq/cloud/isula-faqs.md rename to docs/zh/faq/cloud/isula_faqs.md diff --git a/docs/zh/faq/cloud/kmesh-faqs.md b/docs/zh/faq/cloud/kmesh_faqs.md similarity index 100% rename from docs/zh/faq/cloud/kmesh-faqs.md rename to docs/zh/faq/cloud/kmesh_faqs.md diff --git a/docs/zh/faq/cloud/kubernetes-faqs.md b/docs/zh/faq/cloud/kubernetes_faqs.md similarity index 100% rename from docs/zh/faq/cloud/kubernetes-faqs.md rename to docs/zh/faq/cloud/kubernetes_faqs.md diff --git a/docs/zh/faq/community_tools/dde-faqs.md b/docs/zh/faq/community_tools/dde_faqs.md similarity index 100% rename from docs/zh/faq/community_tools/dde-faqs.md rename to docs/zh/faq/community_tools/dde_faqs.md diff --git a/docs/zh/faq/community_tools/isocut-faqs.md b/docs/zh/faq/community_tools/isocut_faqs.md similarity index 100% rename from docs/zh/faq/community_tools/isocut-faqs.md rename to docs/zh/faq/community_tools/isocut_faqs.md diff --git a/docs/zh/faq/community_tools/patch-tracking-faqs.md b/docs/zh/faq/community_tools/patch_tracking-_aqs.md similarity index 100% rename from docs/zh/faq/community_tools/patch-tracking-faqs.md rename to docs/zh/faq/community_tools/patch_tracking-_aqs.md diff --git a/docs/zh/faq/community_tools/xfce-faq.md b/docs/zh/faq/community_tools/xfce_faq.md similarity index 100% rename from docs/zh/faq/community_tools/xfce-faq.md rename to docs/zh/faq/community_tools/xfce_faq.md diff --git a/docs/zh/faq/general/general.md b/docs/zh/faq/general/general_faq.md similarity index 55% rename from docs/zh/faq/general/general.md rename to docs/zh/faq/general/general_faq.md index b3791f9074ab9f0ba98ce7e3d68527e878422bd6..b5399fb1fa8f11534538f176093c4629d1f66fc3 100644 --- a/docs/zh/faq/general/general.md +++ b/docs/zh/faq/general/general_faq.md @@ -63,54 +63,6 @@ openEuler社区欢迎您的加入，期待您能在社区中提升技能、结 openEuler目前已广泛应用于各行各业，包括政务、金融、运营商、互联网、电力、制造业、能源、教育、交通和医疗等行业。 openEuler 希望与广大生态伙伴、用户、开发者一起，通过联合创新、社区共建，不断增强场景化能力，最终实现统一操作系统支持多设备，应用一次开发覆盖全场景。 -## openEuler的WSL应用场景有？ - -- 在 Windows 中快速部署和体验 openEuler LTS 版本。 -- 利用 vs code 和 openEuler WSL 打造流畅跨平台开发体验。 -- 在 openEuler WSL 中搭建 K8S 集群。 -- 用你喜爱的 openEuler command-line 程序或脚本处理 Windows 或 WSL 中的文件和程序。 - -## openEuler中的HMDFS是什么 ？ - -HMDFS 是从 OH 社区迁移而来的在软总线生态之上的一个分布式文件系统， 其在分布式软总线动态组网的基础上， 为 网络上各个设备结点提供一个全局一致的访问视图，支持开发者通过基础文件系统接口进行读写访问，具有高性能、低延 时等优点。 - -## openEuler中的SysCare软件是什么？ - -SysCare 是一个系统级热修复软件，为操作系统提供安全补丁和系统错误热修复能力，主机无需重新启动即可修复该 系统问题。 SysCare 将内核态热补丁技术与用户态热补丁技术进行融合统一，用户仅需聚焦在自己核心业务中，系统修复 问题交予 SysCare 进行处理。后期计划根据修复组件的不同，提供系统热升级技术，进一步解放运维用户提升运维效率。 - -## 什么是A-Ops？ - -A-Ops 是一款基于操作系统维度的故障运维平台，提供从数据采集，健康巡检，故障诊断，故障修复的到智能运维解 决方案。A-Ops 项目包括了若干子项目：覆盖故障发现（Gala） ，故障定位支撑（X-diagnosis） ，缺陷修复（Apollo） 等。 - -## secGear 主要提供哪三大能力？ - -- 架构兼容：屏蔽不同 SDK 接口差异，提供统一开发接口，实现不同架构共源码。 -- 易开发：提供开发工具、通用安全组件等，帮助用户聚焦业务，开发效率显著提升。 -- 高性能：提供零切换特性，在 REE-TEE 频繁交互、大数据交互等典型场景下提升 REE-TEE 交互性能 10 倍 +。 - -## AI for OS 安全主要有哪些技术？ - -- 漏洞挖掘：自动化漏洞挖掘是当前操作系统安全研究的热点，无论是 基于代码分析的，还是模糊测试的，亦或两者结合的漏洞挖掘技术，都可以有 效地识别出当前系统中存在的缺陷。传统的模糊测试工具在种子生成、选择、 变异、测试、评估、反馈等多个环节都存在一定的盲目性和随机性，代码分析 技术，无论是源码级，还是二进制级或者特定拓展成 DSL(Domain- Specific Language) 的 IR(Intermediate Representation) 级，都十分依赖基于专家经验构 建的缺陷模式库。结合人工智能技术，可以很好地挖掘缺陷代码数据集中的模式信息，从而指导模糊测试和代码分析技术的各个过程，有效地提升识别精度 和效率。 - -- 入侵检测：以APT 威胁为代表的现代安全问题持续出现且变幻莫测， 攻击组织会使用一整套大型的攻击武器库，对目标系统进行自动化、持续的攻 击尝试和自反馈，并且基于固定模式的安全防御技术难以抵御未知的威胁。因 此，我们需要结合人工智能技术，自动化深度挖掘其中的关键特征，支持多种 高维数据的联合特征提取。这在当前大数据时代是必须具备的能力，但是对于 个人来说却又是困难的。另外，结合人工智能技术可以更有效地识别出系统中 的异常行为或者状态，从而更准确、更及时地进行攻击阻断。比如，在异常流 量检测、侧信道攻击检测领域中，通过结合人工智能技术的入侵检测技术，都 取得了很好的效果。 - -## openEuler 提供的多级调度框架有什么优势？ - -openEuler 提供了多级调度框架，实现多种调度模型共存，业务可根 -据需要进行调度模型的选择。 - -- 相比于传统的进程/线程调度模型更为灵活，可移植性更好。 -- 新增的协程等轻量级调度模型切换更快，调度时间占比更小。 - -## 根据openEuler操作系统安全机制的作用范围，可将这些安全机制分为哪三种类型？ - -真实性保护、完整性保护和机密性保护三种类型 - -## 工业安全领域openEuler系统运用的安全隔离技术主要有哪两种范式？ - -- 隔离已知来源但可能存在漏洞的服务，以削减其受到攻击后对系统其 他组成部分造成的危害。 -- 限制不受信任来源的代码(可能是恶意代码或存在漏洞的组件)可能 对系统其他组成部分造成的危害。 - ## openEuler操作系统噪声是指什么？ 操作系统噪声是指业务运行中执行的非应用计算任务，包括： @@ -125,21 +77,3 @@ openEuler 提供了多级调度框架，实现多种调度模型共存，业务 ## openEuler常用repo源 为了方便大家快速找到openEuler所需版本的repo源，现将openEuler各版本的repo源进行了整理并归类，详情可查看： - -## 迁移过程中可能需要用到的网站链接 - -openEuler迁移专区: - -- x2openEuler官方文档 -- x2openEuler工具下载 -- x2openEuler需要用到的openEuler的源 - -- x2openEuler兼容性分析比对数据库centos7/8—>openEuler22.03-LTS下载地址 - -- x2openEuler迁移学习 - -## 为什么在同样分配的物理内存下，openEuler 显示的可用内存比 CentOS 少？ - -这个问题是两个操作系统在分配给 crashkernel（内核崩溃时使用的内存区域）的内存大小不同导致的。在实验中，给两个操作系统都分配了 4G 的内存，但是 CentOS 可用内存为 3.7G，而 openEuler 可用内存只有 3.3G。通过查看系统的 dmesg 日志，发现在 CentOS 中为 crashkernel 预留的内存是 161MB，而在 openEuler 中预留的内存是 512MB。将 openEuler 的 crashkernel 内存预留修改为 256MB 后，可用内存与 CentOS 相同，从而证明了是由于 crashkernel 的内存预留差异导致的可用内存差异。 - -解决方法：在 openEuler 的 grub 配置文件（/boot/grub2/grub.cfg）中将 crashkernel 的预留内存从 512MB 修改为 256MB，可以解决这个问题。 diff --git a/docs/zh/faq/general/project_intro_faq.md b/docs/zh/faq/general/project_intro_faq.md new file mode 100644 index 0000000000000000000000000000000000000000..d2b044f6e9c6e847885d68d041b9dc09d896a453 --- /dev/null +++ b/docs/zh/faq/general/project_intro_faq.md @@ -0,0 +1,49 @@ +# 特性通用问题 + +## openEuler的WSL应用场景有？ + +- 在 Windows 中快速部署和体验 openEuler LTS 版本。 +- 利用 vs code 和 openEuler WSL 打造流畅跨平台开发体验。 +- 在 openEuler WSL 中搭建 K8S 集群。 +- 用你喜爱的 openEuler command-line 程序或脚本处理 Windows 或 WSL 中的文件和程序。 + +## openEuler中的HMDFS是什么 ？ + +HMDFS 是从 OH 社区迁移而来的在软总线生态之上的一个分布式文件系统， 其在分布式软总线动态组网的基础上， 为 网络上各个设备结点提供一个全局一致的访问视图，支持开发者通过基础文件系统接口进行读写访问，具有高性能、低延 时等优点。 + +## openEuler中的SysCare软件是什么？ + +SysCare 是一个系统级热修复软件，为操作系统提供安全补丁和系统错误热修复能力，主机无需重新启动即可修复该 系统问题。 SysCare 将内核态热补丁技术与用户态热补丁技术进行融合统一，用户仅需聚焦在自己核心业务中，系统修复 问题交予 SysCare 进行处理。后期计划根据修复组件的不同，提供系统热升级技术，进一步解放运维用户提升运维效率。 + +## 什么是A-Ops？ + +A-Ops 是一款基于操作系统维度的故障运维平台，提供从数据采集，健康巡检，故障诊断，故障修复的到智能运维解 决方案。A-Ops 项目包括了若干子项目：覆盖故障发现（Gala） ，故障定位支撑（X-diagnosis） ，缺陷修复（Apollo） 等。 + +## secGear 主要提供哪三大能力？ + +- 架构兼容：屏蔽不同 SDK 接口差异，提供统一开发接口，实现不同架构共源码。 +- 易开发：提供开发工具、通用安全组件等，帮助用户聚焦业务，开发效率显著提升。 +- 高性能：提供零切换特性，在 REE-TEE 频繁交互、大数据交互等典型场景下提升 REE-TEE 交互性能 10 倍 +。 + +## AI for OS 安全主要有哪些技术？ + +- 漏洞挖掘：自动化漏洞挖掘是当前操作系统安全研究的热点，无论是 基于代码分析的，还是模糊测试的，亦或两者结合的漏洞挖掘技术，都可以有 效地识别出当前系统中存在的缺陷。传统的模糊测试工具在种子生成、选择、 变异、测试、评估、反馈等多个环节都存在一定的盲目性和随机性，代码分析 技术，无论是源码级，还是二进制级或者特定拓展成 DSL(Domain- Specific Language) 的 IR(Intermediate Representation) 级，都十分依赖基于专家经验构 建的缺陷模式库。结合人工智能技术，可以很好地挖掘缺陷代码数据集中的模式信息，从而指导模糊测试和代码分析技术的各个过程，有效地提升识别精度 和效率。 + +- 入侵检测：以APT 威胁为代表的现代安全问题持续出现且变幻莫测， 攻击组织会使用一整套大型的攻击武器库，对目标系统进行自动化、持续的攻 击尝试和自反馈，并且基于固定模式的安全防御技术难以抵御未知的威胁。因 此，我们需要结合人工智能技术，自动化深度挖掘其中的关键特征，支持多种 高维数据的联合特征提取。这在当前大数据时代是必须具备的能力，但是对于 个人来说却又是困难的。另外，结合人工智能技术可以更有效地识别出系统中 的异常行为或者状态，从而更准确、更及时地进行攻击阻断。比如，在异常流 量检测、侧信道攻击检测领域中，通过结合人工智能技术的入侵检测技术，都 取得了很好的效果。 + +## openEuler 提供的多级调度框架有什么优势？ + +openEuler 提供了多级调度框架，实现多种调度模型共存，业务可根 +据需要进行调度模型的选择。 + +- 相比于传统的进程/线程调度模型更为灵活，可移植性更好。 +- 新增的协程等轻量级调度模型切换更快，调度时间占比更小。 + +## 根据openEuler操作系统安全机制的作用范围，可将这些安全机制分为哪三种类型？ + +真实性保护、完整性保护和机密性保护三种类型 + +## 工业安全领域openEuler系统运用的安全隔离技术主要有哪两种范式？ + +- 隔离已知来源但可能存在漏洞的服务，以削减其受到攻击后对系统其 他组成部分造成的危害。 +- 限制不受信任来源的代码(可能是恶意代码或存在漏洞的组件)可能 对系统其他组成部分造成的危害。 diff --git a/docs/zh/faq/server/atune-faqs.md b/docs/zh/faq/server/atune_faqs.md similarity index 100% rename from docs/zh/faq/server/atune-faqs.md rename to docs/zh/faq/server/atune_faqs.md diff --git a/docs/zh/faq/server/kernel_faq.md b/docs/zh/faq/server/kernel_faqs.md similarity index 100% rename from docs/zh/faq/server/kernel_faq.md rename to docs/zh/faq/server/kernel_faqs.md diff --git a/docs/zh/faq/server/migration_faqs.md b/docs/zh/faq/server/migration_faqs.md new file mode 100644 index 0000000000000000000000000000000000000000..88f27af2ae230c5ed929c65ba1ac02e0b3432476 --- /dev/null +++ b/docs/zh/faq/server/migration_faqs.md @@ -0,0 +1,64 @@ +# 迁移常见问题与解决方法 + +## 迁移过程中可能需要用到的网站链接 + +openEuler迁移专区: + +- x2openEuler官方文档 +- x2openEuler工具下载 +- x2openEuler需要用到的openEuler的源 + +- x2openEuler兼容性分析比对数据库centos7/8—>openEuler22.03-LTS下载地址 + +- x2openEuler迁移学习 + +## 为什么在同样分配的物理内存下，openEuler 显示的可用内存比 CentOS 少？ + +这个问题是两个操作系统在分配给 crashkernel（内核崩溃时使用的内存区域）的内存大小不同导致的。在实验中，给两个操作系统都分配了 4G 的内存，但是 CentOS 可用内存为 3.7G，而 openEuler 可用内存只有 3.3G。通过查看系统的 dmesg 日志，发现在 CentOS 中为 crashkernel 预留的内存是 161MB，而在 openEuler 中预留的内存是 512MB。将 openEuler 的 crashkernel 内存预留修改为 256MB 后，可用内存与 CentOS 相同，从而证明了是由于 crashkernel 的内存预留差异导致的可用内存差异。 + +解决方法：在 openEuler 的 grub 配置文件（/boot/grub2/grub.cfg）中将 crashkernel 的预留内存从 512MB 修改为 256MB，可以解决这个问题。 + +## 如果在迁移软件包时遇到宏无法解析的问题，该如何解决？ + +这通常发生在从CentOS或Fedora迁移到其他系统时，因为不同系统的宏定义可能不同。解决方法有两种：一是查询宏的具体含义，并在spec文件中用其实际值替换宏；二是将提供宏定义的macros软件包引入到仓库中，并在BuildRequires中添加，以确保宏能够正确解析。 + +## 在进行虚拟机热迁移时，应该如何准备环境并检查迁移前的必要条件？ + +进行虚拟机热迁移前，需要准备两个物理机（源端和目的端）并进行一系列的检查来确保迁移可以顺利进行。这些检查包括： + +权限检查：确保当前用户有执行热迁移的权限。 +网络检查：检查源端和目的端主机之间的网络是否互通，并保证两个主机在相同网段。 +存储资源检查：确认两端是否可以访问相同的存储资源，并确保目的端主机有足够的CPU、内存和存储资源。 +CPU资源检查：确认两个主机的CPU资源情况。 +内存检查：核实两个主机的内存情况。 +存储检查：检查两个主机的存储配置。 +虚拟机状态检查：确认被迁移的虚拟机处于运行状态。 +此外，可根据需要设置热迁移参数，如最大停机时间和迁移过程中的最大带宽，以及确定存储方式是共享存储还是非共享存储。在非共享存储的情况下，可能还需要进行额外的配置，如通过NFS设置共享存储。 + +## 什么是虚拟机热迁移，它与虚拟机冷迁移有什么区别？ + +虚拟机热迁移是一种技术，它允许在不关闭虚拟机的情况下，将整个虚拟机的运行状态（包括内存中的数据和磁盘上的数据）完整地迁移到另一台物理服务器上。这种迁移过程对用户来说是透明的，即用户不会感受到任何服务中断或性能下降。热迁移通常用于硬件维护、升级，或是负载均衡等场景，确保关键业务连续性和服务的高可用性。 + +相比之下，虚拟机冷迁移（也称为静态迁移）涉及到在迁移前关闭虚拟机。这意味着在迁移过程中，该虚拟机上的服务是不可用的。冷迁移适用于非实时或可容忍停机时间的场景，例如批量处理作业或非关键业务的迁移。 + +总结两者的主要区别： + +1. 热迁移允许在不停机的情况下迁移虚拟机，保证了业务的连续性；而冷迁移需要在迁移前关闭虚拟机，导致服务暂时不可用。 +2. 热迁移对用户透明，用户体验不会受到影响；冷迁移则可能导致服务中断。 +3. 热迁移技术复杂度较高，因为它需要同步迁移内存中的数据；而冷迁移相对简单，因为只涉及静态数据的迁移。 + +## 如何将SQL Server数据从Windows迁移到openEuler？ + +首先，在Windows上备份SQL Server数据库。可以使用SQL Server Management Studio (SSMS) 或使用SQL语句的方法进行备份。备份完成后，使用scp或其他方法将备份文件传输到openEuler系统。在openEuler上，创建一个新的备份目录并将备份文件移动到该目录。使用sqlcmd工具，执行SQL语句来还原数据库。如果数据库包含辅助文件，需要在RESTORE DATABASE命令中为这些文件添加MOVE子句。最后，通过列举所有数据库来验证数据迁移是否成功。 + +## 在进行CentOS到openEuler的操作系统迁移时，为什么需要考虑硬件兼容性检测？ + +硬件兼容性检测在CentOS到openEuler的迁移中至关重要，因为这不仅涉及到操作系统的更换，还包括对操作系统上运行的应用软件和业务系统的替代、适配、迁移和重构。确保硬件兼容性可以保障迁移过程中的系统稳定性和业务的连续性，防止迁移后出现硬件不兼容导致的应用故障或性能下降。 + +## openEuler社区提供的迁移工具x2openEuler具备哪些功能，它是如何应用于迁移评估？ + +openEuler社区提供的迁移工具x2openEuler主要用于迁移评估，具备以下功能： + +1. 软件评估：通过扫描依赖的软件包清单信息，对各类应用（如rpm, tar, zip, gzip, jar, py, pyc, sh, bin等）进行评估，并生成HTML格式的评估报告。 +2. 配置收集与评估：支持收集用户环境数据并生成JSON格式文件，包括硬件配置、配置接口、内核选项配置参数、系统配置参数（sysctl/proc/sys）、环境变量、服务、进程、端口、命令接口、系统调用项和设备驱动接口等信息，并完成配置信息分析评估。 +3. 硬件评估：评估运行环境的整机和整机板卡（如RAID, NIC, FC, IB, GPU, SSD, TPM等）是否在openEuler的兼容性清单中。这些功能帮助用户在迁移之前识别潜在的兼容性问题，为顺利迁移提供支持。 diff --git a/docs/zh/faq/server/system_management_faq.md b/docs/zh/faq/server/system_management_faq.md new file mode 100644 index 0000000000000000000000000000000000000000..4f6bf49d95fd9ac612df76272f62a567b879c631 --- /dev/null +++ b/docs/zh/faq/server/system_management_faq.md @@ -0,0 +1,25 @@ +# 系统性能常见问题与解决方法 + +## 为什么在 openEuler 22.03 SP1 系统中，启动 NFS 服务后，尽管最初可以达到千兆网络速率，但经过不到一天的写入操作，客户端的响应速度会急剧下降到大约 2MB/s？ + +这个性能下降的主要原因是 NFS 服务端的缓存上涨至 50% 时，其性能会骤降。这种现象主要是由于内存分配和回收机制的问题。在申请内存的过程中，系统不会立即同步回收内存，而是依赖于较慢的后台内存回收机制。当系统无法及时申请到足够的内存时，会导致等待时间（如 500 毫秒的延迟）。这个问题在高负载下尤为明显，因为 NFS 服务端需要大量内存来处理客户端的请求。随着服务运行时间的增长，可用内存的减少会导致性能急剧下降，特别是在密集的写入操作中。 + +## 如何解决 openEuler 系统中由于 ext4 文件系统的 inode 错误而导致的文件创建失败问题？ + +为了解决这个问题，应该在处理 dx_node 块的 rec_len 字段时使用正确的方法。正确的做法是使用 ext4_rec_len_from_disk() 函数来转换 rec_len 为 65536，然后进行比较。这样可以确保在添加新的 dx_node 块时，正确地设置 rec_len 字段，并为节点计算并设置正确的校验和。这个更正将避免由于校验和不正确导致的 inode 错误，从而允许系统正常创建和管理大量文件。 + +## 如何解决 openEuler 系统中业务进程因 glibc 线程缓存特性导致的内存占用过高问题？ + +解决这个问题的方法是关闭 glibc 的线程缓存特性。这可以通过在启动程序之前设置环境变量来实现。具体操作是在 bash_profile 中添加 GLIBC_TUNABLES=glibc.malloc.tcache_count=0，这样可以关闭线程缓存。在进程启动后，还需要检查进程的环境变量（/proc/pid/environ）以确保成功添加。关闭 glibc 的 tcache 之后，进程的内存管理将与 glibc 2.17 版本一致，不会有其他副作用。根据客户反馈，实施这一修改方案后，内存占用明显降低，且相比于 CentOS，openEuler 的内存占用也变得更低。 + +## 为什么在 ARM 架构上进行 fio 压测多盘场景时，性能仅为 X86 架构的一半？ + +在 ARM 架构下进行 fio 压测时，性能低于 X86 架构的主要原因是中断处理机制的差异。在 ARM 环境中，8 盘同时压测时，所有盘的中断都集中在了 0、32、64 核心上，导致处理这些中断的 CPU 被压满。这个瓶颈主要是由于 ARM 架构下的 LPI (Large Payload Interface) 中断和 X86 架构下的 APIC 中断的实现机制不同。X86 架构通过 APIC 实现了中断负载均衡，而 ARM 架构的 LPI 中断主要由 ITS (Interrupt Translation Service) 驱动程序处理，它会默认将中断分配到最低编号的 CPU，导致单核处理中断出现瓶颈。 + +## 为什么在机器掉电后，系统启动时 xfs 文件系统会出现问题，执行 ls 命令时显示 input/output error？ + +机器掉电可以导致 xfs 文件系统损坏，因为掉电可能发生在文件系统写入操作的过程中，导致数据未能完全写入磁盘。当系统重新启动后，xfs文件系统可能处于不一致的状态，这种状态下执行文件系统操作，如 ls 命令，可能会遇到输入/输出错误。这类错误通常表明文件系统的某些部分未能正确加载或读取，可能是由于文件系统元数据损坏或者未完成的写入操作造成的。 + +## 如何解决系统启动时未使用新内核的问题？ + +要解决这个问题，用户需要将 /boot/grub2/grub.cfg 文件的内容替换为 /boot/efi/EFI/xxxx/grub.cfg 中的内容。这样做可以确保在启动时系统会读取包含新内核的正确配置文件。此外，检查并确认系统的引导模式（UEFI 或 legacy）也是解决此类问题的重要步骤。 diff --git a/docs/zh/faq/virtulization/virt-faq.md b/docs/zh/faq/virtualization/virt_faq.md similarity index 100% rename from docs/zh/faq/virtulization/virt-faq.md rename to docs/zh/faq/virtualization/virt_faq.md