背景: pgsql连接时候报错org.postgresql.util.PSQLException: FATAL: sorry, too many clients already, 意思是client已经把连接池占满了. 使用ps -ef | grep postgres删除几个进程, 进入数据库运行SELECT * FROM pg_stat_activity, 发现大部分都是idle空闲状态的连接 然后修改/var/lib/pgsql/14/data/postgres.conf中的idle_ses

Hadoop yarn 加密采矿僵尸网路病毒还在继续蔓延! 解决步骤 如果你同样遇到了kdevtmpfsi异常进程,占用了非常高的CPU和出网带宽,影响到了你的正常业务,建议使用以下步骤解决 杀掉异常进程 ps -ef|grep kdevtmpfsi(异常进程) kill -9 pid 杀掉守护进程 杀掉kdevtmpfsi进程后,随后进程还会重启,还要杀掉守护进程 kinsing ps -ef|grep kinsing kill -9 pid 删除异常crontab任务 当你杀掉守护进程,以为

突然发现公司测试服务器CPU过高,是这两个sysupdate, networkservice进程,很明显是被挖矿了,记录下来以供参考. 病毒会把一些文件给加i锁或a锁,导致无法修改数据,所以某些操作需要清除锁 这个是kdevtmpfsi的守护进程,把它kill掉,然后kill掉kdevtmpfsi,然后删文件. ps -aux | grep kinsing [root@localhost tmp]# ps -aux | grep kinsing root 11459 0.0 0.0 112812

问题定位及排查 上周无意中调试程序在Linux上ps -ef|grep tomcat发现有许多tomcat的进程,当时因为没有影响系统运行就没当回事.而且我内心总觉得这可能是tomcat像nginx一样启动多个进程. 后来测试在一次升级后反馈说怎么现在tomcat进程无法shutdown?这让我有点意外,看来这个问题并没有这么简单.于是开始思考问题会出在哪里. 复现问题 先是另外一台服务器部署,然后shutdown后再ps进程是空的,这说明tomcat不会自动产生新的进程.那就有可能系统代码出了

背景 mysql可以支持多种不同的存储引擎,innodb由于其高效的读写性能,并且支持事务特性,使得它成为mysql存储引擎的代名词,使用非常广泛.随着SSD逐渐普及,硬件存储成本越来越高,面向写优化的rocksdb引擎逐渐流行起来,我们也是看中了rocksdb引擎在写放大和空间放大的优势,将其引入到mysql体系.两种引擎的结构B-Tree(innodb引擎)和LSM-Tree(rocksdb引擎)很好地形成互补,我们可以根据业务类型来选择合适的存储.一般mysql默认是mysql+innod

一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环. 以我们最近出现的一个实际故障为例,介绍怎么定位和解决这类问题. 根据top命令,发现PID为28555的Java进程占用CPU高达200%,出现故障. 通过ps aux | grep PID命令,可以进一步确定是tomcat进程出现了问题.但是,怎么定位到具体线程或者代码呢? 首先显示线程列表: ps -mp pid -o THREAD,tid,time 找到了耗时最高的线程28802,占用CPU时间快两个小时了!

这篇文章是写给自己的. 周三的时候我在维护公司的一个wordpress项目页面时发现了一个非常奇怪的情况:当我尝试更新网站上的一个页面后,在wordpress后台的编辑器中发现其内容并没有按我预期的将图片的网址替换下来(网站开启了百度云插件,插件会抓取文章中的图片,然后将图片上传至百度云,并将文章中的地址替换),但是,我查看前台的页面却发现页面显示时正常的.检查页面中的图片网址也是做过替换的,总之一句话,就是前台文章展示页和后台编辑器中的内容不一致.这个bug真诡异,下面就把排查这个bug的过程

AG排查和监控指南 1. 排查场景 如下表包含了常用排查的场景.根据被分为几个场景类型,比如Configuration,client connectivity,failover和performance. Scenario 笔记 Scenario Type Description Troubleshoot AlwaysOn Availability Groups Configuration (SQL Server) 排查:AG配置 Configuration 提供了一些典型的配置AG实例发生问题的

