最近网站CPU经常爆满,到阿里云提交了工单,工程师给我的处理意见:   您好,虚拟主机CPU占用比较高通常这种情况有两种可能:   一是网站应用程序代码逻辑较复杂,或业务架构效率比较低,在请求了某个网页后执行了死循环,造成占用CPU较高,您可以对网站程序代码进行优化改善.   二是有可能您的网站被访问量比较大,访问量包括正常的访问,也包括其他人恶意的频繁攻击式访问,您可以根据网站日志文件,筛选下是否有类似蜘蛛爬虫程序在频繁访问您的网站,对您的虚拟主机造成资源的大量消耗.如果有异常IP的话,您可以

参考 https://wiki.mikejung.biz/Benchmarking 买了一个1核的ECS,测试一下CPU性能 第一次是只用1个thread去跑 [root@iZwz9fy718twfih4bjs551Z ~]# sysbench --test=cpu --cpu-max-prime=20000 run 第二次是用32个thread去跑 [root@iZwz9fy718twfih4bjs551Z ~]# sysbench --test=cpu --cpu-max-prime=200

常常有在本地搭建没问题,到阿里云上跑的时候 fabric启动不成功的问题. 引用: https://yq.aliyun.com/articles/238940 解决方案 1.在e2e_cli 下有个docker-compose-base.yaml    在order和peer的配置下,env 添加: -GODEBUG=netdns=go 2. vi /etc/resov.conf 里把options的配置去掉 还有一个坑爹的问题,1.1版本启动了四个kafka,我阿里云的ecs 2G 的内存带不

阿里云上跑火车(安装 OpenStack Train 版本),猜猜最终花了多少钱? 前言 前面给大家提供了用虚拟机安装 OpenStack 的镜像,虽然已经很简便了,但还是略显笨重.一来镜像文件比较大,二来个人电脑资源比较有限,体验不是很好. 最最重要的是,使用个人电脑没法展示 Kolla 的真正实力,多节点安装. 为了让大家能充分体验到云计算带来的便利,我把目光盯上了公有云. 本期先介绍基本操作,仍然是部署一个 All-In-One 的环境. 选择阿里云 国内首选的公有云当然是阿里云了,我其实

非常抱歉,今天 10:05-10:20 左右,我们用阿里云服务器搭建的 docker swarm 集群又出现故障,又是因为突然的节点 CPU 波动. 受这次故障影响的站点有 闪存,博问,班级,园子,短信息,招聘,小组,网摘,openapi ,由此给您带来很大的麻烦,请您谅解. 故障前先是有一个 worker 节点出现 CPU 100% 报警: 云服务器ECS实例:swarm1-node5,CPU使用率于10:00发生告警,值为100%,持续时间1分钟 收到报警后,我们将这个节点下线并重启: do

