CN112817986B

CN112817986B - 适用于Linux生产环境的数据结构修复方法及装置

Info

Publication number: CN112817986B
Application number: CN202110218365.1A
Authority: CN
Inventors: 陈亮; 刘国辉
Original assignee: Beijing Easy Star Technology Development Co ltd
Current assignee: Beijing Easy Star Technology Development Co ltd
Priority date: 2021-02-26
Filing date: 2021-02-26
Publication date: 2022-03-22
Anticipated expiration: 2041-02-26
Also published as: CN112817986A

Abstract

本发明提供一种适用于Linux生产环境的数据结构修复方法及装置，包括：使内核空间与Linux用户空间建立交互通道，Linux用户空间基于所述交互通道向所述内核空间发送和\或建立指令；基于指令遍历内核空间处的数据结构，获取每一个数据结构后作为参数调用先前注册的回调函数，基于所述回调函数确定每个数据结构的具体处理方式；基于所述具体处理方式对所述数据结构进行处理。本发明提供的技术方案，在生产环境仍然运行的情况下，以***可扩展的修正模块的方式，遍历***基础数据结构，找出问题数据结构并予以修正或导出有价值的信息，辅助工作人员对***进行修复。

Description

适用于Linux生产环境的数据结构修复方法及装置

技术领域

本发明涉及技术，尤其涉及一种适用于Linux生产环境的数据结构修复方法及装置。

背景技术

近年云计算技术迅速发展，许多产业陆续将业务转移到云平台的虚拟机(virtualmachine)或者容器(container)上，云平台供应商必须负责客户业务虚拟机的可靠性、稳定性与安全性。而这些特性往往与云平台的基础设施，即操作***息息相关，操作***提供丰富的硬件架构、内存、进程、网络、存储、虚拟化支持，并且不断的在演进中，在这庞大的***里出现一些漏洞或错误是难免的，在一般情况下Linux内核社群或相关的Linux发行版开发商都能很快识别问题并提出修复补丁，对于一般使用者来说已经达到解决问题的目的，但对云平台供应商而言就未必能符合需求，因为打上这些补丁后是需要重启***的，对于业务量庞大的云平台，重启***是需要尽量避免的。当前，当前并没有一个有效的机制，能在不重启机器的前提下对Linux生产环境中的错误进行修复。

发明内容

本发明实施例提供一种适用于Linux生产环境的数据结构修复方法及装置，能够在不重启机器的前提下对Linux生产环境中的错误进行修复。

本发明实施例的第一方面，提供一种适用于Linux生产环境的数据结构修复方法，包括：

使内核空间与Linux用户空间建立交互通道，Linux用户空间基于所述交互通道向所述内核空间发送和\或建立指令；

基于指令遍历内核空间处的数据结构，获取每一个数据结构后作为参数调用先前注册的回调函数，基于所述回调函数确定每个数据结构的具体处理方式；

基于所述具体处理方式对所述数据结构进行处理。

可选地，在第一方面的一种可能实现方式中，还包括：

基于所述交互通道查询已注册和\或已建立的指令。

可选地，在第一方面的一种可能实现方式中，所述基于指令遍历内核空间处的数据结构包括：

预先注册一个指令，其中所述指令中包含有遍历数据信息，所述遍历数据信息与待处理问题对应设置；

基于所述指令遍历对应的内核数据后，进行修复处理。

可选地，在第一方面的一种可能实现方式中，基于所述具体处理方式对所述数据结构进行处理包括：

获取每个所有缓存中用量为0且所属的cgroup已被删除的这些缓存，调用回调函数进行注销。

本发明实施例的第二方面，提供一种适用于Linux生产环境的数据结构修复装置，包括：

主交互模块，用于使内核空间与Linux用户空间建立交互通道，Linux用户空间基于所述交互通道向所述内核空间发送和\或建立指令；

命令调用模块，用于基于指令遍历内核空间处的数据结构，获取每一个数据结构后作为参数调用先前注册的回调函数，基于所述回调函数确定每个数据结构的具体处理方式；

处理模块，用于基于所述具体处理方式对所述数据结构进行处理。

