首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    测试环境服务器硬盘塞满问题排查

    某天下午测试环境服务器出现tab无法补全命令,给出的提示大概意思就是说,无可用空间无法创建临时文件,不过这次跟上次出现的问题比较像,上次服务器出现的问题,因此楼主判断可能是服务器数据盘被占满,果不其然,...使用df -h命令看到服务器数据盘出现100%被占用的情况。...问题排查过程 楼主首先想到的是可以看到,linux系统中占用数据盘最大的文件,常情况下,最有可能找出占用磁盘空间文件或文件夹的地方,主要是 /tmp or /var or /home or /。...如果需要输出可读性更高的内容,请使用如下命令: du -hsx * | sort -rh | head -10 ok,到此为止问题华华丽丽的解决了,很开心哦。...一般情况下查看某一端口的占用情况的用法是: lsof -i:端口号 例如查看80端口的使用情况 lsof -i:80 COMMAND PID USER FD TYPE DEVICE SIZE

    55610

    死锁问题排查

    既然已知道异常服务,那可以从这里入手进行分析,又与同事沟通一番,确定了与该服务相关的一些后台模块,接下来重点排查这些模块。...首先通过pprof抓取了这些模块的堆栈日志,Go提供了net/http/pprof和runtime/pprof两个包用于性能测评分析,前者通常用于web服务器的性能分析,后者通常用于普通代码的性能分析。...下面是出现问题的参考日志,关键点已包含其中,因为原日志不方便展示。 排查方法 日志中出现了sync....问题本质 上面问题的根因是死锁导致的,死锁也是计算机中常见出现的问题。...codereview 通过代码评审,有经验的工程师对代码进行review之后,一些比较明显的存在死锁代码逻辑是容易发现的,当然有些逻辑隐藏的比较深,一般很难发现。

    1K10

    linux服务器性能问题相关排查手册(总结向)

    如果单块磁盘的队列长度持续超过2,一般认为该磁盘存在I/O性能问题。...出现此种情况,很可能是系统中存在大量进程处于D的状态,也就是不可中断的睡眠状态,这一般是由于硬件问题导致的。...$2}' |xargs top -b -n1 -Hp | grep COMMAND -A1 | tail -n 1 | awk '{print $1}' | xargs printf 0x%x IO问题排查思路...注意:如果服务器中正在运行业务进程,kill 会直接终止进程,请慎重操作。 重启实例。重启实例系统会退出现有的进程,开机后重新加载,过程中会释放调用的 deleted 文件的句柄。...查看是否有异常内核模块,引用了其他文件,手册rmmod异常模块,查看df是否变化(容易被忽略) 常用性能排查工具介绍 uptime image.png top 实时CPU使用情况和进程信息 image.png

    2.1K21

    Linux 服务器性能出问题排查下这些参数指标

    一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。...CPU 占用率高很多情况下意味着一些东西,这也给服务器 CPU 使用率过高情况下指明了相应地排查思路: 当 user 占用率过高的时候,通常是某些个别的进程占用了大量的 CPU,这时候很容易通过 top...找到该程序;此时如果怀疑程序异常,可以通过 perf 等思路找出热点调用函数来进一步排查; 当 system 占用率过高的时候,如果 IO 操作(包括终端 IO)比较多,可能会造成这部分的 CPU 占用率高...,比如在 file server、database server 等类型的服务器上,否则(比如>20%)很可能有些部分的内核、驱动模块有问题; 当 nice 占用率过高的时候,通常是有意行为,当进程的发起者知道某些进程占用较高的...睡眠的进程数目;swpd 表示使用到的虚拟内存数量,跟 top-Swap-used 的数值是一个含义,而如手册所说,通常情况下 buffers 数目要比 cached Mem 小的多,buffers 一般

    1.9K61

    linux服务器负载问题排查思路以及常用指令总结

    最近在维护公司线上的服务器排查了一些问题,所以做一个总结。有一段时间,线上环境变得很卡,客户端请求很多都报超时,因为线上没有良好的apm监控,所以只能通过流量高峰期和日志去排查问题。...通过排查,发现数据库的慢查询日志在比之间的暴涨了十倍,然后发现,memcache服务器(8核)负载很高,cpu一直在50%的左右,原因就是memcache服务器内存用完,导致内存的淘汰十分频繁,这样就导致很多请求落到数据库...典型问题 java应用出问题一般都是内存和cpu的问题,像cpu飙高,内存不够等是通过这些来发现。...如果是内存问题,则通过gc日志和jmap输出dump文件。 二、磁盘问题 磁盘问题在mysql服务器中非常常见,很多时候mysql服务器的CPU不高但是却出现慢查询日志飙升,就是因为磁盘出现了瓶颈。...三、网络问题 在线上服务器,大部分服务器都是只能内网访问,放在公网的服务器也就那几台nginx和ftp的,另外公网的那些服务器都有流量监控,所以网络问题一般并不大,不再详细说明,推荐一些工具,如果有需要可以对着查下

    3.1K30

    线上服务器出现零星502的问题排查

    我看了下,确实是每次出现502基本都是出现在群发任务调度比较多的情况,但是我在我们日志系统并没有发现成规模的其他报错,另外服务器资源有波动但是也没那么大的波动,因为我们这一般申请服务器资源比较容易,都是做了一定的富余的...这边咨询了下运维侧最近是否有什么变动或者解决方案,运维侧觉得是服务器资源问题,先直接给我们加了一倍的机器 但是观察后发现502少了但是问题还是没解决 1.2 网关两边链接保活时间不一致 我新功能上线的那一天的同时把我们的服务切到了...那么这时候就会产生一个现象:前50秒没有传输内容,在第51秒的时候,浏览器向nginx发了一个请求,这时候ka1还没有断掉,因为没有到100秒的时间,所以这是没有问题的,但是当nginx试图向应用服务器发请求的时候就出问题了...因为ka2的超时设置是50秒,这时候已经超了,所以就断了,这时候nginx无法再从应用服务器获得正确响应,只好返回浏览器502错误! 但是我们根本就没有设置过这些参数啊,怎么会有这种问题呢?...后面观察了几天,发现调整后服务器完全正常了,再也没出现过502; 三 总结 其实这次问题还是比较明显的 1.出现时机是新功能发布上线后 2.502的同时往往伴随着链接数的下降(先是系统充分预热,链接数全部激活了

    1.8K30

    日常问题排查-调用超时日常问题排查-调用超时

    日常问题排查-调用超时 前言 日常Bug排查系列都是一些简单Bug排查,笔者将在这里介绍一些排查Bug的简单技巧,同时顺便积累素材^_^。 Bug现场 这次的Bug是大家喜闻乐见的调用超时。...开始排查 那么这5秒钟时间到底消失在哪里呢?有3个可能的点: 1)A日志打点到真正发出请求包 2)网络上 3)B真正接收请求包到B日志打点。...可是这又引入了一个新的问题,为什么一次Full GC能达到6s之巨。 为什么这么慢 观察监控,笔者发现Full GC有时候快有时候慢。翻出对应6s的那条gc监控日志。...所以看上去是概率上出现GC慢的问题。 另一个机房没出问题 这时候巧的是,业务开发向笔者反映,另一个机房的相同应用确不会出现此问题。捞了下对应日志,发现其class unloading只有0.9s左右。...另外, 对于一个偶发性的问题,我们应该通过监控等手段去寻找规律,这样就很容易找到突破点。

    1.2K30

    Linux 服务器性能出问题排查下这些参数指标

    一个基于 Linux 操作系统的服务器运行的同时,也会表征出各种各样参数信息。...CPU 占用率高很多情况下意味着一些东西,这也给服务器 CPU 使用率过高情况下指明了相应地排查思路: 当 user 占用率过高的时候,通常是某些个别的进程占用了大量的 CPU,这时候很容易通过 top...找到该程序;此时如果怀疑程序异常,可以通过 perf 等思路找出热点调用函数来进一步排查; 当 system 占用率过高的时候,如果 IO 操作(包括终端 IO)比较多,可能会造成这部分的 CPU 占用率高...,比如在 file server、database server 等类型的服务器上,否则(比如>20%)很可能有些部分的内核、驱动模块有问题; 当 nice 占用率过高的时候,通常是有意行为,当进程的发起者知道某些进程占用较高的...睡眠的进程数目;swpd 表示使用到的虚拟内存数量,跟 top-Swap-used 的数值是一个含义,而如手册所说,通常情况下 buffers 数目要比 cached Mem 小的多,buffers 一般

    1.7K40

    Android 混淆问题排查

    问题 近期在开发过程中,突然出现混淆后程序出现运行时异常,编译是正常的,不混淆也是正常的, 错误信息如下提示 12-07 14:10:27.056 10603-10603/?...ZygoteInit.java:888) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:749) 思路 1、通过上面的错误信息首先会去排查...2、考虑到关闭混淆正常,开启混淆异常,那么就定位到时混淆的问题 3、既然是混淆问题那就查看混淆配置文件proguard-rules.pro,基本的配置都已经防混淆了 4、接下来的思路就是通过反编译来查看...BaseApplication到底出了啥额问题 过程 第一步 我们看到下面反编译的代码 ?...所以以后遇到混淆的问题就按照提示一步一步排查,一定要反编译文件来分析问题,不然无法定位原因。 还有第一次混淆后建议反编译查看一下包里面的代码,有没有需要混淆的核心代码被keep掉了。

    2.3K20

    Docker EOF问题排查

    一、前言 问题排查过程,源码部分均由我的开发同事排查和记录;在征得其同意后,由我发表在此。...二、问题 某天接到客户反馈,pod的事件中出现大量的 warning event: Readiness probe failed: OCI runtime exec failed: exec failed...三、环境 特别说明:客户在负责运行业务的k8s节点上坚持开启了cpu-manager 组件 版本 k8s 1.14.x 四、排查 1、接到客户反馈后,检查该pod所在节点的kubelet日志,如下...经过排查,发现 runc exec 在运行期间会读取 container 的 state.json,并使用 json decode 时出现异常。 ?...此时排查 runc EOF 和 kubelet cpu-manager update container(默认每 10s 更新一次) 的时间,发现时间点刚好吻合,验证猜想。

    4.9K10
    领券