NFS使用RPC来进行客户端和服务器之间的通信。而在RPC的底层，NFS使用TCP来进行数据的可靠传输，以便客户端和服务器之间能够有效地传输文件和进行远程调用（默认为TCP,也可调整为udp）1.首先服务器端启动RPC服务portmap，并开启portmap的111端口。2.服务器端启动NFS服务，并向RPC注册端口信息。3.客户端启动RPC（portmap服务），向服务端的RPC(portmap)服务请求服务端的NFS端口。4.服务端的RPC(portmap)服务反馈NFS端口信息给客户端。5.客户端通过获取的NFS端口来建立和服务端的NFS连接并进行数据的传输(网络传输基于TCP)。当客户
数据库连接数超了，导致数据库连接不上，如何排查当前连接数，以及如何修改最大连接数限制？1.对比当前连接数和最大连接数如果差的比较少，比如相差十几，二十几，连不上的话，很有可能是用连接池连接，一次申请连接数大于剩余的连接数导致的。#查看当前总连接数SELECTcount(*)FROMV$session;#查看数据库设置的最大连接数,process的值即为最大连接数SELECT*fromV$PARAMETERWHERENAMELIKE'%process%';#这条sql服务端和客户端都能执行；showparameterprocess;#这条命令只能在服务端执行2.分组查看每个用户的连接数情况如果是
1、线上边端环境Java服务部署在边端，docker老是重启先看几个常用的docker指令1.1journalctl-udocker--since=2023-09-15【查看docker守护进程日志】命令用于查看Docker服务的日志。该命令使用journalctl工具来访问系统的日志消息，特别是与Docker相关的日志，从哪一天日志看起，since后面跟着的是具体日期。1.2dockerevents--since=1694707200000【查看docker的事件日志】dockerevents命令用于监听Docker守护进程产生的实时事件。从哪一天日志看起，since后面跟着的是unix时间
相信很多朋友曾经都遇到过这个问题，最近也是被这个错误折磨的怀疑人生。在执行HiveSQL的时候总是时不时报错，couldnotfindstatusofjob然后进入yarn的日志里面，发现具体的错误为Noroutetohost其实这个错误首先看起来是很明确的，没有主机的路由，经过网上查询，总结起来有这么3个原因：1、对方的域名确实不通2、本机开了防火墙3、etc/hosts里面没有配置本机的机器名和ip但是很显然，这都是一些比较低级的错误，简单排查一下并不是这些原因。其实这个问题以前也发生过，但是发生的频率是极其低的，导致不能复现，二是也没有太好的办法，就单单一个Noroutetohost有点
内存马检测排查手段前言内存马是无文件落地webshell中最常见的攻击手段，随着攻防演练对抗强度越来越高，流量分析、EDR等专业安全设备被蓝方广泛使用，传统的文件上传的webshll以及文件形式的后门容易被检测到，文件shell明显气数已尽，而内存马因其隐蔽性等优点从而越来越盛行。由客户端发起的Web请求后，中间件的各个独立的组件如Listener、Filter、Servlet等组件会在请求过程中做监听、判断、过滤等操作，内存马就是利用请求过程在内存中修改已有的组件或动态注册一个新的组件，插入恶意的shellcode，达到持久化控制服务器的目的。内存马可以通过访问存在漏洞的url加上命令执行参
NO.1产生问题在我们学习中使用到sysdate这个函数时，发现查出来的日期时间与当前的正确时间不一致，相差8个小时左右，为什么会产生这个问题？又该如何解决？–在数据库中使用sysdate()函数查询系统时间selectsysdate();结果显示：NO.2原因分析原因分析1：第一时间想到的是数据库所在的云服务器时间可能与网络时间不同步，因为数据库是装在云服务器上的，但是这种可能性应该较小，因为购买的阿里云服务器应该不会存在这种问题，一般会自动校对时间。于是先确定云服务器的时间，输入date命令查看云服务器系统时间，结果云服务器显示的时间是正确的，如下图：原因分析2：排除第一种可能后，又想到M
1.出现内存泄漏1.1事发现场在风和日丽的一天，本人正看着需求、敲着代码，展望美好的未来。突然收到一条内存使用率过高的告警。1.2证人证词告警的这个项目，老代码是python的，最近一直在go化。随着go化率不断上升，发现内存的RSS使用率越飙越高。最终达到容器内存限制后，进程会自动重启。RSS如下图所示：2.排查内存泄露2.1分析问题看到这种不正常的RSS增长，第一反应是：是不是最近上的代码有什么问题？是不是发生了内存泄露？内存泄露可是大事，赶紧查查。于是将时间线拉长，看看是从哪天开始的。结果，现实是很残酷的。从项目刚上线的时候就有这个问题了。由于项目是2周一个版本，以前是还没达到内存限制，
背景环境是CentOS7操作系统，nacos服务宕掉了，启动服务的时候报错。Causedby:org.springframework.beans.BeanInstantiationException:Failedtoinstantiate[org.springframework.boot.web.servlet.FilterRegistrationBean]:Factorymethod‘distroFilterRegistration’threwexception;nestedexceptionisorg.springframework.beans.factory.UnsatisfiedDep
Docker是一种相对使用较简单的容器，我们可以通过以下几种方式获取信息：1、通过dockerrun执行命令，查看返回信息2、通过dockerlogs去获取日志，做有针对性的筛选3、通过systemctlstatusdocker查看docker服务状态4、通过journalctl-udocker.service查看日志以下是整理的docker容器类问题故障，分为9个类一、启动类故障1、docker:CannotconnecttotheDockerdaemonatunix:///var/run/docker.sock.Isthedockerdaemonrunning?原因：Docker未正常启动
Redis阻塞原因以及问题排查尽管我们在日常工作中经常使用Redis作为数据库的缓存，以大大减轻数据库压力并提升用户体验，但Redis也可能出现阻塞情况，导致整个系统变慢，进而影响用户体验。因此，在面对Redis阻塞的情况下，我们可以从以下七个方面进行全面的分析，以确定造成Redis阻塞的具体原因。慢查询因为Redis是单线程的，所以如果出现大量的慢查询，可能会导致redis-server阻塞，可以通过slowloggetn获取慢日志查看详细情况，如下所示。>slowlogget334168863009914659LPOPAutomatic:Plan:wait:RestoreList192.1
