GlusterFS服务器端进程分析

服务端进程信息:

root       348  0.0  0.2 273104 16268 ?        Ssl  17:31   0:00 /usr/sbin/glusterd --pid-file=/run/glusterd.pid

root       401  0.0  0.6 308532 52700 ?        Ssl  17:31   0:00 /usr/sbin/glusterfs -s localhost --volfile-id gluster/nfs -p /var/lib/glusterd/nfs/run/nfs.pid -l /var/log/glusterfs/nfs.log -S /var/run/bdec9c41dda184769df21998432b9bf2.socket

root       417  0.0  0.2 323660 23612 ?        Ssl  17:31   0:00 /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p /var/lib/glusterd/glustershd/run/glustershd.pid -l /var/log/glusterfs/glustershd.log -S /var/run/510a9fdbe684d9518726048e1b21a40d.socket --xlator-option *replicate*.node-uuid=f22b60d6-ff4d-4247-bdda-0a4fe0223384

root     32756  0.9  0.2 548512 22132 ?        Ssl  17:30   0:07 /usr/sbin/glusterfsd -s lab22 --volfile-id tank.lab22.letv-disk3 -p /var/lib/glusterd/vols/tank/run/lab22-letv-disk3.pid -S /var/run/a71a75abe47e437d55b915773b3b4f5c.socket --brick-name /letv/disk3 -l /var/log/glusterfs/bricks/letv-disk3.log --xlator-option *-posix.glusterd-uuid=f22b60d6-ff4d-4247-bdda-0a4fe0223384 --brick-port 49155 --xlator-option tank-server.listen-port=49155

服务端重启glusterd服务,如下进程PID变不。

root     24082  2.0  0.3 548508 24752 ?        Ssl  17:46   0:05 /usr/sbin/glusterfsd -s lab21 --volfile-id tank.lab21.letv-disk3 -p /var/lib/glusterd/vols/tank/run/lab21-letv-disk3.pid -S /var/run/5e33431834617265b46d9dc89cdb2e53.socket --brick-name /letv/disk3 -l /var/log/glusterfs/bricks/letv-disk3.log --xlator-option *-posix.glusterd-uuid=0d5ba4a3-c6fa-4afd-ad39-a2842ca3cde0 --brick-port 49176 --xlator-option tank-server.listen-port=49176

其他3个进程PID会变,生产新的进程。

当服务器端执行gluster volume stop操作后,上述进程消失,gluster volume start后会创建新的线程。

时间: 2024-10-25 18:48:54

GlusterFS服务器端进程分析的相关文章

GlusterFS客户端进程分析

客户端重新挂载gluster卷时,进程变化如下: 该进程PID不会变化: 16683 root      20   0  398m  16m 2796 S  0.0  0.2   2:31.58 /usr/sbin/glusterd --pid-file=/run/glusterd.pid 以下进程PID会变,重新生成: root     10068  7.9  0.4 302108 39204 ?        Ssl  17:19   0:40 /usr/sbin/glusterfs --v

进程分析之CPU

进程分析之CPU 本文转载自:https://github.com/ColZer/DigAndBuried/blob/master/system/cpu.md 在<进程分析之内存>文中,对系统/进程的内存使用情况进行分析了,本文将从cpu使用情况对进程进行分析:在这之前,先针对cpu比较相关几个概念进行介绍 CPU INFO的阅读以及对基本概念的了解: cpu从硬件到系统层面有三个概念:物理CPU个数.物理核数.逻辑核个数:其中物理CPU的个数即硬件层面实实在在的CPU的个数:现在CPU都为多

Android源码分析--system_server进程分析

在上一篇博文中我们进行了有关Zygote进程的分析,我们知道Zygote进程创建了一个重要的进程–system_server进程后就进入了无限循环中,之后Android系统中的重要任务就交给了system_server进程,作为zygote的嫡长子进程,system_server进程的意义非凡,今天我们来分析一下system_server进程. 创建system_server进程 在ZygoteInit中main方法中,通过调用startSystemServer方法开启了system_serve

构建根文件系统之init进程分析

busybox是ls.cp等命令的集合. 执行ls时,实际上是执行了busybox ls 执行cp时,实际上是执行了busybox cp 分析init程序之前,再让我们回想一下我们的目标:u-boot启动内核,内核启动应用程序,内核是怎样启动应用程序呢,内核启动了init进程,位于/sbin/init中.我们最终的目的是启动客户程序,也就是说假如你是做手机的,希望启动一个手机的程序,假如是做监控的,那么就启动一个监控的程序的.客户各有不同,但都使用了linux系统,那么怎样加以区分呢? init

Linux内核的idle进程分析

1. idle是什么 简单的说idle是一个进程,其pid号为 0.其前身是系统创建的第一个进程.也是唯一一个没有通过fork()产生的进程. 在smp系统中,每一个处理器单元有独立的一个执行队列,而每一个执行队列上又有一个idle进程,即有多少处理器单元.就有多少idle进程. 系统的空暇时间,事实上就是指idle进程的"执行时间".既然是idle是进程.那我们来看看idle是怎样被创建,又详细做了哪些事情? 2. idle的创建 我们知道系统是从BIOS加电自检,载入MBR中的引导

Linux0.11内核--fork进程分析

[版权所有,转载请注明出处.出处:http://www.cnblogs.com/joey-hua/p/5597818.html ] 据说安卓应用里通过fork子进程的方式可以防止应用被杀,大概原理就是子进程被杀会向父进程发送信号什么的,就不深究了. 首先fork()函数它是一个系统调用,在sys.h中: extern int sys_fork (); // 创建进程. (kernel/system_call.s, 208) // 系统调用函数指针表.用于系统调用中断处理程序(int 0x80),

Android源码分析--Zygote进程分析

众所周知,Android系统中存在着两个完全不同的世界: 1. Java世界,Google所提供的SDK就主要是针对这个世界的,在这个世界中运行的程序都是基于Dalvik虚拟机的Java程序. 2. native世界,也就是利用C或C++语言开发的程序. 那么问题来了,Android系统具体是如何将这两个世界联系起来的,这就是关系到本篇博文所讲的Zygote进程.Android是基于Linux内核构建的,这样Android最早进入的也就是native世界.Linux系统启动的第一个进程是init

linux用户进程分析

       经过实验3的介绍,我们需要来点实在的,所以将我们理解的流程用于linux系统的分析.换句话说,通过类比的方式去进行描述与理解linux相关的部分.本节的内容很详实,而且也分析了很久,所以长话短说,静静的去感受与理解linux内核代码的实现.当然,我们实验的系统代码很简单而且直接,但是linux内核经过20多年的发展,更有成千上万的开发者共同维护,所以对于代码的书写会更加精练,对于基础相对薄弱的程序员去理解有一些障碍,但是反过来说,更有利于我们语言知识的提高. 如下的介绍方法是对

GlusterFS源码解析 —— GlusterFS 结构体系分析

简述 经过这几天对Glusterfs的分析, 对其体系结构已经有了初步的理解. 值得庆贺的一点就是  Glusterfs 的整个体系结构非常清晰, 高度模块化的设计使得我们对他的理解和扩展变得比较容易. 我打算从下面几步来分析其体系结构: 1. 给出几个从网络上收集的结构图, 用以帮助我们来从整理上认识其体系结构. 2. 以 Glusterfs 的一个客户端配置文件入手, 来理解配置文件的同时也进一步来理解其体系结构. 上面的两项都是基于宏观方面的分析, 下面我们将从系统的微观方面来理解其相关的