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

    解决数据中心网速变慢的八个检查必备步骤

    在数据中心运行过程中,不可避免会出现各种各样的问题。若网络发生信息不通、网页不能浏览等连通性故障时,这类故障现象的故障点很容易检查和定位, 解决起来并不困难。但是网络如果是通的,而网速变慢。遇到这种“软”故障,就比较令人头痛,有的人往往就会束手无策。一旦遇到这类问题时,需要有一个定位问题的基本思路,这样就能帮助我们在日常维护中有条不紊地找到问题的真实原因。 第一:检查设备CPU占用率 数据中心里的设备少则数百,多则上万,不可能都去依依检查CPU。需要先明确哪个业务慢,了解这个业务在数据中心里需要经过哪些设备

    05

    记一次mysql数据库cpu暴涨100%事故

    在公司监控大盘上看到了我负责的项目的数据库服务器CPU达到100%了, 于是紧急排查问题。仔细的看了一下监控大盘,发现时间从下午3点47分起就开始迅速上升到满cpu的情况,并且持续了23分钟,之后又断断续续的满cpu,每次持续时间大概在几分钟到10分钟左右。第一反应是想到是不是服务器有什么错误日志没输出,检查了elk中的错误,没有错误异常。第二个排查的地方是检查从3点47分起开始的访问量看看是不是并发比较高,发现访问量也是正常的,qps大概在60左右。于是下去找运维要一份数据库的慢sql,但是运维还没看到有慢sql(这点不清楚运维的慢sql是怎么记录日志的,按道理是应该有慢sql)。于是通过show processlist查询到了大概4,5条正在执行的查询。发现用户是我们yearning的用户,而不是应用的用户,并且query_start的起始时间距离现在也差不多在7,8分钟左右。将该sql展开发现是一个在yearning上面执行的inner join,我们是有分表的措施的,将数据按照不同企业维度分摊到10个表。平均一张表大概在10万左右的数据量,同事执行的inner join查询通过explain关键词分析发现该语句笛卡尔积之后的扫描行数足足有6亿行,最后筛选出了89行符合要求的数据。跟同事沟通了一下才发现是他执行的复杂查询。让运维帮忙kill掉查询语句后,数据库cpu恢复正常。

    01

    【VMware虚拟化解决方案】 基于VMware虚拟化平台VDI整体性能分析与优化

    本来打算将前期项目里面出现的问题的分析思路与解决方法写出来,第一、疏导一下自己的思路,第二、分析并找出自身在技术层面所存在欠缺。但由于每个人都有一根懒经所以迟迟未动。今天突然发现51CTO在做VMware【展现虚拟化商业价值】解决方案的征文活动,看着那丰厚的奖品,让我这根懒经顿时兴奋!决定将前期的一个分析思路与解决方法写下来,一来供朋友们参考,二来借助专业大师帮忙分析分析思路是否正确。由于其中涉及公司的一个相关机密所以相应的资料信息会明确的更少一些还请见谅!由于我们的服务器虚拟化、桌面虚拟化都是采用一套存储,本来想将整盘的分析过程写下来,但发现如果加上服务器虚拟化与RDS虚拟化以后篇幅太长了,为此这里仅仅只说VID平台。

    04
    领券