挺无语的,局方为了提高服务器资源利用率,年年都改个规则
挺无语的,局方为了提高服务器资源利用率,年年都改个规则,今年更变态了
云资源缩容利用率指标(属于低负载):
1.VCPU: [ VCPU 平均利用率<8%日峰值利用率<60%]
2 、内存: [内存平均利用率< 10% 且峰值利用<60%]
云资源利用率指标(不属于低负载):
1.VCPU: [ VCPU 平均利用率 ≥8%或峰值利用率 >60%)
2.内存: [内存平均利用率≥10% 或峰值利用 ≥60%]
好了,现在又要重新动态获取保证 cpu 与内存同时达标才行,上一年是 cpu 与内存满足一个要求就行,因此直接默认跑个 tomcat 把内存占满足平均利用率即可,今年开始 cpu+内存都同时满足。都什么脑子呢
提高服务器资源利用率我觉得完全没问题。能理解并且支持。
devin.com/lookbusy/ 这个可以满足你
用不上的资源为什么不释放掉??
释放容易, 但是要用时申请麻烦吧
从申请到通过,流程要走半年+,因此每年申请资源都会做多点,导致部分资源是还没用上的。
并不是释放的问题,据我的观察,最少 70%的开发对自己开发的系统,需要用多少资源、能用多少资源,是需要内存还是 CPU 还是磁盘 IO 读写,这些问题完全没啥概念。然后配置就直接拉满了。
就直接导致了上线之后各种资源使用率 0%的情况。
这个涉及到价格问题么?缩容了之后价格还是原来的么?
而且缩容有了,那么扩容呢?扩容方便不?
缩容方便,扩容需要申请流程很麻烦~
局方是谁
写个脚本擦边跑就是了,规则随便改
#8
如果不涉及价格问题的话,那确实是人家缩容合理。
不过扩容的话,应该还是时间太长了,走流程没问题,你 1 个 2 个自然日就给走完了啊,扩容拖半年+,再缩容就是不合理了。除非说缩容也是半年一次,看半年之内的使用率指标。
平均 8%没问题啊,日均都做不到说明你们纯纯申请多了。
都是跑个脚本拉一下利用率
CPU 日峰值 60% 也太高了,这不是稍微来点突发流量就挂了
我们只要求 CPU 日峰值不低于 30%
除非你们有弹性扩容
没事的,给他服务器配置缩到 9 块 9 一个月的学生服务器。他自己定的规则,关键时刻卡死他不就行了。不让他紧张一下真以为服务器是放着吃白饭的,公司员工的利用率比较低也是在吃白饭的
他要利用率达标就给他达标呗,打工的关心这个?顶多建议一下,发个邮件留痕,出事了看🎆偷着乐就行了
我觉得这个指标看上去没啥大问题啊。。。
换个问法。如果这些服务器省下的钱都给你,你愿意去优化么?
扩容慢了出事他们负责就行
比较好奇如何去评估一个合理的资源,我们这边标配是 4c8g
避免类似这样的情况发生。
改成按量付费就行,给钱了你爱空着就空着。
大佬博客主题改得很棒啊,能分享否?感谢😁
经过艰苦的努力,目前收集到「小搭百科网」 的分身域名共计 2509 个。 已经做成屏蔽列表: github.com/dallaslu/penzai-list 可使用以下直接…
家里的 nas 有 ipv4 外网,不过不是固定 ip ,但是如果你想做一些小应用,比如接入钉钉机器人或者小程序,都是需要固定 ip 的,这个怎么办呢 弄台云主机,做代理呗…
[ 感谢 Todd 同学投递本文 ] 目前,程序设计语言似乎进入了一个蓬勃发展的时期,Javascript、Perl、Python、Ruby、Groovy等一批较新的语言正越来…
合速度