首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

有没有可能知道数据库表在过去几天里每天的大小变化?

要了解数据库表在过去几天里的大小变化,你可以使用多种方法来实现,这取决于你使用的数据库管理系统(DBMS)。以下是一些常见的 DBMS 及其相应的方法:

1. MySQL/MariaDB

在 MySQL 或 MariaDB 中,你可以使用 information_schema 数据库中的表来获取表的大小信息。你可以创建一个脚本来定期记录表的大小变化。

示例脚本

代码语言:javascript
复制
CREATE TABLE IF NOT EXISTS table_size_history (
    record_date DATE,
    table_name VARCHAR(255),
    data_length BIGINT,
    index_length BIGINT,
    total_length BIGINT
);

INSERT INTO table_size_history (record_date, table_name, data_length, index_length, total_length)
SELECT
    CURDATE() AS record_date,
    table_name,
    data_length,
    index_length,
    data_length + index_length AS total_length
FROM
    information_schema.tables
WHERE
    table_schema = 'your_database_name';

你可以将这个脚本设置为一个定时任务(例如使用 cron 或 Windows 任务计划)来每天运行一次。

查询历史数据

代码语言:javascript
复制
SELECT * FROM table_size_history WHERE table_name = 'your_table_name' ORDER BY record_date;

2. PostgreSQL

在 PostgreSQL 中,你可以使用 pg_total_relation_size 函数来获取表的大小。类似地,你可以创建一个脚本来定期记录表的大小变化。

示例脚本

代码语言:javascript
复制
CREATE TABLE IF NOT EXISTS table_size_history (
    record_date DATE,
    table_name TEXT,
    total_size BIGINT
);

INSERT INTO table_size_history (record_date, table_name, total_size)
SELECT
    CURRENT_DATE AS record_date,
    relname AS table_name,
    pg_total_relation_size(relid) AS total_size
FROM
    pg_catalog.pg_statio_user_tables;

你可以将这个脚本设置为一个定时任务(例如使用 cron)来每天运行一次。

查询历史数据

代码语言:javascript
复制
SELECT * FROM table_size_history WHERE table_name = 'your_table_name' ORDER BY record_date;

3. Microsoft SQL Server

在 SQL Server 中,你可以使用 sp_spaceused 存储过程来获取表的大小。你可以创建一个脚本来定期记录表的大小变化。

示例脚本

代码语言:javascript
复制
CREATE TABLE IF NOT EXISTS table_size_history (
    record_date DATE,
    table_name NVARCHAR(255),
    data_size BIGINT,
    index_size BIGINT,
    total_size BIGINT
);

INSERT INTO table_size_history (record_date, table_name, data_size, index_size, total_size)
EXEC sp_MSforeachtable @command1="EXEC sp_spaceused '?'";

你可以将这个脚本设置为一个定时任务(例如使用 SQL Server 代理)来每天运行一次。

查询历史数据

代码语言:javascript
复制
SELECT * FROM table_size_history WHERE table_name = 'your_table_name' ORDER BY record_date;

4. Oracle

在 Oracle 中,你可以使用 DBA_SEGMENTS 视图来获取表的大小。你可以创建一个脚本来定期记录表的大小变化。

示例脚本

代码语言:javascript
复制
CREATE TABLE table_size_history (
    record_date DATE,
    table_name VARCHAR2(255),
    total_size NUMBER
);

INSERT INTO table_size_history (record_date, table_name, total_size)
SELECT
    SYSDATE AS record_date,
    segment_name AS table_name,
    SUM(bytes) AS total_size
FROM
    dba_segments
WHERE
    segment_type = 'TABLE' AND owner = 'YOUR_SCHEMA_NAME'
GROUP BY
    segment_name;

你可以将这个脚本设置为一个定时任务(例如使用 Oracle DBMS_SCHEDULER)来每天运行一次。

查询历史数据

代码语言:javascript
复制
SELECT * FROM table_size_history WHERE table_name = 'YOUR_TABLE_NAME' ORDER BY record_date;
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

如何洞悉隐性需求