可选地，在第二方面的一种可能实现方式中，还包括应用层工具模块，用于基于所述交互通道查询已注册和\或已建立的指令。

可选地，在第二方面的一种可能实现方式中，所述基于指令遍历内核空间处的数据结构包括：

基于所述指令遍历对应的内核数据后，进行修复处理。

可选地，在第二方面的一种可能实现方式中，基于所述具体处理方式对所述数据结构进行处理包括：

本发明的第三方面提供了一种电子设备，所述电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行第一方面任意一项提供的方法。

本发明实施例的第四方面，提供一种可读存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时用于实现本发明第一方面及第一方面各种可能设计的所述方法。

本发明提供的一种适用于Linux生产环境的数据结构修复方法及装置，在生产环境仍然在运行的情况下，以***可扩展的修正模块的方式，遍历***基础数据结构，找出问题数据结构并予以修正或导出有价值的信息。

附图说明

图1为现有技术中场景1的第一种情况的示意图；

图2为现有技术中场景1的第二种情况的示意图；

图3为现有技术中场景2的第一种情况的示意图；

图4为适用于Linux生产环境的数据结构修复装置的第一种实施方式的示意图；

图5为适用于Linux生产环境的数据结构修复方法的第一种实施方式的示意图；

图6为适用于Linux生产环境的数据结构修复装置的第二种实施方式的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。

应当理解，在本发明的各种实施例中，各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

应当理解，在本发明中，“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本发明中，“多个”是指两个或两个以上。“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。“包含A、B和C”、“包含A、B、C”是指A、B、C三者都包含，“包含A、B或C”是指包含A、B、C三者之一，“包含A、B和/或C”是指包含A、B、C三者中任1个或任2个或3个。

应当理解，在本发明中，“与A对应的B”、“与A相对应的B”、“A与B相对应”或者“B与A相对应”，表示B与A相关联，根据A可以确定B。根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其他信息确定B。A与B的匹配，是A与B的相似度大于或等于预设的阈值。

取决于语境，如在此所使用的“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

相关词语解释、说明：

Container：特定进程或库文件的资源隔离技术；

cgroup-Linux：资源隔离技术的实现，为container的背景技术；

memory leak：内存泄漏，使用完毕的内存未释放或是遗失释放途径；

slub cache-Linux：高速缓存机制，实现数据结构内存的快速分配与释放；

page cache-Linux：文件***缓存，用内存页当缓存增加io效率；

free page：未被分配的内存空闲页；

live patching-Linux：内核动态修正技术，允许不重启机器修正内核代码；

debugfs：一种用于内核调试的虚拟文件***；

user space-Linux：用户态地址空间；

kernel space-Linux：内核态地址空间。

本发明提供一种适用于Linux生产环境的数据结构修复装置，其适用于包括但不限于以下两种在生产环境下遇到的场景。

场景1：Container(特定进程或库文件的资源隔离技术)在异常关闭的情况下造成memory leak(内存泄露)的情况。

container利用Linux kernel的cgroup技术实现container间的资源隔离，cgroup是阶层式架构，彼此间存在父子关系，程序在cgroup内使用slub cache，也会继承这种父子关系，如图1所示，有root cgroup,cgroup A与cgorup B，A和B是root的子cgroup，创建出来的slub cache会加入到root slub cache数据结构的kmem_cache数组下，以及加入到slab_caches全局串列中，这个串列联系著整个***的slub cache。

考虑cgroup下slub cache释放流程，如图2所示，正常container关闭时，会结束其下的所有进程，释放所有内存，过程中会调用mem_cgroup_css_offline函数，把这个cgroup下的slub cache经由kmem_cache_shrink函数释放，如果slub cache的使用量为0，则调用memcg_kmem_destroy_cache注销。在一个异常的情况下，例如有些slub cache仍在使用中，slub cache使用量无法归零，则会使这个slub cache无法注销，但是这个cgroup已经不存在，slub cache也就一直残留在***上，形成内存泄漏。

场景2：由于存储设备问题造成的page_lock