1.问题背景      默认情况下,线上的mysql复制都是异步复制,因此在极端情况下,主备切换时,会有一定的概率备库比主库数据少,因此切换后,我们会通过工具进行回滚回补,确保数据不丢失.半同步复制则要求主库执行每一个事务,都要求至少一个备库成功接收后,才真正执行完成,因此可以保持主备库的强一致性.为了确保主备库数据强一致,减少数据丢失,尝试在生产环境中开启mysql的复制的半同步(semi-sync)特性.实际操作过程中,发现大部分实例半同步都可以正常运行,但有少部分实例始终开不起来(只能以普

前言 很多时候数据库的TempDB.日志等文件的暴增可能导致磁盘空间被占满,如果日常配置不到位,往往会导致数据库故障,业务被迫中断. 这种文件暴增很难排查,经验不足的一些运维人员可能更是无法排查具体原因,导致问题不能彻底解决. 场景描述 客户系统比较稳定,用了5台机器做了AlwaysOn高可用组,完全实现了读写分离.磁盘也做了规划,主库日常操作TempDB需求在20G以下,所以TempDB所在的磁盘只配置了100个G的空间. 本案例是客户突然接到监控报警,显示TempDB磁盘空间不足,可用空间不

今天一个待上线服务测试完毕,需要构建CI,按照模板配置好包还原,xbuild编译,报错,错误信息如下: EtcdRegister.cs(8,15): error CS0234: The type or namespace name `LawDissector' does not exist in the namespace `Gridsum'. Are you missing an assembly reference? EtcdRegister.cs(14,20): error CS0246:

公司在kubernetes集群上稳定运行数月的kibana服务于昨天下午突然无法正常提供服务,访问kibana地址后提示如下信息: 排查过程: 看到提示后,第一反应肯定是检查elasticsearch集群,碰巧昨天下午公司VPN奇慢,频繁连接不上亦庄机房,因此问题排查一度集中在elasticsearch服务上,另一方面也是因为kibana服务由docker镜像提供,只读服务本身是没有状态变化的,在kubernetes集群中查看pod状态,也没有崩溃重启的记录,因此只能怀疑是连接的elastics

今天在测试基于etcd的分布式锁过程中,在测试获取锁后,释放之前超出TTL时长的情况下自动延长TTL这部分功能,在延长指定key的TTL时总是返回404错误信息,在对目标KEY更新TTL时目标KEY已不存在. 最终问题排查为ETCD集群3个节点之间的系统时间不一致,因为TTL延长是在KEY创建后单独一个监听线程中进行,在TTL过半之后会更新TTL,因此可能出现更新TTL之前,由于集群中时间超前的节点将目标KEY删除,导致更新TTL时找不到目标KEY的错误. 同步集群所有节点系统时间后问题排除:

系统级别perf top, dstat -tam, vtune 都能很好分析beam 瓶颈,本文主要erlang 级别排查: 1. 反编译 确认线上运行代码是否正确,reltools没掌握好,升级偶尔出现问题 decompile(Mod) -> {ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(code:which(Mod), [abstract_code]), io:format("~s~n", [erl_prettypr:

前些天发现:http://hellojava.info/这个站点,关于java问题排查分析总结线上故障总结其实是最有价值的,好的总结就是一个系统演进历史,是团队难得的积累沉淀. 花了不少时间看了下,顺手整理了笔记: 1. Hashmap 并发情况下未加锁导致OOM 嗯,死循环很常见,OOM也会有,序列化时 HashMap.writeObject 一直执行生成巨大的数组. 2. Direct Bytebuffer     大小有限制,默认配置大小为:-Xmx,必要通过-XX:MaxDirectMe

新服务上线后观察到,CPU在10 ~ 70%间波动严重,但从每秒业务计数器看业务处理速度很平均. 接下来是排查步骤: 1. dstat -tam 大概每10s一个周期,网络流量开始变得很小,随后突然增大,CPU也激增. 网络流量变化和从性能计数器结果上并不符合,服务相关业务较为复杂,先找出那个业务占用网络流量. 2. iftop 找出流量最大的几个目标IP,并且周期的流量变为0随后激增. 通过IP 知道是外部http接口地址,因为接口调用是异步进行的,性能计算是执行开始记录的,而不是结束记录,因

一.概述: 在实际使用hadoop的过程中,由于涉及到多台服务器.每台机器上可能还有多个服务等.所以当集群环境出现问题时,快速定位到错误出现的地方尤为重要. 在排查错误的过程中,基本上就是通过既有的工具来检测集群的运行时环境.集群日志等来分析导致错误的原因. 二.Java heap: hadoop需要运行在Java运行时环境之上.因此jvm中的内存分配是否处于合理的状态,就是需要检测的一个因素.Java虚拟机中分为多个区域,最值得关注的区域是heap区.heap区的大体划分如下: 创建对象时,会

 阅读目录: 性能相关的数据指标 内存使用率used_memory 命令处理总数total_commands_processed 延迟时间 内存碎片率 回收key 总结 性能相关的数据指标 通过Redis-cli命令行界面访问到Redis服务器,然后使用info命令获取所有与Redis服务相关的信息.通过这些信息来分析文章后面提到的一些性能指标. info命令输出的数据可分为10个类别,分别是: server clients memory persistence stats replicatio

前段时间 出现过这个问题,: 表中有一列为number类型 rec_recordlength (两个时间的间隔长度/秒) 部分数据 统计这个字段就会出现 "算出运算溢出" 错误,很是头疼,找不出原因 然后 今天又出现了, 然后不断排查,排查,发现是有一条数据导致的, 后来 这条数据删除重新插入就好了, 然后想到唯一动过这条数据的,是执行了rec_recordlength的更新,动作如下: *(rec_endtime-rec_starttime) where rec_c_id='1785

排查AG配置 本文主要用来帮助排查在AG配置时出现的问题,包括,AG功能被禁用,账号配置不正确,数据库镜像endpoint不存在,endpoint不能访问. Section Description AlwaysOn Availability Groups Is Not Enabled 如果实例没有启动AG特性,实例就不支持任何AG相关的功能 Accounts 在SQL Server在运行的情况下,正确的账号配置 Endpoints 诊断关于实例的镜像endpoint问题. System name

排查:AG超过RTO 自动故障转移或者手动转移之后,没有数据都是,你可能会发现切换时间超过了你的RTO.或者当你评估切换时间同步提交secondary副本,发现超过了你的RTO. 1. 通常原因 通常引起故障转移超过RTO的原因: 1.报表负荷堵塞了Redo线程. 2.因为资源争用,Redo线程被落下. 2. 报表负荷堵塞了Redo线程 Redo线程在secondary副本被一个只读长运行语句堵塞. 原因: 在secondary副本,只读查询获得Sch-s锁,这些sch-s锁会堵塞redo线程获