- 博客(327)
- 收藏
- 关注
原创 【JVM】亿级流量调优(二)
要突破32G内存瓶颈的话,需要改写8字节对齐这条规则,8字节对齐的话,瓶颈是32G,16字节对齐,瓶颈也会扩大一倍,变成64G.但是这样需要考虑内存的使用率,因为在对齐填充的时候,补充的都是空白地址,也就是说在突破瓶颈的同时,也会带来内存空间的浪费。现在64位机器,并没有完全使用64位地址来表示,只使用了48位,剩下16位保留。也就是说,64位机器上最大使用的内存是2的48次方,原因在于CPU还没有强大到能处理这么大的内存,受制于CPU的算力例如:8字节对齐:17B+7B=24B。
2024-08-25 10:10:50
66
原创 【JVM】亿级流量调优(一)
前面的klass模型,它是Java类的元信息在JVM中的存在形式。这个oop模型是Java对象在JVM中的存在形式。
2024-08-25 10:06:52
106
原创 【JVM】剖析字符串与数组的底层实现(二)
jdk8:底层是一个char[]数组jdk9及之后:底层是一个byte[]数组一个中文占两个字节,一个char占两个字节,一个byte占一个字节Jdk9及之后的版本中,多了一个code属性,这个属性标记是告诉调用者按几个字节来取的问题,如果按byte存储的话,存不是什么问题,问题是如何取呢?
2024-08-23 11:53:35
708
原创 【JVM】剖析字符串与数组的底层实现(一)
这里要明确一点的是,在Jdk6以及以前的版本中,字符串的常量池是放在堆的Perm区的,Perm区是一个类静态的区域,主要存储一些加载类的信息,常量池,方法片段等内容,默认大小只有4m,一旦常量池中大量使用intern是会直接产生java.lang.OutOfMemoryError:PermGen Space错误的。JDK1.6及之前:有永久代,运行时常量池在永久代,运行时常量池包含字符串常量池,Perm区域只有4m,一旦常量池大量使用intern很容易发生永久代的OOM。为什么输出会有这些变化呢?
2024-08-23 11:40:38
885
原创 【JVM】JVM内存模型与操作系统内存模型(二)
与虚拟机栈发挥的作用是相似的,他们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中使用、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。甚至有的虚拟机 比如(SUn HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError和OutOfMemoryErr异常。
2024-08-22 10:51:00
864
原创 【JVM】JVM内存模型与操作系统内存模型(一)
可以这样理解:JVM内存模型其实就是JVM在启动的时候从操作系统内存中要了一块大内存,然后将这个大内存分成五个区域:方法区、堆区、虚拟机栈、本地方法栈、本地方法栈、程序计数器.其实叫JVM运行时区域更合适。但是要区分JVM内存模型与JMM(Java Memory Model)InstanceKlass:类的元信息(方法区)InstanceMirrorKlass:镜像类Class对象(堆区)四个名词:class文件:即硬盘上的.class文件。
2024-08-22 10:45:13
1293
原创 【JVM】JVM解析字节码文件过程(二)
在Java字节码中,field_info结构是用来描述类或接口中的字段(成员变量的)。每个field_info结构对应类文件中的一个字段。其中它的组成部分包括如下:1.access_flags:访问标志,表示字段的访问级别(如public, private, protected, static等)和其他属性(如final volatile等)2.name_index:字段名的索引,它是一个指向常量池的索引,常量池中的对应条目包含字段的名称。
2024-08-21 11:01:17
1027
1
原创 【JVM】类加载器、双亲委派、SPI(二)
元空间内部给各个类加载器划分了内存区域。另外还需要注意一点的是,方法区会有碎片化问题,方法区的垃圾回收通常被称为类的卸载。方法区回收之后是没有整理的。
2024-08-20 08:22:14
986
原创 【JVM】类加载器、双亲委派、SPI(一)
实现方式,需要继承java.lang.ClassLoader类,通过源码查看我们也得知了ClassLoader在loadClass的时候不会立马触发解析阶段,因为源码里面就写死了是false.懒汉模式,你可能听过loadClass()和findClass()方法,两者的职责是不一样的loadClass方法与findClass方法分析:1.loadClass方法是ClassLoader类中最常用的方法之一,它负责加载指定的类。它的主要特点是:1.1 它是一个public方法,可以被外部类调用。
2024-08-20 08:17:42
850
原创 【JVM】深入理解类加载机制(二)
Hotspot Debugger(HSDB):JDK原生自带以Windows系统为例,jdk8的环境,在jdk的lib目录下,启动之前,你需要确保你进入的lib目录和你当前的JAVA_HOME配置的JDK是相同的,否则可能会出现无法加载libarary的异常,进而无法使用HSDB,命令如下调节字体大小的方法,添加环境变量JAVA_TOOL_OPTIONS这里需要用attach到一个java进程,利用jps可以查看到相关指令将进程号输入进去,我这里换了一个程序,进程号不同。
2024-08-19 09:00:30
796
原创 【JVM】深入理解类加载机制(一)
Java的每个类,在JVM中都有一个对应的Klass类实例与之对应,存储类的元信息如:常量池、属性信息、方法信息…从继承关系上也能看出来,类的元信息是存储在元空间的。总结:非数组:InstanceKlass -> 普通的类在JVM中对应的C++类 方法区InstanceMirrorKlass -> 对应的是Class对象 镜像类 堆区数组:基本类型数组引用类型数组: ObjArrayKlass为什么还要有镜像类?是为了安全,由JVM控制可以将哪些参数返回给用户。
2024-08-19 08:54:57
913
原创 【JVM】跟我一起来编译OpenJDK
作为一名Javer,应该不少人都想编译一下OpenJDK然后在项目中用上它,自己还可以在OpenJDK中加入自己的东西,而不用受限于Oracle官网上的JDK,市面上还有很多技术也是运行在JVM之上的,这更加说明了研究JVM的重要性,比如Kotlin、Groovy、JRuby、Jython、Scala等等,接下来让我们一起探索JVM吧~
2024-07-16 22:08:22
942
原创 【MySQL】RedoLog日志和Binlog日志哪个先写的问题?
1.自动为每个事务分配一个唯一的ID(XID)。这个ID很重要,是两阶段提交的核心2.COMMIT会被自动的分成Prepare和Commit两个阶段3.Binlog会被当作事务协调者(Transaction Coordinator) Binlog Event会被当作协调者日志binlog在2PC中充当了事务的协调者(Transaction Coordinator)由binlog来通知InnoDB引擎来执行prepare,commit或者rollback的步骤。
2024-07-16 21:06:59
927
原创 MySQL之MySQL用户工具(二)
以过往的经验来看,大多数MySQL商店需要提供两种类型的监测工具:健康监测工具——检测到异常时告警——和为趋势、诊断、问题排查、容量规划等记录指标的工具。大多数系统仅在这些任务中的一个方面做得很好,而不能两者兼顾。更不幸的是,有十几种工具可选,使得评估和选择一款适合的工具非常耗时。许多监控系统不是专门为MySQL服务器设计。它们是通用系统,用于周期性地检测许多类型的资源,从及其到路由再到软件(例如MySQL)。它们一般有某些类型的插件架构,经常会伴随有一些MySQL插件
2024-07-08 21:33:47
733
原创 MySQL之备份与恢复和MySQL用户工具(一)
MySQL服务器发行包中并没有包含针对许多常用任务的工具,例如监控服务器或比较不同服务器间数据的工具。幸运的是,Oracle的商业版提供了一些扩展工具,并且MySQL活跃的开源社区和第三方公司也提供了一系列的工具,降低了自己"重复发明轮子"的需要。
2024-07-08 08:54:14
1065
原创 MySQL之备份与恢复(十)
有各种各样的好的和不是那么好的备份工具。我们喜欢对LVM使用mylvmbackup做快照备份,使用Percona Xtrabackup(开源)或MySQL Enterprise Backup(收费)做InnoDB热备份。不建议对大数据量使用mysqldump,因为它对服务器有影响,并且漫长的还原时间不可预知。有一些备份工具已经出现多年了,不幸的是有些已经过时。最明显的例子是Maatkkit的mk-parallel-dump。它从没有正确运行,甚至被重新设计过好几次还是不行。
2024-07-07 12:29:28
1121
原创 MySQL之备份与恢复(九)
复制和基于时间点的恢复使用的是相同的技术:服务器的二进制日志。这意味着复制在恢复时会是个非常有帮助的工具,哪怕方式不是很明显。下面将演示一些可以用到的方法。这里列出来的不是一个完整的列表,但应该可以为你根据需求设计恢复方案带来一些想法。记得编写脚本,并且对恢复过程中需要用到的所有技术进行预演。shijian只有没有任何多表的UPDATE、DELETE或INSERT语句操作这个表时,上述流程才是可行的。
2024-07-07 10:31:03
1021
原创 MySQL之备份与恢复(八)
如果还原的是逻辑备份而不是物理备份,则与使用操作系统简单地复制文件到适当位置的方式不同,需要使用MySQL服务器本身来加载数据到表中。在加载导出文件之前,应该先花一点时间考虑文件有多大,需要多久加载完,以及在启动之前还需要做什么事情,例如通知用户或禁用掉部分应用。禁掉二进制日志也是个好主意,除非需要将还原操作复制到备库:服务器加载一个巨大的导出文件的代价很高,并且写二进制日志会增加更多的(可能没有必要的)开销。加载巨大的文件对于一些存储引擎也有影响。
2024-07-06 12:01:07
1045
原创 MySQL之备份与恢复(七)
LVM快照备份也是有开销的。服务器写到原始卷的越多,引发的额外开销也越多。当服务器随机修改许多不同块时,磁头需要需要自写时复制空间来来回回寻址,并且将数据的老版本写到写时复制空间。从快照中读取也有开销,因为LVM需要从原始卷中读取大部分数据。只有快照创建后修改过的数据从写时复制空间读取;因此,逻辑顺序读取快照数据实际上也可能导致磁头来回移动。所以应该为此规划好快照。快照实际上会导致原始卷和快照都比正常的读/写性能要差——如果使用过多的写时复制空间,性能可能会差很多。
2024-07-06 09:36:13
975
原创 MySQL之备份与恢复(六)
创建一个快照的消耗几乎微不足道,但还是需要确保系统配置可以让你获取在备份瞬间的所有需要的文件的一致性副本。首先,确保系统满足下面这些条件。LVM有卷组的概念,它包含一个或多个逻辑卷。输出显示了一个分布在一个物理卷上的卷组,它有四个逻辑卷,大概有250GB空间空闲。入股哦需要,可用vgdisplay命令产生更详细的输出。现在让我们看下系统上的逻辑卷。
2024-07-05 21:29:31
1006
原创 MySQL之备份与恢复(五)
可以使用SQL命令SELECT INTO OUTFILE以符号分隔文件格式创建数据的逻辑备份。(可以用mysqldump的 --tab选项导出到符号分隔文件中)。符号分隔文件包含以ASCII展示的原始数据,没有SQL、注释和列名。下面是一个导出为逗号分隔值(CVS)格式的例子。对于表个形式的数据来说这是一个很好的通用格式。导出时你可能会遇到报错,按照图中所示导入到mysql认为安全的目录下就行。比起SQL导出文件,符号分隔文件要更紧凑且更易于用命令行工具操作,这种方法最大的优点时备份和还原速度更快。
2024-07-05 09:17:23
728
原创 MySQL之备份与恢复(四)
从备库中备份最大的好处是可以不干扰主库,避免在主库上增加额外的负载。这是一个建立备库的好理由,即使不需要用它做负载均衡或高可用。如果钱是个问题,也可以把备份用的备库用于其他用户,例如报表服务——只要不对其做写操作,以确保备份不会修改数据。备库不必只用于备份的目的;只需要在下次备份时能及时跟上主库,即使有时因作为其他用途导致复制延时也没有关系。当从备库备份时,应该保存所有关于复制进程的信息,例如备库相对于主库的位置。
2024-07-04 23:02:04
913
原创 MySQL之备份与恢复(三)
物理备份通常更加简单高效(值得一提的是物理备份会更容易出错;很难相Mysqldump一样简单)尽管如此,对于需要长期保留的备份,或者是满足法律合规要求的备份,尽量不要完全依赖物理备份。至少每隔一段时间还是需要做一次逻辑备份。除非经过测试,不要假定备份(特别是物理备份)是正常的。对InnoDB来说,这意味着需要启动一个MySQL实例,执行InnoDB恢复操作,然后运行CHECK TABLES。也可以跳过这一操作,仅对文件运行innochecksum,但不建议这样做。
2024-07-04 21:44:33
1324
原创 MySQL之备份与恢复(二)
如果一切正常,那么永远也不需要考虑恢复。但是,一旦需要恢复,只有世界上最好的备份系统是没用的,还需要一个强大的恢复系统。不幸的是,让备份系统平滑工作比构造良好的恢复过程和工具更容易。这里有一个看到的真实例子:一个客户报告说当mysqldump加上-d选项后,备份变得像闪电一般快,他想知道为什么没有一个人提出该选项可以如此快地加速备份过程。如果这个客户已经尝试还原这些备份,就不难发现其原因:使用-d选项将不会备份数据!这个客户关注备份,却没有关注恢复,因此完全没有意识到这个问题。
2024-07-03 22:10:36
1311
4
原创 MySQL之应用层优化和备份与恢复(一)
如果没有提前做好备份规划,也许以后会发现已经错失了一些最佳得选择。例如,在服务器已经配置好了以后,才想起应该使用LVM,以便可以获取文件系统的快照——但这时已经太迟了。在为别分配置系统参数时,可能没有注意到某些系统配置对性能有着重要影响。如果没有计划做定期的恢复演练,当真的需要恢复时,就会发现并没有那么顺利。在此假设大部分用户主要使用InnoDB而不是MyISAM。也不会涵盖一个精心设计的备份和恢复解决方案的所有部分——而仅涉及与MySQL相关的部分。1.安全(访问备份,恢复数据的权限,文件是否需要加密)
2024-07-03 09:22:38
637
原创 MySQL之应用层优化(三)
可以缓存关于搜索的最小信息,而不必缓存整个列表,例如返回结果的数量以及列表中的产品ID。现在想象以下,一个产品地描述发生了变化,不再包含搜索中匹配地关键字,但是搜索结果地缓存还没有过期失效,此时用户就会看到错误地搜索结果,因为缓存的搜索结果将会引用这个变化了的产品,即使它不再包含匹配搜索的关键字。在前面的图书俱乐部的例子中,你可以通过下面的版本好标记评论,使缓存的评论依赖于用户的版本和书的版本:user_ver=1234和book_ver=5678.任一版本号变了,都应该刷新缓存的评论。
2024-07-02 22:11:36
944
原创 MySQL之应用层优化(二)
每个Web服务器都有一个最佳并发度——就是说,让进程处理请求尽可能快,并且不超过系统负载的最优的并发连接数。这就是前面说的最大系统容量。进行一个简单的测量和建模,或者只是反复试验,就可以找到这个"神奇的数",为此花一些时间是值得的。对于大流量的网站,Web服务器同一时刻处理上千个连接是很常见的。然而,只有一小部分连接需要进程实时处理。其他的可能是读请求,处理文件上传,填鸭式服务内容,或者只是等待客户端的下一步请求。随者并发的增加,服务器会逐渐到达它的最大吞吐量。
2024-07-02 09:27:01
1115
原创 MySQL之高可用性和应用层优化(一)
如果在提高MySQL的性能上花费太多时间,容易使事业局限于MySQL本身,而忽略了用户体验。回过头来看,也许可以意识到,或许MySQL已经足够优化,对于用户看到的响应时间而言,其所占的比重已经非常之小,此时应该关注下其他部分了。这是个很不错的观点,尤其是对DBA而言,这是很值得去做的正确的事。但如果不是MySQL,那有时什么导致了问题?在前面的讨论中,可以通过测量可以快速而准确地给出答案。如果能顺着应用的逻辑过程从头到尾来剖析,那么找到问题的源头一般来说并不困难。
2024-07-01 22:36:28
1061
2
原创 MySQL之高可用性(四)
冗余是很好的技术,但实际上只有在遇到故障需要恢复时才会用到。(见鬼,这可以用备份来实现)。冗余一点儿也不会增加可用性或减少宕机。在故障转移的过程中,高可用性是建立在冗余的基础上。当有一个组件失效,但存在冗余时,可以停止使用发生故障的组件,而使用冗余备件。冗余和故障转移结合可以帮助更快地恢复,如你所知,MTTR(平均恢复时间)的减少将降低宕机时间并改善可用性。在继续这个话题之前,我们先来定义一些术语。我们统一使用"故障转移(failover)",有些人使用"回退(fallback)“来表达同一意思。
2024-07-01 09:30:36
715
原创 MySQL之高可用性(三)
当使用同步复制时,主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标:当服务器崩溃时没有提交的事务会丢失,并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动——主动模式。这意味着每个服务器在任何时候都是故障转移的候选者,这使得通过冗余关于获得高可用性更加容易,早期版本的MySQL不支持同步复制(MySQL5.5支持半同步复制),还有两个基于MySQL的集群解决方案支持同步复制。
2024-06-30 13:16:25
1126
原创 MySQL之高可用性(二)
找到并消除系统中的可能失效的单点,并结合切换到备用组件的机制,这是一种通过减少恢复时间(MTTR)来改善可用性的方法。如果你够聪明,有时候甚至能将实际的恢复时间降低至0,但总的来说这很困难。(即使一些非常引人注目的技术,例如昂贵的负载均衡器,在发现问题并进行反馈时也会导致一定的延迟)。思考并梳理整个应用,尝试去定位任何可能失效的单点。是一个硬盘驱动器,一台服务器,一台交换或路由器,还是某个机架的电源?所有数据都在一个数据中心,或者冗余数据中心是由同一个公司提供的吗?
2024-06-30 10:39:41
1011
原创 MySQL之可扩展性和高可用性(一)
接下来分析提到的复制、可扩展性以及高可用性三个主题中的第三个。归根结底,高可用性实际上意味着"更少的宕机时间"。然而糟糕的是,高可用性经常和其他的概念混淆,例如冗余、保障数据不丢失,以及负载均衡。高可用性实际上优点像神秘的野兽。它通常以百分比表示,这本身也是一种按时:高可用性不是绝对的,只有相对更高的可用性。100%的可用性是不可能达到的。可用性的"9"规则是表示可用性目标最普遍的方法,你可能也知道"5个9"表示99.999%的正常可用时间。换句话说,每年只允许5分钟的宕机时间。
2024-06-29 12:20:55
693
原创 MySQL之可扩展性(九)
还有一个分发负载的办法是重新配置应用。例如,你可以配置多个机器来分担生成大报表操作的负载。每台机器可以配置成连接到不同的MySQL备库,并为第N个用户或网站生成报表。这样的系统很容易实现,但如果需要修改一些代码——包括配置文件修改——会变得脆弱且难以处理。硬编码有着固有的限制,需要在每台机器上修改硬编码,或者在一个中心服务器上修改,然后通过文件副本或代码控制更新命令"发布"到其他服务器上,如果将配置存储在服务器或缓存中,就可以避免这些麻烦。
2024-06-29 10:30:43
1138
原创 MySQL之可扩展性(八)
负载均衡的基本思路很简单:在一个服务器集群中尽可能地平均负载量。通常的做法是在服务器前端设置一个负载均衡器(一般是专门的硬件设备)。然后负载均衡器将请求的连接路由到最空闲的可用服务器。如图显示了一个典型的大型网站负载均衡设置,其中一个负载均衡器用于HTTP流量,另一个用于MySQL访问。负载均衡有五个常见目的。在与MySQL相关的领域里,负载均衡架构通常和数据分片及复制紧密相关。你可以把负载均衡和高可用性结合在一起,部署到应用的任一层次上。
2024-06-28 22:57:52
1071
原创 MySQL之可扩展性(七)
理想的扩展方案时单一逻辑数据库能够存储尽可能多的数据,处理尽可能多的查询,并如期望的那样增长。许多人的第一想法就是建立一个"集群"或者"网格"来无缝处理这些事情,这样应用就无须去做太多工作,也不需要知道数据到底存在哪台服务器上。随者云计算的流行,自动扩展——根据负载或数据大小变化动态地在集群中增加/移除服务器——变得越来越有趣。网上出现了许多被称为NoSQL的技术。许多NoSQL的支持者发表了一些奇怪且未经证实的观点,例如"关系型模型无法进行扩展",或者"SQL无法扩展"。
2024-06-28 21:15:13
860
原创 MySQL之可扩展性(六)
如有必要,可以通过在分片间移动数据来达到负载均衡。举个例子,许多读者可能听一些大型图片分享网站或流行社区网站的开发者提到过用于分片间移动用户数据的工具。在分片间移动数据的好处很明显。例如,当需要升级硬件时,可以将用户数据从旧分片转移到新分片上,而无须暂停整个分片的服务或将其设置为只读。然而,我们也应该尽量避免重新均衡分片数据,因为这可能会影响用户使用。在分片间转移数据也使得为应用增加新特性更加困难,因为新特性可能还需要包含针对重新均衡脚本的升级。如果分片足够小,就无须这么做;
2024-06-27 22:36:30
894
原创 MySQL之可扩展性(五)
需要确定如何在节点上部署数据分片。如果在标命中包含了分片号,就需要在查询模板里插入分片号。常用的方法是在查询中使用特殊的"神奇的"占位符,例如sprintf()这样的格式化函数中的%s,或者使用变量做字符串插值。$shardno$shardno这在新应用中很容易实现,但对于已有的应用则优点困难。构建新应用时,查询模板并不是问题,我们倾向于使用每个分片一个数据库的方式,并把分片号写到数据库名和表名中。
2024-06-27 09:25:13
1575
原创 MySQL之可扩展性(四)
这是一个问题,对吧?答案很简单:如非必要,尽量不分片。首先看是否能通过性能调优或者更好的应用或数据库设计来推迟分片。如果能足够长时间地推迟分片,也许可以直接购买更大地服务器,升级MySQL到性能更优地版本,然后继续使用单台服务器,也可以增加或减少复制。简单地说,对单台服务器而言,数据大小或写负载变得太大时,分片将是不可避免的。如果不分片,而是尽可能地优化应用,系统能扩展到什么程度呢?答案可能会让你惊讶。
2024-06-26 21:52:40
1375
原创 MySQL之可扩展性(三)
可以把向外扩展(有时也称为横向扩展或水平扩展)策略划分为三个部分:复制、拆分以及数据分片(sharding).最简单也最常见的向外扩展的方法是通过复制将数据分发到多个服务器上,然后将备库用于读查询。这种技术对于以读为主的应用很有效。它也有一些缺点,例如重复缓存,但如果数据规模有限这就不是问题。另外一个比较常见的向外扩展是工作负载分布到多个"节点"。具体如何分布工作负载是一个复杂的话题。许多大型的MySQL应用不能自动分布负载,就算有也没有做到完全的自动化。
2024-06-26 09:28:51
755
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人