Linux文件***利用page cache机制先把文件内容加载到内存中，不同应用如果读取同一个文件，会从page cache直接读出，避免频繁访问底层存储设备以达到加速的效果，如图3所示，应用发起读操作，如果该文件没有page cache，会先取得一个free page并且调用lock_page函数锁住这个page(即置位PG_locked)，为的是要确保page不被改动或回收，也代表数据还没真正从磁盘读入这个page，所以禁止访问。随后向块设备层提交io请求(submit_bio)，块设备层会以最有效率的方式对io请求做合并与排序(io scheduler)，然后交由设备驱动实际对存储设备进行读操作。读取完成后设备对CPU发起中断，进入io完成调用栈(bio_endio)，然后unlock_page解锁这个page，代表这个page已经读取完成，可以进行其他操作。从上述io流程可以看到，lock_page在应用的调用链上，unlock_page则由中断发起，是一种非同步机制，如果存储设备有问题(坏盘、存储网络不稳)导致无法完成读取，就可能发生page一直处于lock状态，此时如果其他进程想要对该page操作，例如卸载文件***，就会因为一直等不到该page unlock而卡住，这也是问题的表象。

本发明提供对以上两种情况的修复方式包括：

场景1，遍历所有cgroup下的slab cache，找出用量为0且所属的cgroup已被删除的，调用memcg_kmem_destroy_cache注销。

场景2，遍历page wait table，找到处于等待状态的的进程数据结构，从其等待的locked page能找出属于哪个存储设备，用来后续排查存储设备问题。

上述2种场景存在一个共同的现象，即需要在数量庞大的基础数据结构中找出有问题的数据结构。Linux对于这些基础数据结构通常会以串列或数组的方式管理，我们可以从遍历这些数据结构，识别有问题的数据结构后加以修正，或导出有用的信息。我们把这种想法以一种可扩展的模块架构来实现，包含遍历的对象，遍历的方式以及对遍历的对象的操作，如图4所示，由四个部份构成，并以上面两种场景为例演示如何应用。

1.main debugger module，以debugfs(DebugFS,顾名思义,是一种用于内核调试的虚拟文件***,内核开发者通过debugfs和用户空间交换数据)作为与user space(Linux用户态地址空间)交互的管道，允许command module注册command，也允许debugger script(调试程序脚本)查询或下发command指令

2.command module，command module为遍历数据结构的具体实现，并在得到每一个数据结构后作为参数调用action module注册的回调函数，以决定对每个数据结构的具体处理方式。command module本身会向main debugger module注册为一个命令，一个命令可以有多种option，例如场景一的命令的option 1为遍历所有slab caches，option 2为只遍历cgroup下的slab cache，而场景二的命令只有option 1为iter page wait table。

3.action module，action module实现遍历过程中的每个数据结构的具体处理方式，例如场景一对于每个slab cache，对应的action为找出用量为0且所属的cgroup已被删除的这些slab cache，调用注销函数注销。场景二则需要遍历page wait table，从处于等待状态的的进程数据结构找到被lock的page，再从page推导出属于哪个存储设备。

4.debugger script，应用层工具，可用来查询已注册的command或下发command。

利用这种架构，我们清楚的把控制腳本、模块主体、遍历方法与操作行为解耦，方便扩展，也能只提供几个特定模块用于解决特定问题，例如解决场景一的问题只需要提供图4的debugger.ko,iter_slab.ko,iter_slab_action.ko以及用户态的debugger_script.sh脚本，其他与此问题无关的模块则不须提供，加载這些ko模块後，利用debugger_script.sh下发command，例如要排除场景一的内存泄漏问题，则用debugger_script.sh下发[cmd2,option2],就会调用到iterate cgroup slab caches命令遍历所有cgroup slabcaches，所对应的action为判断传过来的slab cache用量是否为0，所属的cgroup是否存在，如过都存在则调用注销函数注销。如此一来整个***遍历过后，***存就能得到释放，生产环境就能恢复正常使用状态。

本发明提出的方法在运行在生产环境前需要充分验证，以避免所作的操作反而让环境更不稳定，环境修复后也需要卸载掉command和action模块，避免误触发。

