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

一次线上数据库添加字段造成磁盘不够的问题

公司使用的是MySQL数据库,随着业务和用户的增加有张表的数据达到了150000000(1亿5千万)条左右,其中好几个功能都会对这张表进行增删改操作。在并发量比较大的时候,经常会出现死锁问题。 为了解决这个问题找到CTO和其他领导来请教方案。 经过分析之后,由于离业务繁忙期还有几天,并且1月是系统达到最大并发的时期,所以决定暂时先采取比较稳妥的版本号方案,即只往数据库insert和update数据,定时任务删除旧的数据(之后会采取数据分表分区的方案)版本号记录在redis里面。于是花了2天左右的时间把这些业务里面的代码重构和修改了一遍(其中涉及到使用第三方库修改的代码,修改这部分花了很多时间)。经测试人员测试没问题后,准备发到线上。

03

生产应用频繁fullgc分析

接下来,dump内存,这里注意一点,dump时切记让运维同学把dump的机器从集群中摘掉,否则dump时会造成JVM线程停顿,导致超时告警,影响业务。dump结果使用MAT(Eclipse Memory Analyzer)分析,具体截图就不展示了,从支配树上可以看出,某个缓存对象占用空间很大,个数非常多。从业务代码中查看,发现该对象是个本地缓存对象(Guava Cache),缓存3分钟,而且是个配置项,按照不同业务线、城市,总共才500个,每个配置项比较小,怎么会突然占用这么大空间呢?使用jstat命令查看系统的垃圾回收统计情况,发现YGC大概每10s一次,对于一个对象,即在年轻代中驻留约15*10=150s,再晋升到老年代,也就是在缓存有效期内,缓存对象足够晋升到老年代,缓存失效时,则会创新创建对象放入缓存。初步结论是:缓存过期时间过小导致对象晋升到老年代过快。

02

SAP S4HANA 2020 Fully-Activated Appliance 虚拟机版分享

花费了整整一个周末加两个晚上,终于将最新的SAP S/4HANA 2020, Fully-Activated Appliance从Amazon远程主机打包下载下来,做成VM虚拟机,对,你没看错,很多人心心念念的Fully-Activated Appliance版本,自带业务数据,简称FAA。整个过程非常的艰辛,不仅需要在Amazon上提交工单增加配额,同时还要配置各种参数,主机上打包系统花了5-6个小时,中间还断线了一次,还得从来。因为国内的网络不给力,下载速度太慢,所以采用加拿大的服务器从Amazon主机ftp到本地,然后再传到网盘上,下载过程也很辛苦,足足花了二十多个小时,生怕掉线又得重新来过。但上传网盘的时候又差点崩溃,百度网盘在加拿大海外不给力,上传只有200-300KB/S,尝试了很多的网盘,最终挑选Apple iCloud作为中间云盘,购买iCloud容量,先传上去,然后国内这边再下载下来,123G的数据库上传下载足足用了15个小时,分了33个压缩包。因为手头上没有合适的机子安装,只好借用一个朋友的日本远端主机,然后又得在那台服务器上重新下载一遍。

04

关于Windows服务器的一个奇怪的问题

已经被这个问题困扰了很久了,先说下这个问题的来源及现象吧。 这个问题得从上次换服务器之后说起。这是公司的服务器,用于手机相关的服务器,为手机业务提供APP的升级、收集手机用户基本信息及为手机APP提供相应的指令。因为业务原因,手机用户的相关请求在时间上会比较集中,从数据上来说,高峰的时候并发也就几千个吧。之前的服务器配置比较差一些,4核8G的机器,访问量大的时候响应会比较慢,最慢的时候几十秒才能给返回,服务器的资源也吃满,所以就换成新服务器。新机器是Xeon E5 v4处理器,8核16线程,16G内存。 换到新机器之后,资源剩余比较多,但是却时不时的出现访问的时候秒断的情况。

02
领券