俗话说,计划赶不上变化快,无论需求文档做得如何细致,考虑得如何周全,总会有些难以预料需求变更在每天困扰着我们。开发人员苦恼,产品运营人员更苦恼,毕竟谁也不愿意捂着脸一遍一遍地求人改需求。...而需求人员往往会想当然认为,功能差不多,只要挪一下就可以了(平移过去/拼过去)。或者是,页面长差不多,就改成移动端大小就可以了(缩一下)。...内容运营需求 所有静态内容,都可能变成运营需求。静态广告位可能变成轮播广告位,轮播广告位可能变成需要运营后台填写数据,而不是直接写死页面。或者某一天可能变成从另外一个自动数据源拉取数据。...那么对于涉及到钱活动来说,唯一凭据可能就是你数据库数据了。...有可能这个信息是存储相对独立中,并没有严格挂在这个用户id下,那么查询时候就一定要再检查一下数据和用户对应关系。

53930

我眼中分布式系统可观测性

几天 TiDB 4.0 开发分支中,我们引入了一个新功能叫做:Key Visualizer(下面简称 KeyViz),说起来这个小工具也并不复杂,就是用不同颜色方框来显示整个数据库不同位置数据访问频度和流量...过去我一直苦于寻找一个例子说明什么叫做一个「可观测」系统, KeyViz 这个项目上,我找到了对这点绝佳体现。 举几个直观小例子。你知道 TPC-C 测试「长」什么样子吗?...对于一张数据,我们会在逻辑上切分成若干个连续区间,将这些区间内数据分给不同机器存储,不管是写入还是读取,只需要知道目标数据属于哪个区间,就可以直接到那个机器上进行访问。...然后问题就来了,对于这样数据库而言,有没有一种办法能够直观地描述系统运行时状态?我怎么知道它是不是「生病」了?我能不能预测这个系统未来?我能不能发现未知风险?...举个数据库例子:有经验架构师设计一个基于分布式数据库应用时,通常不会将主键设成自增主键,会尽可能用 UUID 或者其他方式打散数据,这样在即使有突发写入压力时候,系统也能很好扩展。