本发明提供一种适用于Linux生产环境的数据结构修复方法，如图5所示其流程图，包括：

步骤S10、与Linux用户态地址空间(user space)建立交互通道，基于所述交互通道向所述Linux用户态地址空间(user space)发送和\或建立指令；

步骤S20、基于指令遍历内核空间处的数据结构，获取每一个数据结构后作为参数调用先前action module注册的回调函数，基于所述回调函数确定每个数据结构的具体处理方式；

步骤S30、基于所述具体处理方式对所述数据结构进行处理。

还包括步骤S40、基于所述交互通道查询已注册和\或已建立的指令(command)。

在步骤S20中，包括：

S201、预先注册一个指令，其中所述指令中包含有遍历数据信息，所述遍历数据信息与待处理问题对应设置；其中数据信息以及对应的目标问题包括场景1和场景2中的slubcache相关数据和page cache相关数据。

S202、基于所述指令遍历对应的内核数据后，进行修复处理。

在步骤S30中，包括：

S301、基于所述具体处理方式对所述数据结构进行处理包括：

S302、获取每个所有缓存中用量为0且所属的cgroup已被删除的这些缓存，调用回调函数进行注销。

本发明还提供一种适用于Linux生产环境的数据结构修复装置，如图6所示，包括：

主交互模块(main debugger module)，用于使内核空间与Linux用户空间(userspace)建立交互通道，Linux用户空间基于所述交互通道向所述内核空间发送和\或建立指令(command)；

命令调用模块(command module)，用于基于指令遍历内核空间处的数据结构，获取每一个数据结构后作为参数调用action module处先前注册的回调函数，基于所述回调函数确定每个数据结构的具体处理方式；

处理模块(action module)，用于基于所述具体处理方式对所述数据结构进行处理。

进一步的，还包括应用层工具模块(debugger script)，用于基于所述交互通道查询已注册和\或已建立的指令。

进一步的，所述基于指令遍历内核空间处的数据结构包括：

基于所述指令遍历对应的内核数据后，进行修复处理。

进一步的，基于所述具体处理方式对所述数据结构进行处理包括：

其中，可读存储介质可以是计算机存储介质，也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如，可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(ApplicationSpecific Integrated Circuits，简称：ASIC)中。另外，该ASIC可以位于用户设备中。当然，处理器和可读存储介质也可以作为分立组件存在于通信设备中。可读存储介质可以是只读存储器(ROM)、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本发明还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得设备实施上述的各种实施方式提供的方法。

在上述终端或者服务器的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

1.一种适用于Linux生产环境的数据结构修复方法，其特征在于，包括：

基于所述具体处理方式对所述数据结构进行处理；

基于所述具体处理方式对所述数据结构进行处理包括：

获取每个所有缓存中用量为0且所属的cgroup已被删除的这些缓存，调用回调函数进行注销；或者，获取处于等待状态的的进程数据结构，从等待的locked page找出所属存储设备，用来后续排查存储设备问题。

2.根据权利要求1所述的数据结构修复方法，其特征在于，

还包括：

基于所述交互通道查询已注册和\或已建立的指令。

3.根据权利要求1所述的数据结构修复方法，其特征在于，

所述基于指令遍历内核空间处的数据结构包括：

基于所述指令遍历对应的内核数据后，进行修复处理。

4.一种适用于Linux生产环境的数据结构修复装置，其特征在于，包括：

处理模块，用于基于所述具体处理方式对所述数据结构进行处理；

基于所述具体处理方式对所述数据结构进行处理包括：

5.根据权利要求4所述的数据结构修复装置，其特征在于，

还包括应用层工具模块，用于基于所述交互通道查询已注册和\或已建立的指令。

6.根据权利要求4所述的数据结构修复装置，其特征在于，

所述基于指令遍历内核空间处的数据结构包括：

基于所述指令遍历对应的内核数据后，进行修复处理。

7.一种电子设备，其特征在于，所述电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行权利要求1-3任意一项所述的方法。

8.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时用于实现权利要求1至3任一所述的方法。