非常抱歉,昨天的服务器CPU 100%问题是达到 memcached 的连接数限制引起的,不是阿里云服务器的问题. 之前我们用的是阿里云“云数据库 memcached 版”,上个周末我们换成了自己搭建——基于阿里云“内存网络增强型”服务器用 docker 跑 memcached . docker run -d --net=host --restart unless-stopped memcached -m 15360 但我们在部署 memcached 时没有设置 conn-limit 参数(默认

如果说2013年云计算之路的主题是“踩坑”,那么2014年我们希望云计算之路的主题变成“填坑”——当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在“黑色n秒”(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑. 受“云计算之路:2009年Xen一个补丁背后那

当今天早上在日志中发现这样的错误之后,对阿里云OCS(mecached缓存服务)的积怨倾泻而出. 2014-06-08 07:15:56,078 [ERROR] Enyim.Caching.Memcached.MemcachedNode System.IO.IOException: Failed to write to the socket '10.160.124.220:11211'. Error: ConnectionReset 这个问题我们4月份发现过,当时给OCS起了个外号叫“会断连接的

原文链接:https://m.ithome.com/html/444828.htm 今年一月份,华为正式发布了鲲鹏920数据中心高性能处理器,该处理器兼容ARM架构,采用7纳米制造,最高支持64核,主频达到2.6GHz,支持八通道DDR4.PCIe 4.0.100G RoCE网络. 华为云基于鲲鹏920处理器的通用计算增强型KC1实例,作为市面上为数不多基于ARM架构的云服务器表现究竟如何,我们与阿里云的企业级通用型G5实例进行了全方位的对比. 一.处理器及内存性能 此次我们测试的云服务器产品分

这是今天遇到的第2次故障,主站1台云服务器在14:40:33-14:41:09期间出现CPU突然跑满的状况,而CPU跑满之前,请求量并没有明显增长. 向阿里云提交之后,说晚上会对这台云服务器的虚拟机进行优化.

前提,昨天晚上导入数据库到本地时候发现硬盘满了,出了,好多错,这边在目录下新建了一个/mysql这样的数据库目录,再将/etc/my.cnf 下的datadir 指向到/mysql下,就可以了 阿里云提供云服务器的硬盘由两块组成,一块是系统盘,一块是数据盘,默认数据盘是没有挂载的,如果要用到数据盘就需要自己手动挂载.通过命令fdisk -l,可以看到设备名为/dev/xvdb.另外在挂载前要对硬盘(/dev/xvdb)分区和格式化.分区使用命令fdisk,格式化命令为mkfs.ext3. fdi

工作中涉及到阿里云的应用.在性能测试阶段,压测过程中只要一个CPU未使用满,第二个CPU以至于第三个和第四个CPU完全用不到. 后来和阿里云的同事沟通他们现在用的是单队列的网卡,只能靠RPS/RFS这种伪多队列来均衡CPU的使用情况. 2个CPU:echo '3' >/sys/class/net/eth0/queues/rx-0/rps_cpusecho '32768' >/proc/sys/net/core/rps_sock_flow_entriesecho '32768' >/sys

非常抱歉,今天下午14:20-14:55期间,由于同一个负载均衡中的2台服务器都出现CPU 100%问题,造成博客后台无法正常访问,由此给您带来了很大很大的麻烦,请您谅解. 博客后台是CPU消耗很低的应用,这2台服务器通常CPU占用在5%左右,之前从来没有出现CPU 100%的问题(所以连云监控都没添加CPU监控报警).这次问题很突然,我们发现问题后,远程连接不上服务器,只能重启,重启后立马恢复正常. 对于问题的具体原因,目前还没找到.我们正在进一步排查,也反馈给了阿里云,阿里云也在排查.

今天上午 10: 40 左右,我们所使用的阿里云 RDS 实例的 CPU 突然飙高到近 100% ,造成大量数据库查询操作缓慢.超时,在这个恶劣条件下大量 memcached 缓存无法建立,这样的雪上加霜让 Web 服务器的 CPU 跟着不堪重负,于是要么访问缓慢,要么直接 503 ...造成网站无法正常访问,由此给您带来了很大的麻烦,请您谅解. 问题非常奇怪,昨天同样的时间段,RDS CPU 占用却少很多,平时 RDS CPU 的占用通常都在 60% 以下,而今天我们网站的访问量并没有明显的突

1.使用top命令,查看到一个叫xWx3T的进程cpu占用99.8%,由于我的阿里云是单核的,所以最高只能100%. 把它用kill命令杀死后,过一会儿又启动了,又占用100%. 使用ps -ef可以看到进程路径是在tmp文件夹下,于是我把这几个文件删了 2.刚开始我以为是linux的root密码简单了,被人破解了,于是重新设置了更复杂的 密码,可是仍然重新生成这几个文件,导致cpu又是100%,很恼人.于是写了个python脚本,后台挂起运行,当检测到存在xWx3T这个进程,就杀死他.起到了作

在云上真是无奇不有,昨天偶然间发现在IIS的应用程序池回收设置中,仅仅设置了一下基于虚拟内存限制的回收,就引发了CPU有规律的波动.在这篇博文中,我们将向大家汇报一下云计算之路上的这个小发现. 在之前我们使用阿里云云服务器(虚拟机)遇到一个左右为难的情况: 如果开启虚拟内存页面交换文件,会造成CPU占用高,在高并发情况下会引发CPU 100%.系统无响应的故障,详见云计算之路-阿里云上:启用Windows虚拟内存引发的CPU 100%故障. 如果关闭虚拟内存页面交换文件,在某种因素引起的短时间虚

今天上午11:35~11:40左右,由于负载均衡中的两台云服务器CPU占用突然飚至100%,造成网站5分钟左右不能正常访问,请大家带来了麻烦,请谅解! (上图中红色曲线表示CPU占用) 经过分析,我们确认CPU 100%问题与启用Windows虚拟内存有关. 原先这两台云服务器是禁用虚拟内存的,但昨天由于虚拟内存不够用,造成了服务器自动重启(详见云计算之路-阿里云上:禁用Windows虚拟内存引发的重启),于是启用了Windows虚拟内存.在今天访问高峰期高并发的情况下,引发了CPU 100%故

这篇博文记录一下6月1日在阿里云上遇到的奇怪的CPU 100%问题,希望多年以后能真相大白. 那天负载均衡(SLB)中只放了1台云服务器(平时都放2台),由于是节假日,虽然只放了一台,但这台服务器的负载也没有平时高.但在上午的时候突然出现了CPU 100%问题,然后切换到另外一台云服务器恢复正常. 下午的时候,我们将负载又切换回那台出问题的服务器,正常运行一段时间后,CPU又飙到100%.切换回之前正常的那台服务器后又恢复正常. 对比两台服务器,虽然那台正常的服务器CPU波动也挺大,但即使偶尔串

非常非常抱歉,今晚 19:34 ~ 21:16 园子所使用的阿里云 RDS 数据库服务器突然出现 CPU 100% 问题,造成全站无法正常访问,由此您带来了很大的麻烦,请您谅解. 故障经过是这样的.19:34 这个时间点本来是一个访问低峰,数据库压力比访问高峰时低很多,但数据库服务器却异想天开.吃饱了撑着地让自己的 CPU 满负荷工作(到现在我们都没想通,难道是服务器晚饭吃多了想帮助消化?).开始我们以为是某个应用引起的,一个一个应用排查与重启, 但 CPU 不为所动,依然百分百.接着,我们一边

昨天 22:00~22:30 左右与 23:30~00:30 左右,有1台服役多年的阿里云负载均衡突然失灵,造成通过这台负载均衡访问博客站点的用户遭遇 502, 503, 504 ,由此给您带来麻烦,请您谅解. 问题非常奇怪,从表现看,似乎负载均衡与后端服务器之间的内网通信出现了问题.有时健康检查成功,但转发请求到后端服务器会失败:后端服务器明明正常,有时健康检查却失败:最糟糕的时候,所有后端服务器都健康检查失败.而其他使用同样后端服务器的负载均衡都没出现这个问题,最终通过下线这台负载均衡解决了