67241
  • 好雨云资深架构师祁世垚参加Qcon演讲,现场反响热烈

    影响性能可能有好几点,举一些例子,常规URL,高峰请求数量给变大了,对运维压力会造成影响。但是有些URL很多,但是真的需要这么多吗?业务逻辑上使用有没有问题?我们需要知道。...还有有些数据库查询有没有真正被缓存到cache,这只有开发知道数据库运维是不知道。...另外是该分离到从库CQL有没有分离也不知道,还有一些cache缓存被穿透了,压力也被丢到数据库这一层了,然后是一些静态资源未压缩,可能会造成带宽占用和浪费。 我们运用实时分析会发现什么问题?...另外我们业务请求可能每天时间点都会有对不同业务请求,所以这个图各个时间段,能浮现出来问题是不样。这个图页面每隔5秒能定时刷新一下,过去5分钟内最新统计结果。...它平均响应时间都是慢查询罚值以下,所以不会出现在慢查询日志,但是它确实会占用很多数据库资源,请求量非常大。

    72840

    解决一个程序问题需要多少步——确定我们没有摸鱼

    3 天前,运行社区系统报告,很多老历史照片都无法作为附件加载 —— 小鲨鱼,快来解决问题。很多人都问题,为什么程序员每天不是调 Bug 就是调 Bug 路上。...现在问题就是主题中内容都没有丢,但是当主题重新生成 HTML 后,只要主题中有附件部分,全部都没有正确生成 HTML。快点检查存储云端附件有没有被删掉。...Step 5 查询数据库数据现在我们得从数据库查看了,因为没有办法确定到底是程序还是数据问题。貌似备份前 3 天数据是好,我们应该要把数据库数据恢复下看看。...因为这个库是容器内,你是没有办法通过其他数据库工具直接连接到数据库上运行 SQL ,通常生成服务器也不允许你这么做。查询结果,发现是本地有的记录,服务器上没有。大概率知道数据库映射出了问题。...原来主题和附件关系映射表中数据丢了部分,导致整个附件有用数据被当做无效数据清理掉了。Step 12 数据恢复把 JOIN 映射表数据进行恢复。

    12700

    今天碰到几个问题20151023(r6笔记第97天)

    每天工作中会碰到一些问题,圈内朋友也会有各种问题,解决问题总是能够带来很大成就感,有时候感觉在做两份工作。...:) 帮助别人意义就在于别人碰到坑,你可能也会碰到,别人遇到坎,也可能是以后你会面临,坑填平了,坎越过去了,对己对人都是好事,知道那些坑,自己就会绕过去尽量规范,不要去犯;有哪些坎,出了问题之后...这个错误不在数据库日志中出现,但是操作中会报出。...详细内容参见http://blog.itpub.net/23718752/viewspace-1815497/ 第一个图是前几天发现DB time有很大抖动,发现后台任务收集统计信息时候总是失败...可以看到后面的几天DB time都在极低一个值范围内。 ? 查看删除datapump临时第二天凌晨,归档次数每小时有近40次,说明当天确实做了不少工作。自此问题便得以解决。

    67540

    显卡缺货终于到头了:4000多块可得3070Ti,比原价便宜2000块拿下3090Ti

    过去半年,显卡降价50%以上 实际上,显卡不再稀缺、持续降价之势年初已经显现。 The Verge统计了eBay上二手GPU价格变化。...总的来看,最近几天,尽管京东上面这些卡价格每天都有些许波动,但将今天几天对比,基本都在呈缓缓下降趋势,没有突然涨上来。...就是不知道未来几个月,显卡价格是否有望再跌落到更诱人价格。 现在下山还是再等等?...就在大家都在“奔走相告”这一喜大普奔消息时,不知道有没有人发现: “短缺是结束了,但是这价格是不是还是不太合理?”...还有人根本不信显卡真的会告别短缺,他认为,挖矿浪潮可能还会卷土重来。 甚至可能就在今年年底? 当然,也有一波人心情是“没钱了,无所谓”,就算真的降了,自己也不会买了。

    23410

    MySQL binlog集市项目小结

    ,而要恢复时候成本则太高了,举个极端例子,1T数据量数据库,要恢复字典数据最有1M,但是很可能需要恢复1T数据量作为代价,有点得不偿失,所以,我们对于binlog集市是希望尽可能完整捕获数据库数据变化...这个事情往前做一下,那就是通常误操作时提供信息是有较大偏差,比如12:10发生操作,可能研发同学会信誓旦旦说是12:08,到底那个时间段之内有没有相关操作,我是把重心放在了定位环节,通过定位让整个数据恢复代价变得最小...其次,我结合我思考,还有一些是之前和研发简单沟通所做分析: 1)运维视角宏观评估和分析:每天数据库中那么多数据变化每天变化情况是如何每天产生多少日志存储?...全平台有哪些需要重点识别和关注,对于那些频繁发生数据变化可能会提供优化思路 4)数据量变化巡检:如果数据库中某张数据量暴涨和下跌,我们有没有机制发现,从单一维度是很难分析出问题,得有历史数据支撑...热文: 呼伦贝尔游记第二篇 呼伦贝尔游记第一篇 山西大同云冈石窟一日游 新数据库时代,DBA 发展之路该如何选择 我们为什么MySQL中几乎不使用分区 《大江大河2》最触动我一段经典对话

    19840

    记录服务上线一年来点点滴滴

    这样观看端查询时,可以一次性获取到最近30天,每天event个数。因为我们只给用户保留最近30天数据,redis上做了个数统计,就不用再去数据库统计了。...搞过数据库的人都知道,更新操作比插入对数据库消耗大得多,从某种意义上来说也变相减轻了数据库负载。 3.0版本中,我们修改了redis使用策略。...虽然是解决了存储方面的问题,但是随着使用云服务用户不断增加,数据库访问压力也渐增。3.0版本,我们新增了浓缩视频功能,就是将一天中视频变化压缩成很短几分钟。...而这一切,都是由于浓缩视频集中凌晨那段时间上传导致。做促销活动几天每天都会送出1w多云服务,一下子就把数据库压垮了。...每天建一张,数据量也不会达到单上限。仅仅是这样实现一下其实也不复杂,但是考虑到版本兼容就没那么简单了。数据库还是只有一台,用户如果还是使用3.0版本,我们也得按照新方式来写

    1.1K50

    从微盟删库,谈谈身边删库跑路大神

    运维人员恶意删除核心数据这种操作确实是有可能发生,但是正常情况下又不应该发生。当然由于管理不规范、权限控制等问题依然可能造成某些人员恶意或非恶意制造出‘删库跑路’事件。...leader回头看了一眼发现一切都已经空了...一脸黑线问:你干啥了!!! 回答: rm -rf /* 可能也是群大佬教 ? 当天晚上两个人都没回家,当时还没有客户使用,并且还是晚上。...不过很厉害是,由于该研发不知道为啥要删除这个数据库。觉得可能有需要就把数据进行了本地备份他硬盘是够大 马上从本地恢复数据,由于网络原因,三小时回复。...工作到最后,我好像都不知道生产环境有没有公网,因为一切都是内网host.. 大数据环境下还经历过提交了Job之后,等Job执行完成后你才能拿到一份压缩好日志。...而执行时数据都是通过文档进行解释,无法看到原始存储。甚至存储位置..每天执行一次,执行完成去ftp上下载执行日志。痛苦!

    1.4K30

    数据分析:缓慢变化中寻找跳变——基于缓慢变化维度用户分群

    特点: 基本上是基于用户当天一些行为或状态数据,例如启动方式,每天启动方式都可能变化,其它也相同。 优势: 优点是与业务结合行强相关,分群方式灵活,能够迅速定位问题。...我们引入了数据仓库中缓慢变化概念,例如,每天均将用户按照过去1个月领取红包天数做分段,这样,用户分群是缓慢变化,解决了分群一致性问题,监控指标是短期变化,可以很好监控出业务异动。 ?...红包敏感群体(缓慢变化维中,过去1个月领取红包22-28天),发布渗透率逐渐提高,这说明红包模块和发布模块,用户产生了较强交集,也许可以在产品层面迭代,促进2个模块相互互动。...总的来说,运用运营视角缓慢变化维,本质上是,一个低频变化上发现其中高频变化。...BI工具应用 对于BI工具,需要区分维度和事实,现在很多BI工具就可以支持「按天变化维度信息」,可以方便快捷利用缓慢变化维进行异动分析,以腾讯灯塔为例: ?

    74230

    数据分析:缓慢变化中寻找跳变——基于缓慢变化维度用户分群

    图:某业务用户数分年龄段曲线(来自腾讯灯塔截图) 动态属性类:当天启动方式、当日拉活渠道、新老用户、当日播放视频数、当日是否领取红包 · 特点:基本上是基于用户当天一些行为或状态数据,例如启动方式,每天启动方式都可能变化...例如,希望分析红包业务,有没有对用户留存产生影响,我们设想几种方式 · 按当日是否领取红包将用户分群,分为「领取红包用户」「未领红包用户」,洞察用户留存,这里会受领取红包渗透率影响较大,另外每天领取红包用户...我们引入了数据仓库中缓慢变化概念,例如,每天均将用户按照过去1个月领取红包天数做分段,这样,用户分群是缓慢变化,解决了分群一致性问题,监控指标是短期变化,可以很好监控出业务异动。 ?...,还非常容易找到业务交集影响和变化 ·    红包敏感群体(缓慢变化维中,过去1个月领取红包22-28天),发布渗透率逐渐提高,这说明红包模块和发布模块,用户产生了较强交集,也许可以在产品层面迭代...BI工具应用       对于BI工具,需要区分维度和事实,现在很多BI工具就可以支持「按天变化维度信息」,可以方便快捷利用缓慢变化维进行异动分析,以腾讯灯塔为例: ?

    74020

    十月丰收季,看看我都收获了什么?

    比如月初有 20 年一遇国庆中秋双节重合,漫长 8 天假期,我在家学习了《价值投资-入门与实战》,目的就是为了让自己对当下环境有更进一步了解,也有利于我对当下形式发展有更进一步认识,当然还有一个目的自然就是创造更多可能呗...不过我想讲的是群友故事,十月有属于他付出得到美好回报。 九月底时候,群友 C 来找我,给了我一张后台服务器监控截图,CPU 使用率飙升到 100%,问我怎么办。...我是第一次看到,不知道有没有小伙伴们某一时刻看到过自己服务器或者是别人服务器 CPU 满载情况。...我们先把数据库建立了一些索引,优化了很多插入语句,还看到一段 select 语句几十个字段,N张关联,太难了,测试了下,一条查询经历了 4 秒,这是什么样查询,也太难了吧。...效果明显啊,小伙伴们,这就是努力回报,期间C 同学还不知道索引,不知道 Redis 缓存,不知道数据库分库分,但是经过这次排查,这些知识点都用上了,实践是检验真理唯一标准,尤其是技术水平提高,实践还是更好方式

    38120

    听说你会架构设计?来,解释一下为什么错不在李佳琦

    于是就趁着休息功夫了解了一下,原来这场风波事件起源于前几天一场直播。 当时,李佳琦直播间介绍合作产品 “花西子” 眉笔价格为 79 元时,有网友评论区吐槽越来越贵了。他直言:哪里贵了?...评论系统特点 正巧,前几天在看关于评论系统设计方案,且这类架构设计互联网大厂面试出现频率还是挺高。所以我们今天就来探讨一下这个热门话题——《海量评论系统架构设计》。...对于嵌套评论存储,我们可以使用递归结构或层次结构数据库设计,也可以使用关系型数据库结构。评论(comment)字段如下: comment_id:评论唯一标识符,主键。...当然,这可能会产生误判,布隆过滤器一定可以发现重复值,但也可能将不重复值判断为重复值。如上图中 “天气”,虽然都命中了 1,但是它并没有存在于敏感词集合。...并且,通过分析用户评论内容,可以进行情感分析,以了解用户情感倾向。 除了算法模块,我们还需要新增一个评论采集系统,定期(比如每天)从数据库里拉取用户评论数据,传入对象存储服务。

    20321

    程序员,别太累!

    可是没用几天,这些技术就要面临淘汰,于是乎,又要辛辛苦苦,勤勤恳恳,没日没夜学习新技术,真想说句坑爹啊,还能不能和小朋友们愉快玩耍,还能不能吃着火锅唱着歌。...,还有没有和朋友们吹牛 B 时间,还有没有和妹子约会时间。...每天六点起床上班,天还没亮,寒风刺骨,拖着饥饿身体,费尽九牛二虎之力,终于挤进了充满各种气味地铁,却发现,拥挤的人群中,自己学会了金鸡独立,乾坤大挪移,梦回张无忌。...到现在,曾经看过书,已经忘了至少 90% 内容,还有一部分,可能知道个概念。好在我还有时间,通过这么多涉猎,基本上确定了自己发展方向,这也算唯一值得肯定地方吧。...10 珍惜眼前——享受生活 我们总是会回想过去,回想过去天真烂漫,回想过去无拘无束,回想过去轻松自在,尤其当遇到困难,或者出现伤病,止不住感叹过去美好。

    50730

    秒杀系统每秒上万次下单请求,我们该怎么去设计

    那我们如何使用消息队列来解决现在秒杀场景带来问题呢?下面我们就一起来看看该怎么使用。 02 秒杀削峰写流量 看过我前面的文章朋友可能会问,为什么不像以前那样进行分库分呢?...当然是可以,但是你应该知道不管是分库分还是扩展数据库,势必会增加复杂性,还要做数据迁移,虽然你通过前面的学习能具备解决这些数据复杂性问题。...但是,这样秒杀场景,高并发写请求并不是持续,也不是每天都有的,可能只有活动几秒或者几十秒就结束了,就没那么大并发写请求了。...因此,我们使用消息队列应对流量高峰时,需要对队列处理时间,前段写入流量大小以及数据库处理能力都要做好评估,最后根据不同量级来决定该部署多少台处理程序。...而数据库端也只有 10 个并发打过去,也是没有压力。 03 异步化简化秒杀业务 通过上面的学习我们知道了消息队列能够大流量写请求时,起到削峰填谷作用。

    1.2K10

    美团工作是种什么样体验?

    时间真是快,转眼间变成打工人也有一年时间了,最近几天朋友圈被各个同学答辩刷屏了。去年自己过年回到家里,再回学校就是领毕业证了,经历了可能是唯一一年云答辩。...学生时代最后一年,对未来工作充满了想象,一直想知道工作后会是什么样子,每天会干些什么,这里就分享一下自己一年以来美团工作和生活。...一般都会固定一周几天进行上线。上线前,因为会有不同需求同一个小程序项目中开发,所以会将大家代码合在一起,不同需求 QA 会再在 staging 环境再回归一次自己测试 case 。...周日早上睡个懒觉,到中午起来点个外卖,边吃外卖边看会儿综艺,然后发现下午也快过去了,再一想第二天就又要开始 6 天上班了,太难了。 大小周 996 持续到了今年过年,年后改为了大小周。...上边项目压力最大就是 C 端项目了,因为它用户量非常非常大,毕竟开发小程序是阿拉丁指数排第 3。 如果出了一点 bug ,最终影响面会非常广。

    1.3K10

    马云:机器再牛X也是人造,现在智能还在幼儿园时代

    第二,人类最重要是健康和快乐,身体健康才可能快乐,智能时代会对健康产业发生巨大变化,未来生物医学、健康产业上,IoT会有巨大突破。 ▌我国人才处在什么水平?今后的人才如何培养?...我现在最担忧是教育必须改革,如果今天教育方法和过去一百年没有差异,很有可能未来孩子就真找不到工作。...上世纪一代两星,那时候人才有限,所有人才都在大专院校,而今天最优秀人才不在大学企业,所以现在学校跟着企业走,我们认为人才就该在企业间,甚至民营企业间。...关于职业消失问题,我觉得旧职业消失,新职业会出现,关键是你有没有迎接新职业准备。 技术发展和职业替代问题,发展过程中我们会找到解决方案。...让机器替代人类工作,这样,未来我们孩子每天只工作4个小时,他还觉得自己比我现在还忙,这才是未来变化。 ▌区块链未来究竟是什么? 我前几天给阿里巴巴员工正风。

    26230

    『Python 爬虫文集梳理』

    过去几年内,我开始了编程。 过去一年内,我开始了工作生涯。 我学会第一个编程技能是『爬虫』,工作后,开始接触Golang。 我开始不断将编程结合业务, 接触越来越多技术。每天都要学习。...专栏:008:MySQLdb及其银行模拟转账 内存或者文件存储方式,对于数据量、或者对数据组织方式都显有些缺点。那么有没有更好对数据组织方式呢。 有的,数据库数据库有各种各样。...先掌握相同类型中最流行知道了基础增删改查、索引、外键等知道。相应业务技术选型,技术迁移过去而已。 专栏:009:高评分电影都在这里 实践型知识学习,最重要是动手。...有没有一种映射关系?实现编程即将类映射到数据上?有的 ORM 技术就是实现这个。 专栏:013:我要你知道实时票房. 随着你对技术精进,你肯定开始想要将技术应用在更复杂领域。...之后,你可能看着这个框架不舒服,缺少某方面的应用,于是你开始自己默默开发。 甚至你不满足为现有的框架增加功能。你开始自己独立开发框架。 于是,你成为了别人眼中大神。

    59740

    做程序员为什么这么累?

    可是没用几天,这些技术就要面临淘汰,于是乎,又要辛辛苦苦,勤勤恳恳,没日没夜学习新技术,真想说句坑爹啊,还能不能和小朋友们愉快玩耍,还能不能吃着火锅唱着歌。...那么问题来了,还有没有打游戏时间,还有没有学习新知识时间,还有没有和朋友们吹牛B时间,还有没有和妹子约会时间。 一天两天可以,可是每天如此,这样单调生活,有何意义可言。...每天六点起床上班,天还没亮,寒风刺骨,拖着饥饿身体,费尽九牛二虎之力,终于挤进了充满各种气味地铁,却发现,拥挤的人群中,自己学会了金鸡独立,乾坤大挪移,梦回张无忌。...到现在,曾经看过书,已经忘了至少90%内容,还有一部分,可能知道个概念。 好在我还有时间,通过这么多涉猎,基本上确定了自己发展方向,这也算唯一值得肯定地方吧。...珍惜眼前——享受生活 我们总是会回想过去,回想过去天真烂漫,回想过去无拘无束,回想过去轻松自在,尤其当遇到困难,或者出现伤病,止不住感叹过去美好。 越是这样,就越要珍惜眼前,过好眼前生活。

    90630

    JVM运行状态评估及优化

    如堆内存大小,年轻代大小,Eden和Survivor比例,老年代大小,大对象阈值,大龄对象进入老年代阈值等。...同时看系统各个接口响应延时是否比如200ms内或在数据库中模拟出来百万级单数据,然后看系统是否还能稳定运行。...通常压测工具会对系统发起持续不断请求,持续很长时间,比如几个小时,甚至几天时间。 所以此时完全就可以在这个环节,对测试机器运行系统,采用jstat分析模拟真实环境压力下,JVM运行状态。...监控线上JVM 每天高峰、低峰期用jstat、jmap、jhat等工具观察线上系统JVM运行是否正常,有无频繁Full GC问题。有就优化,没有就平时每天都定时或每周都看看。...此时你就可以在这些监控系统可视化界面,看到你需要所有指标,包括你各个内存区域对象占用变化曲线,直接可以看到Eden区对象增速,还会告诉你Young GC发生频率以及耗时,包括老年代对象增速以及

    81740
    领券