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 --volfile-id=/tank --volfile-server=lab21 /mnt/dzq

root     10093  0.0  0.6 232236 53316 ?        Ssl  17:19   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/52fcb2d9e219d2dee4f280489ef3c9d4.socket

root     10097  0.0  0.2 321604 20108 ?        Ssl  17:19   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/dda19e05b0f00927c31e8b28c8a07f08.socket --xlator-option *replicate*.node-uuid=2e830972-f2d2-4da9-8a03-e11e49cfc39e

当设置cache-size=2GB时,客户端的如下进程会开辟对应大小的物理内存空间:

11193 root      20   0 2346m 2.0g 2744 S  0.0 26.6   1:39.68 /usr/sbin/glusterfs --volfile-id=/tank --volfile-server=lab21 /mnt/dzq

实际情况下,客户端只有一个进程,上面的其他进行是因为glusterd服务未关闭产生的:

/usr/sbin/glusterfs --volfile-id=/tank --volfile-server=lab21 /mnt/dzq

时间: 2024-10-04 05:31:24

GlusterFS客户端进程分析的相关文章

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 /v

windows客户端崩溃分析和调试

本文介绍windows上崩溃分析的一些手段,顺便提多进程调试.死锁等. 1.崩溃分析过程 1.1 确认错误码 无论是用windbg还是用vs,首先应该注意的是错误码,而90%以上的崩溃都是非法访问. 在非法访问时,可以看一下访问的目标地址.地址是0,或者离0很近(0x00000008或0xfffffffc), 一般和空指针相关.如果是一个貌似正常的地址,一般是对象已析构后访问其数据,或者堆破坏. 1.2确认崩溃对应的C++操作 什么是确认崩溃对应的C++操作: 比如非法访问,通常得有个mov指令

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

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

进程分析之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

Charles——charles 工具栏Tools总结——客户端进程工具/client_process

客户端进程工具/client_process 显示使每个请求的本地客户端进程; 客户端进程工具显示负责进行每个请求的本地客户端进程的名称. 客户端进程通常是您的Web浏览器,例如firefox.exe,但客户端进程工具可以帮助您发现许多可能未知的HTTP客户端. 客户端进程名称显示在每个请求的“备注”区域中. 如果您可以在Charles中看到您不确定起始过程的请求,则客户端进程工具很有用. 它仅适用于在运行Charles的计算机上发出的请求. 该工具将在Charles接受每个连接之前引入一个短暂

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

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

Week2 Bing词典Android客户端案例分析

一.软件调研 运行平台:Android 4.4.4 必应版本:5.2.2 1.bug发现 1.1 bug标题:单词挑战无法加载和刷新 bug详细描述:学习界面中的单词挑战模块,点击后没有任何反映,并且点击刷新也一直显示“加载失败,请稍候重试” bug严重程度:一般 bug优先级:重要不紧急 bug类型:内容相关 2.采访软件用户了解软件 用户背景:北航计算机学院大三学生 学英语的目的:准备出国的相关语言考试 用户使用软件的照片: 数据量:单词数据量充足,能够满足使用 界面:界面简洁易用 功能:功

Linux内核的idle进程分析

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