挺无语的,局方为了提高服务器资源利用率,年年都改个规则
挺无语的,局方为了提高服务器资源利用率,年年都改个规则,今年更变态了
云资源缩容利用率指标(属于低负载):
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
避免类似这样的情况发生。
改成按量付费就行,给钱了你爱空着就空着。
大佬博客主题改得很棒啊,能分享否?感谢😁
找了一圈发现完全开源的成熟度不够成熟度稍微好一些的不完全开源这就是悲剧 element.io 你觉得如何?集成度很高 github.com/RocketChat/Rock…
既然可以侧载安装,岂不是无法完美执行 App 备案政策了? 强制纯净模式关不掉然后封 bl ? 很可能,要看情况。本国为了维护和谐社会,什么方法和政策都可以上。 怎么禁止…
译者注: 本文翻译自Bruce Eckel(《Thinking in C++》& 《Thinking in Java》作者)的博文,该博文于2009年03月14日发表于: ht…