• 关于 mysql 性能调优 的搜索结果

回答

自己先装个Mysql,然后再看书,入门可以先看《Mysql必知必会》。其他的好书有: 高性能MySQL MySQL核心技术手册 MySQL性能调优与架构设计 深入理解MySQL核心技术 MySQL核心内幕 MySQL开发者SQL权威指南 MySQL技术内幕 InnoDB存储引擎 深入理解MySQL MySQL权威指南

aoteman675 2019-12-02 01:38:30 0 浏览量 回答数 0

问题

服务器性能调优过程

落地花开啦 2019-12-01 19:30:23 1185 浏览量 回答数 1

回答

不会挂掉,只会取决于你的 mysql 服务器有多强大。如果你的数据比较少能够全部放入缓存里面的话,很有可能会远小于 50s,不过这个都说不准,得看你的机器实际配置。会让 mysql 挂掉的一般就是并发的 insert + update,因为排队的锁太多导致 mysql 等待锁时间找出限额导致自动崩溃。书的话《MySQL性能调优与架构设计》这本书作为入门还不错,更多进阶的内容应该去看看 Mysql Performance Blog。

蛮大人123 2019-12-02 01:43:24 0 浏览量 回答数 0

中小企业与商标那些事

企业品牌保护从商标开始,如何挑选一家靠谱的渠道注册商标,解读品牌权益维护的重要节点。

回答

知识清单 常见模式与框架 设计模式 开发框架,比如 spring, springMVC, mybatis 工程化与工具 软件开发流程&规范 分布式架构 负载均衡,高可用 rpc,消息队列 分布式存储 微服务架构 性能优化 应用层:JVM 结构 & 调优 web 服务器层:tomcat 等服务器结构 & 调优 存储层:MySQL 结构 & sql 优化,搜索引擎结构 & 查询优化 底层知识 对 JDK 的包结构,模块深入学习功能&使用场景 围绕数据结构&性能优化学习组织 对于 Java 开发来讲,JDK 几乎就是最底层和基础的知识了。对 JVM, MySQL等非 Java 程序了解结构,原理,调优基本就差不多了。但是 JDK 是要深入了解掌握的,这是你自己开发,学习 Java 程序的基础 从开发到架构师 我理解,1, 2, 5, 6 是高级开发就需要掌握的知识,到架构师级别 3, 4 要理解得比较深入,5, 6 的要求也更高。 技术上是从单体技术 -> 分布式,微服务局部 -> 整体简单 -> 深入 因为架构师是一个更宏观的角色,单体系统的时候,单体系统划分、设计功能模块的也是架构师。随着分布式的兴起,架构师需要从分布式角度看整体系统,而到了微服务时代,架构师又要关注微服务,docker 等技术。

jxiaoyu 2019-12-02 01:47:38 0 浏览量 回答数 0

回答

知识清单 常见模式与框架 设计模式 开发框架,比如 spring, springMVC, mybatis 工程化与工具 软件开发流程&规范 分布式架构 负载均衡,高可用 rpc,消息队列 分布式存储 微服务架构 性能优化 应用层:JVM 结构 & 调优 web 服务器层:tomcat 等服务器结构 & 调优 存储层:MySQL 结构 & sql 优化,搜索引擎结构 & 查询优化 底层知识 对 JDK 的包结构,模块深入学习功能&使用场景 围绕数据结构&性能优化学习组织 对于 Java 开发来讲,JDK 几乎就是最底层和基础的知识了。对 JVM, MySQL等非 Java 程序了解结构,原理,调优基本就差不多了。但是 JDK 是要深入了解掌握的,这是你自己开发,学习 Java 程序的基础 从开发到架构师 我理解,1, 2, 5, 6 是高级开发就需要掌握的知识,到架构师级别 3, 4 要理解得比较深入,5, 6 的要求也更高。 技术上是从单体技术 -> 分布式,微服务局部 -> 整体简单 -> 深入 因为架构师是一个更宏观的角色,单体系统的时候,单体系统划分、设计功能模块的也是架构师。随着分布式的兴起,架构师需要从分布式角度看整体系统,而到了微服务时代,架构师又要关注微服务,docker 等技术。

jxiaoyu 2019-12-02 01:49:29 0 浏览量 回答数 0

回答

知识清单 常见模式与框架 设计模式 开发框架,比如 spring, springMVC, mybatis 工程化与工具 软件开发流程&规范 分布式架构 负载均衡,高可用 rpc,消息队列 分布式存储 微服务架构 性能优化 应用层:JVM 结构 & 调优 web 服务器层:tomcat 等服务器结构 & 调优 存储层:MySQL 结构 & sql 优化,搜索引擎结构 & 查询优化 底层知识 对 JDK 的包结构,模块深入学习功能&使用场景 围绕数据结构&性能优化学习组织 对于 Java 开发来讲,JDK 几乎就是最底层和基础的知识了。对 JVM, MySQL等非 Java 程序了解结构,原理,调优基本就差不多了。但是 JDK 是要深入了解掌握的,这是你自己开发,学习 Java 程序的基础 从开发到架构师 我理解,1, 2, 5, 6 是高级开发就需要掌握的知识,到架构师级别 3, 4 要理解得比较深入,5, 6 的要求也更高。 技术上是从单体技术 -> 分布式,微服务局部 -> 整体简单 -> 深入 因为架构师是一个更宏观的角色,单体系统的时候,单体系统划分、设计功能模块的也是架构师。随着分布式的兴起,架构师需要从分布式角度看整体系统,而到了微服务时代,架构师又要关注微服务,docker 等技术。

jxiaoyu 2019-12-02 01:57:28 0 浏览量 回答数 0

回答

入门足够啦,后期进阶 知识清单 常见模式与框架 设计模式 开发框架,比如 spring, springMVC, mybatis 工程化与工具 软件开发流程&规范 分布式架构 负载均衡,高可用 rpc,消息队列 分布式存储 微服务架构 性能优化 应用层:JVM 结构 & 调优 web 服务器层:tomcat 等服务器结构 & 调优 存储层:MySQL 结构 & sql 优化,搜索引擎结构 & 查询优化 底层知识 对 JDK 的包结构,模块深入学习功能&使用场景 围绕数据结构&性能优化学习组织 对于 Java 开发来讲,JDK 几乎就是最底层和基础的知识了。对 JVM, MySQL等非 Java 程序了解结构,原理,调优基本就差不多了。但是 JDK 是要深入了解掌握的,这是你自己开发,学习 Java 程序的基础 从开发到架构师 我理解,1, 2, 5, 6 是高级开发就需要掌握的知识,到架构师级别 3, 4 要理解得比较深入,5, 6 的要求也更高。 技术上是从单体技术 -> 分布式,微服务局部 -> 整体简单 -> 深入 因为架构师是一个更宏观的角色,单体系统的时候,单体系统划分、设计功能模块的也是架构师。随着分布式的兴起,架构师需要从分布式角度看整体系统,而到了微服务时代,架构师又要关注微服务,docker 等技术。

jxiaoyu 2019-12-02 01:58:56 0 浏览量 回答数 0

问题

千万级的mysql数据库如何做性能优化

蛮大人123 2019-12-01 19:49:11 1888 浏览量 回答数 2

问题

MongoDB性能优化“五部曲”

sunny夏筱 2019-12-01 21:29:33 6708 浏览量 回答数 4

问题

MongoDB性能优化五个简单步骤

doudou1 2019-12-01 22:08:35 7072 浏览量 回答数 2

回答

1.关于云数据库RDS MySQL版【问答合集】 https://developer.aliyun.com/ask/127198?spm=a2c6h.13066369.0.0.9262485fRiMBjo 2.点击链接:https://shop9r183yr3.market.aliyun.com/?spm=a2c6h.13066369.0.0.1df6292blaNHWC 阿里云计算有限公司rds 阿里云数据库官方紧急救援。这个帮你的都是阿里云数据库的研发工程师,相比售后,他们更加专业,也更加懂得数据库的性能调优。 服务收费,按照小时算,可能能解决你的问题。 3.95187转1 阿里专业客服帮助你。 希望对你有帮助!

阿里朵 2019-12-02 02:16:17 0 浏览量 回答数 0

问题

为 MySQL/MariaDB 开启 Binlog 功能

妙正灰 2019-12-01 21:43:30 1193 浏览量 回答数 1

回答

本文介绍AliSQL的内核版本更新说明。 MySQL 8.0 20200229 新特性 Performance Agent:更加便捷的性能数据统计方案。通过MySQL插件的方式,实现MySQL实例内部各项性能数据的采集与统计。 在半同步模式下添加网络往返时间,并记录到性能数据。 性能优化 允许在只读实例上进行语句级并发控制(CCL)操作。 备实例支持Outline。 Proxy短连接优化。 优化不同CPU架构下的pause指令执行时间。 添加内存表查看线程池运行情况。 Bug修复 在低于4.9的Linux Kenerls中禁用ppoll,使用poll代替。 修复wrap_sm4_encrypt函数调用错误问题。 修复在滚动审核日志时持有全局变量锁的问题。 修复恢复不一致性检查的问题。 修复io_statistics表出现错误time值的问题。 修复无效压缩算法导致崩溃的问题。 修复用户列与5.6不兼容的问题。 20200110 新特性 Inventory Hint:新增了三个hint, 支持SELECT、UPDATE、INSERT、DELETE 语句,快速提交/回滚事务,提高业务吞吐能力。 性能优化 启动实例时,先初始化Concurrency Control队列结构,再初始化Concurrency Control规则。 异步清除文件时继续取消小文件的链接。 优化Thread Pool性能。 默认情况下禁用恢复不一致性检查。 更改设置变量所需的权限: 设置以下变量所需的权限已更改为普通用户权限: auto_increment_increment auto_increment_offset bulk_insert_buffer_size binlog_rows_query_log_events 设置以下变量所需的权限已更改为超级用户或系统变量管理用户权限: binlog_format binlog_row_image binlog_direct sql_log_off sql_log_bin 20191225 新特性 Recycle Bin:临时将删除的表转移到回收站,还可以设置保留的时间,方便您找回数据。 性能优化 提高短连接处理性能。 使用专用线程为maintain user服务,避免HA失败。 通过Redo刷新Binlog时出现错误会显式释放文件同步锁。 删除不必要的TCP错误日志。 默认情况下启用线程池。 Bug修复 修复慢日志刷新的问题。 修复锁定范围不正确的问题。 修复TDE的Select函数导致的核心转储问题。 20191115 新特性 Statement Queue:针对语句的排队机制,将语句进行分桶排队,尽量把可能具有相同冲突的语句放在一个桶内排队,减少冲突的开销。 20191101 新特性 为TDE添加SM4加密算法。 保护备实例信息:拥有SUPER或REPLICATION_SLAVE_ADMIN权限的用户才能插入/删除/修改表slave_master_info、slave_relay_log_info、slave_worker_info。 提高自动递增键的优先级:如果表中没有主键或非空唯一键,具有自动增量的非空键将是第一候选项。 对系统表和处于初始化状态线程用到的表,不进行Memory引擎到MyISAM引擎的自动转换。 Redo Log刷新到磁盘之前先将Binlog文件刷新到磁盘。 实例被锁定时也会影响临时表。 添加新的基于LSM树的事务存储引擎X-Engine。 性能优化 Thread Pool:互斥优化。 Performance Insight:性能点支持线程池。 参数调整: primary_fast_lookup:会话参数,默认值为true。 thread_pool_enabled:全局参数,默认值为true。 20191015 新特性 TDE:支持透明数据加密TDE(Transparent Data Encryption)功能,可对数据文件执行实时I/O加密和解密,数据在写入磁盘之前进行加密,从磁盘读入内存时进行解密。 Returning:Returning功能支持DML语句返回Resultset,同时提供了工具包(DBMS_TRANS)便于您快捷使用。 强制将引擎从MyISAM/MEMORY转换为InnoDB:如果全局变量force_memory/mysiam_to_innodb为ON,则创建/修改表时会将表引擎从MyISAM/MEMORY转换为InnoDB。 禁止非高权限账号切换主备实例。 性能代理插件:收集性能数据并保存到本地格式化文本文件,采用文件轮循方式,保留最近的秒级性能数据。 Innodb mutex timeout cofigurable:可配置全局变量innodb_fatal_semaphore_wait_threshold,默认值:600。 忽略索引提示错误:可配置全局变量ignore_index_hint_error,默认值:false。 可关闭SSL加密功能。 TCP错误信息:返回TCP方向(读取、读取等待、写入等待)错误及错误代码到end_connection事件,并且输出错误信息到错误日志。 Bug修复 支持本地AIO的Linux系统内,在触发线性预读之前会合并AIO请求。 优化表/索引统计信息。 如果指定了主键,则直接访问主索引。 20190915 Bug修复 修复Cmd_set_current_connection内存泄露问题。 20190816 新特性 Thread Pool:将线程和会话分离,在拥有大量会话的同时,只需要少量线程完成活跃会话的任务即可。 Statement Concurrency Control:通过控制并发数应对突发的数据库请求流量、资源消耗过高的语句访问以及SQL访问模型的变化,保证MySQL实例持续稳定运行。 Statement Outline:利用Optimizer Hint和Index Hint让MySQL稳定执行计划。 Sequence Engine:简化获取序列值的复杂度。 Purge Large File Asynchronously:删除单个表空间时,会将表空间文件重命名为临时文件,等待异步清除进程清理临时文件。 Performance Insight:专注于实例负载监控、关联分析、性能调优的利器,帮助您迅速评估数据库负载,找到性能问题的源头,提升数据库的稳定性。 优化实例锁状态:实例锁定状态下,可以drop或truncate表。 Bug修复 修复文件大小计算错误的问题。 修复偶尔出现的内存空闲后再次使用的问题。 修复主机缓存大小为0时的崩溃问题。 修复隐式主键与CTS语句的冲突问题。 修复慢查询导致的slog出错问题。 20190601 性能优化 缩短日志表MDL范围,减少MDL阻塞的可能性。 重构终止选项的代码。 Bug修复 修复审计日志中没有记录预编译语句的问题。 屏蔽无效表名的错误日志。 MySQL 5.7基础版/高可用版 20200229 新特性 Performance Agent:更加便捷的性能数据统计方案。通过MySQL插件的方式,实现MySQL实例内部各项性能数据的采集与统计。 在半同步模式下添加网络往返时间,并记录到性能数据。 性能优化 优化不同CPU架构下的pause指令执行时间。 Proxy短连接优化。 添加内存表查看线程池运行情况。 Bug修复 修复DDL重做日志不安全的问题。 修复io_statistics表出现错误time值的问题。 修复更改表导致服务器崩溃的问题。 修复MySQL测试用例。 20200110 性能优化 异步清除文件时继续取消小文件的链接。 优化Thread Pool性能。 thread_pool_enabled参数的默认值调整为OFF。 20191225 新特性 内部账户管理与防范:调整用户权限保护数据安全。 性能优化 提高短连接处理性能。 使用专用线程为maintain user服务,避免HA失败。 删除不必要的TCP错误日志。 优化线程池。 Bug修复 修复读写分离时mysqld进程崩溃问题。 修复密钥环引起的核心转储问题。 20191115 Bug修复 修复主备切换后审计日志显示变量的问题。 20191101 新特性 为TDE添加SM4加密算法。 如果指定了主键,则直接访问主索引。 对系统表和处于初始化状态线程用到的表,不进行Memory引擎到MyISAM引擎的自动转换。 性能优化 Thread Pool:互斥优化。 引入审计日志缓冲机制,提高审计日志的性能。 Performance Insight:性能点支持线程池。 默认开启Thread Pool。 Bug修复 在处理维护用户列表时释放锁。 补充更多TCP错误信息。 20191015 新特性 轮换慢日志:为了在收集慢查询日志时保证零数据丢失,轮换日志表会将慢日志表的csv数据文件重命名为唯一名称并创建新文件。您可以使用show variables like '%rotate_log_table%';查看是否开启轮换慢日志。 性能代理插件:收集性能数据并保存到本地格式化文本文件,采用文件轮轮循方式,保留最近的秒级性能数据。 强制将引擎从MEMORY转换为InnoDB:如果全局变量rds_force_memory_to_innodb为ON,则创建/修改表时会将表引擎从MEMORY转换为InnoDB。 TDE机制优化:添加keyring-rds插件与管控系统/密钥管理服务进行交互。 TCP错误信息:返回TCP方向(读取、读取等待、写入等待)错误及错误代码到end_connection事件,并且输出错误信息到错误日志。 Bug修复 修复DDL中的意外错误Error 1290。 20190925 参数修改 将系统变量auto_generate_certs的默认值由true改为false。 增加全局只读变量auto_detact_certs,默认值为false,有效值为[true | false]。 该系统变量在Server端使用OpenSSL编译时可用,用于控制Server端在启动时是否在数据目录下自动查找SSL加密证书和密钥文件,即控制是否开启Server端的证书和密钥的自动查找功能。 20190915 新特性 Thread Pool:将线程和会话分离,在拥有大量会话的同时,只需要少量线程完成活跃会话的任务即可。 20190815 新特性 Purge Large File Asynchronously:删除单个表空间时,会将表空间文件重命名为临时文件,等待异步清除进程清理临时文件。 Performance Insight:专注于实例负载监控、关联分析、性能调优的利器,帮助您迅速评估数据库负载,找到性能问题的源头,提升数据库的稳定性。 优化实例锁状态:实例锁定状态下,可以drop或truncate表。 Bug修复 禁止在set rds_current_connection命令中设置rds_prepare_begin_id。 允许更改已锁定用户的信息。 禁止用关键字actual作为表名。 修复慢日志导致时间字段溢出的问题。 20190510版本 新特性:允许在事务内创建临时表。 20190319版本 新特性:支持在handshake报文内代理设置threadID。 20190131版本 升级到官方5.7.25版本。 关闭内存管理功能jemalloc。 修复内部变量net_lenth_size计算错误问题。 20181226版本 新特性:支持动态修改binlog-row-event-max-size,加速无主键表的复制。 修复Proxy实例内存申请异常的问题。 20181010版本 支持隐式主键。 加快无主键表的主备复制。 支持Native AIO,提升I/O性能。 20180431版本 新特性: 支持高可用版。 支持SQL审计。 增强对处于快照备份状态的实例的保护。 MySQL 5.7三节点企业版 20191128 新特性 支持读写分离。 Bug修复 修复部分场景下Follower Second_Behind_Master计算错误问题。 修复表级并行复制事务重试时死锁问题。 修复XA相关bug。 20191016 新特性 支持MySQL 5.7高可用版(本地SSD盘)升级到三节点企业版。 兼容MySQL官方GTID功能,默认不开启。 合并AliSQL MySQL 5.7基础版/高可用版 20190915版本及之前的自研功能。 Bug修复 修复重置备实例导致binlog被关闭问题。 20190909 新特性 优化大事务在三节点强一致状态下的执行效率。 支持从Leader/Follower进行Binlog转储。 支持创建只读实例。 系统表默认使用InnoDB引擎。 Bug修复 修复Follower日志清理命令失效问题。 修复参数slave_sql_verify_checksum=OFF和binlog_checksum=crc32时Slave线程异常退出问题。 20190709 新特性 支持三节点功能。 禁用semi-sync插件。 支持表级并行复制、Writeset并行复制。 支持pk_access主键查询加速。 支持线程池。 合并AliSQL MySQL 5.7基础版/高可用版 20190510版本及之前的自研功能。 MySQL 5.6 20200229 新特性 支持Proxy读写分离功能。 性能优化 优化线程池功能。 优化不同CPU架构下的pause指令执行时间。 Bug修复 修复XA事务部分提交的问题。 20200110 新特性 Thread Pool:将线程和会话分离,在拥有大量会话的同时,只需要少量线程完成活跃会话的任务即可。 性能优化 异步清除文件时继续取消小文件的链接。 Bug修复 修复页面清理程序的睡眠时间计算不正确问题。 修复SELECT @@global.gtid_executed导致的故障转移失败问题。 修复IF CLIENT KILLED AFTER ROLLBACK TO SAVEPOINT PREVIOUS STMTS COMMITTED问题。 20191212 性能优化 删除不必要的tcp错误日志 20191115 Bug修复 修复慢日志时间戳溢出问题。 20191101 Bug修复 修复刷新日志时切换慢日志的问题,仅在执行刷新慢日志时切换慢日志。 修正部分显示错误。 20191015 新特性 轮换慢日志:为了在收集慢查询日志时保证零数据丢失,轮换日志表会将慢日志表的csv数据文件重命名为唯一名称并创建新文件。您可以使用show variables like '%rotate_log_table%';查看是否开启轮换慢日志。 SM4加密算法:添加新的SM4加密算法,取代旧的SM加密算法。 Purge Large File Asynchronously:删除单个表空间时,会将表空间文件重命名为临时文件,等待异步清除进程清理临时文件。 TCP错误信息:返回TCP方向(读取、读取等待、写入等待)错误及错误代码到end_connection事件,并且输出错误信息到错误日志。 引入审计日志缓冲机制,提高审计日志的性能。。 Bug修复 禁用pstack,避免存在大量连接时可能导致pstack无响应。 修复隐式主键与create table as select语句之间的冲突。 自动清除由二进制日志创建的临时文件。 20190815 优化实例锁状态:实例锁定状态下,可以drop或truncate表。 20190130版本 修复部分可能导致系统不稳定的bug。 20181010版本 添加参数rocksdb_ddl_commit_in_the_middle(MyRocks)。如果这个参数被打开,部分DDL在执行过程中将会执行commit操作。 201806** (5.6.16)版本 新特性:slow log精度提升为微秒。 20180426(5.6.16)版本 新特性:引入隐藏索引,支持将索引设置为不可见,详情请参见参考文档。 修复备库apply线程的bug。 修复备库apply分区表更新时性能下降问题。 修复TokuDB下alter table comment重建整张表问题,详情请参见参考文档。 修复由show slave status/show status可能触发的死锁问题。 20171205(5.6.16)版本 修复OPTIMIZE TABLE和ONLINE ALTER TABLE同时执行时会触发死锁的问题。 修复SEQUENCE与隐含主键冲突的问题。 修复SHOW CREATE SEQUENCE问题。 修复TokuDB引擎的表统计信息错误。 修复并行OPTIMIZE表引入的死锁问题。 修复QUERY_LOG_EVENT中记录的字符集问题。 修复信号处理引起的数据库无法停止问题,详情请参见参考文档。 修复RESET MASTER引入的问题。 修复备库陷入等待的问题。 修复SHOW CREATE TABLE可能触发的进程崩溃问题。 20170927(5.6.16)版本 修复TokuDB表查询时使用错误索引问题。 20170901(5.6.16)版本 新特性: 升级SSL加密版本到TLS 1.2,详情请参见参考文档。 支持Sequence。 修复NOT IN查询在特定场景下返回结果集有误的问题。 20170530 (5.6.16)版本 新特性:支持高权限账号Kill其他账号下的连接。 20170221(5.6.16)版本 新特性:支持读写分离简介。 MySQL 5.5 20181212 修复调用系统函数gettimeofday(2) 返回值不准确的问题。该系统函数返回值为时间,常用来计算等待超时,时间不准确时会导致一些操作永不超时。

游客yl2rjx5yxwcam 2020-03-08 13:18:55 0 浏览量 回答数 0

问题

【教程免费下载】 MySQL DBA修炼之道

玄学酱 2019-12-01 22:08:05 2647 浏览量 回答数 1

回答

Java架构师,首先要是一个高级java攻城狮,熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池……    Java反射技术,写框架必备的技术,但是有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是”直接内存”的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。    熟练使用各种数据结构和算法,数组、哈希、链表、排序树…,一句话要么是时间换空间要么是空间换时间,这里展开可以说一大堆,需要有一定的应用经验,用于解决各种性能或业务上的问题。    熟练使用linux操作系统,必备,没什么好说的 。    熟悉tcp协议,创建连接三次握手和断开连接四次握手的整个过程,不了解的话,无法对高并发网络应用做优化; 熟悉http协议,尤其是http头,我发现好多工作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。    系统集群、负载均衡、反向代理、动静分离,网站静态化 。    分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点,适用场景 。    分布式缓存技术memcached,redis,提高系统性能必备,一句话,把硬盘上的内容放到内存里来提速,顺便提个算法一致性hash 。    工具nginx必备技能超级好用,高性能,基本不会挂掉的服务器,功能多多,解决各种问题。    数据库的设计能力,mysql必备,最基础的数据库工具,免费好用,对它基本的参数优化,慢查询日志分析,主从复制的配置,至少要成为半个mysql dba。其他nosql数据库如mongodb。    还有队列中间件。如消息推送,可以先把消息写入数据库,推送放队列服务器上,由推送服务器去队列获取处理,这样就可以将消息放数据库和队列里后直接给用户反馈,推送过程则由推送服务器和队列服务器完成,好处异步处理、缓解服务器压力,解藕系统。   以上纯粹是常用的技术,还有很多自己慢慢去摸索吧;因为要知道的东西很多,所以要成为一名合格的架构师,必须要有强大的自学能力,没有人会手把手的教给你所有的东西。    想成为架构师不是懂了一大堆技术就可以了,这些是解决问题的基础、是工具,不懂这些怎么去提解决方案呢?这是成为架构师的必要条件。    架构师要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格,人家一个几百人用户的系统,访问量不大,数据量小,你给人家上集群、上分布式存储、上高端服务器,为了架构而架构,这是最扯淡的,架构师的作用就是第一满足业务需求,第二最低的硬件网络成本和技术维护成本。    架构师还要根据业务发展阶段,提前预见发展到下一个阶段系统架构的解决方案,并且设计当前架构时将架构的升级扩展考虑进去,做到易于升级;否则等系统瓶颈来了,出问题了再去出方案,或现有架构无法扩展直接扔掉重做,或扩展麻烦问题一大堆,这会对企业造成损失。Java架构师学习路线图如:https://yq.aliyun.com/articles/225941?spm=5176.8091938.0.0.qyp0tC

zwt9000 2019-12-02 00:25:32 0 浏览量 回答数 0

回答

据说oschina使用的缓存###### 不一定要完全静态化吧,像楼上说的 可以使用缓存,VIEW层可以使用velocity ######不是说从硬件、软件、技术多方面做提升了,我看有一公司页面全是用的freemark的ftl模板代替的jsp页面,用他们的话来说,ftl要比jsp快,不知道真的是不是这样######不是说ftl的性能比jsp快。是指开发速度。另外对于一个大型的系统来讲。那点性能已经不重要的。后期的性能调优做好。没有问题的。而且对于模板的渲染,即使慢了。加几台机器的问题而已。######对你目前的情况,缓存是最好的方式。######静态化是一个大坑,而且很多人愿意去踩###### 好吧。我也吹一下牛逼了。我给自己写了一个cms小网站,因为系统是512m的单核。安装了tomcat,mysql,java,ftp,包括操作系统。 内存实在不多。 经过了些优化。大概如下: http://www.52menshao.com/content/1051 希望对你有帮助。 ######你可以把静态化,放到最后一步来做。 比如可以先进行一些cdn操作,常用数据缓存,服务器压缩等等。静态化确实非常好,但咱也得先看看问题出在哪才是。

kun坤 2020-05-29 10:46:30 0 浏览量 回答数 0

问题

最佳实践 -MySQL-MySQL实例参数调优参考

李沃晟 2019-12-01 21:40:06 611 浏览量 回答数 0

问题

九个衡量Rails应用性能的小方法

doudou1 2019-12-01 22:09:09 9032 浏览量 回答数 1

问题

九个衡量Rails应用性能的小方法

sunny夏筱 2019-12-01 21:43:43 7571 浏览量 回答数 3

问题

【每日一题】Java知识大测验 | 持续更新

游客ih62co2qqq5ww 2020-06-09 13:59:02 233 浏览量 回答数 2

回答

一、基础篇 1.1、Java基础 面向对象的特征:继承、封装和多态 final, finally, finalize 的区别 Exception、Error、运行时异常与一般异常有何异同 请写出5种常见到的runtime exception int 和 Integer 有什么区别,Integer的值缓存范围 包装类,装箱和拆箱 String、StringBuilder、StringBuffer 重载和重写的区别 抽象类和接口有什么区别 说说反射的用途及实现 说说自定义注解的场景及实现 HTTP请求的GET与POST方式的区别 Session与Cookie区别 列出自己常用的JDK包 MVC设计思想 equals与==的区别 hashCode和equals方法的区别与联系 什么是Java序列化和反序列化,如何实现Java序列化?或者请解释Serializable 接口的作用 Object类中常见的方法,为什么wait notify会放在Object里边? Java的平台无关性如何体现出来的 JDK和JRE的区别 Java 8有哪些新特性 1.2、Java常见集合 List 和 Set 区别 Set和hashCode以及equals方法的联系 List 和 Map 区别 Arraylist 与 LinkedList 区别 ArrayList 与 Vector 区别 HashMap 和 Hashtable 的区别 HashSet 和 HashMap 区别 HashMap 和 ConcurrentHashMap 的区别 HashMap 的工作原理及代码实现,什么时候用到红黑树 多线程情况下HashMap死循环的问题 HashMap出现Hash DOS攻击的问题 ConcurrentHashMap 的工作原理及代码实现,如何统计所有的元素个数 手写简单的HashMap 看过那些Java集合类的源码 1.3、进程和线程 线程和进程的概念、并行和并发的概念 创建线程的方式及实现 进程间通信的方式 说说 CountDownLatch、CyclicBarrier 原理和区别 说说 Semaphore 原理 说说 Exchanger 原理 ThreadLocal 原理分析,ThreadLocal为什么会出现OOM,出现的深层次原理 讲讲线程池的实现原理 线程池的几种实现方式 线程的生命周期,状态是如何转移的 可参考:《Java多线程编程核心技术》 1.4、锁机制 说说线程安全问题,什么是线程安全,如何保证线程安全 重入锁的概念,重入锁为什么可以防止死锁 产生死锁的四个条件(互斥、请求与保持、不剥夺、循环等待) 如何检查死锁(通过jConsole检查死锁) volatile 实现原理(禁止指令重排、刷新内存) synchronized 实现原理(对象监视器) synchronized 与 lock 的区别 AQS同步队列 CAS无锁的概念、乐观锁和悲观锁 常见的原子操作类 什么是ABA问题,出现ABA问题JDK是如何解决的 乐观锁的业务场景及实现方式 Java 8并法包下常见的并发类 偏向锁、轻量级锁、重量级锁、自旋锁的概念 可参考:《Java多线程编程核心技术》 1.5、JVM JVM运行时内存区域划分 内存溢出OOM和堆栈溢出SOE的示例及原因、如何排查与解决 如何判断对象是否可以回收或存活 常见的GC回收算法及其含义 常见的JVM性能监控和故障处理工具类:jps、jstat、jmap、jinfo、jconsole等 JVM如何设置参数 JVM性能调优 类加载器、双亲委派模型、一个类的生命周期、类是如何加载到JVM中的 类加载的过程:加载、验证、准备、解析、初始化 强引用、软引用、弱引用、虚引用 Java内存模型JMM 1.6、设计模式 常见的设计模式 设计模式的的六大原则及其含义 常见的单例模式以及各种实现方式的优缺点,哪一种最好,手写常见的单利模式 设计模式在实际场景中的应用 Spring中用到了哪些设计模式 MyBatis中用到了哪些设计模式 你项目中有使用哪些设计模式 说说常用开源框架中设计模式使用分析 动态代理很重要!!! 1.7、数据结构 树(二叉查找树、平衡二叉树、红黑树、B树、B+树) 深度有限算法、广度优先算法 克鲁斯卡尔算法、普林母算法、迪克拉斯算法 什么是一致性Hash及其原理、Hash环问题 常见的排序算法和查找算法:快排、折半查找、堆排序等 1.8、网络/IO基础 BIO、NIO、AIO的概念 什么是长连接和短连接 Http1.0和2.0相比有什么区别,可参考《Http 2.0》 Https的基本概念 三次握手和四次挥手、为什么挥手需要四次 从游览器中输入URL到页面加载的发生了什么?可参考《从输入URL到页面加载发生了什么》 二、数据存储和消息队列 2.1、数据库 MySQL 索引使用的注意事项 DDL、DML、DCL分别指什么 explain命令 left join,right join,inner join 数据库事物ACID(原子性、一致性、隔离性、持久性) 事物的隔离级别(读未提交、读以提交、可重复读、可序列化读) 脏读、幻读、不可重复读 数据库的几大范式 数据库常见的命令 说说分库与分表设计 分库与分表带来的分布式困境与应对之策(如何解决分布式下的分库分表,全局表?) 说说 SQL 优化之道 MySQL遇到的死锁问题、如何排查与解决 存储引擎的 InnoDB与MyISAM区别,优缺点,使用场景 索引类别(B+树索引、全文索引、哈希索引)、索引的原理 什么是自适应哈希索引(AHI) 为什么要用 B+tree作为MySQL索引的数据结构 聚集索引与非聚集索引的区别 遇到过索引失效的情况没,什么时候可能会出现,如何解决 limit 20000 加载很慢怎么解决 如何选择合适的分布式主键方案 选择合适的数据存储方案 常见的几种分布式ID的设计方案 常见的数据库优化方案,在你的项目中数据库如何进行优化的 2.2、Redis Redis 有哪些数据类型,可参考《Redis常见的5种不同的数据类型详解》 Redis 内部结构 Redis 使用场景 Redis 持久化机制,可参考《使用快照和AOF将Redis数据持久化到硬盘中》 Redis 集群方案与实现 Redis 为什么是单线程的? 缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级 使用缓存的合理性问题 Redis常见的回收策略 2.3、消息队列 消息队列的使用场景 消息的重发补偿解决思路 消息的幂等性解决思路 消息的堆积解决思路 自己如何实现消息队列 如何保证消息的有序性 三、开源框架和容器 3.1、SSM/Servlet Servlet的生命周期 转发与重定向的区别 BeanFactory 和 ApplicationContext 有什么区别 Spring Bean 的生命周期 Spring IOC 如何实现 Spring中Bean的作用域,默认的是哪一个 说说 Spring AOP、Spring AOP 实现原理 动态代理(CGLib 与 JDK)、优缺点、性能对比、如何选择 Spring 事务实现方式、事务的传播机制、默认的事务类别 Spring 事务底层原理 Spring事务失效(事务嵌套),JDK动态代理给Spring事务埋下的坑,可参考《JDK动态代理给Spring事务埋下的坑!》 如何自定义注解实现功能 Spring MVC 运行流程 Spring MVC 启动流程 Spring 的单例实现原理 Spring 框架中用到了哪些设计模式 Spring 其他产品(Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等) 有没有用到Spring Boot,Spring Boot的认识、原理 MyBatis的原理 可参考《为什么会有Spring》 可参考《为什么会有Spring AOP》 3.2、Netty 为什么选择 Netty 说说业务中,Netty 的使用场景 原生的 NIO 在 JDK 1.7 版本存在 epoll bug 什么是TCP 粘包/拆包 TCP粘包/拆包的解决办法 Netty 线程模型 说说 Netty 的零拷贝 Netty 内部执行流程 Netty 重连实现 3.3、Tomcat Tomcat的基础架构(Server、Service、Connector、Container) Tomcat如何加载Servlet的 Pipeline-Valve机制 可参考:《四张图带你了解Tomcat系统架构!》 四、分布式 4.1、Nginx 请解释什么是C10K问题或者知道什么是C10K问题吗? Nginx简介,可参考《Nginx简介》 正向代理和反向代理. Nginx几种常见的负载均衡策略 Nginx服务器上的Master和Worker进程分别是什么 使用“反向代理服务器”的优点是什么? 4.2、分布式其他 谈谈业务中使用分布式的场景 Session 分布式方案 Session 分布式处理 分布式锁的应用场景、分布式锁的产生原因、基本概念 分布是锁的常见解决方案 分布式事务的常见解决方案 集群与负载均衡的算法与实现 说说分库与分表设计,可参考《数据库分库分表策略的具体实现方案》 分库与分表带来的分布式困境与应对之策 4.3、Dubbo 什么是Dubbo,可参考《Dubbo入门》 什么是RPC、如何实现RPC、RPC 的实现原理,可参考《基于HTTP的RPC实现》 Dubbo中的SPI是什么概念 Dubbo的基本原理、执行流程 五、微服务 5.1、微服务 前后端分离是如何做的? 微服务哪些框架 Spring Could的常见组件有哪些?可参考《Spring Cloud概述》 领域驱动有了解吗?什么是领域驱动模型?充血模型、贫血模型 JWT有了解吗,什么是JWT,可参考《前后端分离利器之JWT》 你怎么理解 RESTful 说说如何设计一个良好的 API 如何理解 RESTful API 的幂等性 如何保证接口的幂等性 说说 CAP 定理、BASE 理论 怎么考虑数据一致性问题 说说最终一致性的实现方案 微服务的优缺点,可参考《微服务批判》 微服务与 SOA 的区别 如何拆分服务、水平分割、垂直分割 如何应对微服务的链式调用异常 如何快速追踪与定位问题 如何保证微服务的安全、认证 5.2、安全问题 如何防范常见的Web攻击、如何方式SQL注入 服务端通信安全攻防 HTTPS原理剖析、降级攻击、HTTP与HTTPS的对比 5.3、性能优化 性能指标有哪些 如何发现性能瓶颈 性能调优的常见手段 说说你在项目中如何进行性能调优 六、其他 6.1、设计能力 说说你在项目中使用过的UML图 你如何考虑组件化、服务化、系统拆分 秒杀场景如何设计 可参考:《秒杀系统的技术挑战、应对策略以及架构设计总结一二!》 6.2、业务工程 说说你的开发流程、如何进行自动化部署的 你和团队是如何沟通的 你如何进行代码评审 说说你对技术与业务的理解 说说你在项目中遇到感觉最难Bug,是如何解决的 介绍一下工作中的一个你认为最有价值的项目,以及在这个过程中的角色、解决的问题、你觉得你们项目还有哪些不足的地方 6.3、软实力 说说你的优缺点、亮点 说说你最近在看什么书、什么博客、在研究什么新技术、再看那些开源项目的源代码 说说你觉得最有意义的技术书籍 工作之余做什么事情、平时是如何学习的,怎样提升自己的能力 说说个人发展方向方面的思考 说说你认为的服务端开发工程师应该具备哪些能力 说说你认为的架构师是什么样的,架构师主要做什么 如何看待加班的问题

徐刘根 2020-03-31 11:22:08 0 浏览量 回答数 0

回答

与MyISAM表不同,InnoDB表不会跟踪该表包含多少行。 因此,知道InnoDB表中确切行数的唯一方法是检查表中的每一行并累加一个计数。因此,在大型InnoDB表上,执行SELECT COUNT(*) FROM innodb_table查询的速度可能非常慢,因为它会进行全表扫描以获取行数。 phpMyAdmin使用查询SHOW TABLE STATUS来从引擎(InnoDB)获取表中行数的估计计数。由于这只是估计,因此每次您调用它时都会有所不同,有时差异可能会很大,有时甚至很接近。 这是Percona 关于InnoDB表的COUNT(*)的内容丰富的博客文章。 显示表状态的MySQL手册页指出: 行数。某些存储引擎(例如MyISAM)存储准确的计数。对于其他存储引擎,例如InnoDB,此值是一个近似值,可能与实际值相差40%至50%。在这种情况下,请使用SELECT COUNT(*)获得准确的计数。 有关InnoDB限制的页面会更加详细: 除表保留的物理大小外,SHOW TABLE STATUS不会提供有关InnoDB表的准确统计信息。行数只是SQL优化中使用的粗略估计。 InnoDB不保留表中行的内部计数,因为并发事务可能同时“看到”不同数量的行。为了处理一条SELECT COUNT(*) FROM t语句,InnoDB扫描表的索引,如果索引不完全在缓冲池中,则将花费一些时间。如果您的表不经常更改,那么使用MySQL查询缓存是一个很好的解决方案。为了快速计数,您必须使用自己创建的计数器表,并让您的应用程序根据插入和删除它来对其进行更新。如果大约有足够的行数,SHOW TABLE STATUS则可以使用。请参见第14.3.14.1节“ InnoDB性能调优技巧”。来源:stack overflow

保持可爱mmm 2020-05-11 13:49:05 0 浏览量 回答数 0

问题

关于apache ab性能测试指标问题

落地花开啦 2019-12-01 19:41:14 1394 浏览量 回答数 1

问题

【技术干货】阿里云构建千万级别架构演变之路

驻云科技 2019-12-01 21:14:19 6333 浏览量 回答数 5

问题

Centos 系统优化思路整理

holdb 2019-12-01 22:03:44 8681 浏览量 回答数 5

问题

DBA专家门诊一期:索引与sql优化

xiaofanqie 2019-12-01 21:22:17 27123 浏览量 回答数 29

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

回答

解决了吗?感觉是版本的问题 ######请问楼主解决了吗?我现在也遇到了相同的问题######这个是由于当时IK分词器还不支持solr5.3版本。现在百度已经能找到solr5.3版本下的ik分词器代码了。######https://github.com/EugenePig/ik-analyzer-solr5   下载这个 然后直接编译 按照reademe 的说明配置即可######基于微博数据检测的Solr实战开发 课程观看地址: http://www.xuetuwuyou.com/course/145 课程出自学途无忧网: http://www.xuetuwuyou.com solrcloud5.2.1+zookeeper一部精通 课程观看地址: http://www.xuetuwuyou.com/course/15 一、课程用到的软件 1.centos6.7 2.apache-tomcat-7.0.47 3.solr-5.5 4.zookeeper 3.4.6 5.eclipse-jee-neon-R-win32-x86_64  二、课程目标 在海量数据的情况下,传统的关系型数据库已经力不从心,快速检索已经成为了应用系统所必备的功能之一。本课程从实战角度出发,让学员能从实战中学习到: 搜索引擎的原理及架构。  掌握在大数据环境下经典检索算法。  掌握如何使用solr实现系统快速检索目标。  掌握solr在开发中常见的技术大坑与调优技术。 三、适用人群 开发人员、架构师、对分布式搜索引擎有兴趣的朋友。 四、课程内容介绍: 第1课、Solr简介与部署     知识点:Solr基本概念以及应用的介绍、Solr单机版的搭建 第2课、Solr建库实战     知识点:介绍managed-schame和solrConfig两大配置文件,并建立Solr库开始实操 第3课、Solr中文分词器与全量数据导入     知识点:对比中文分词器IK与MMSeg4j的特点、Solr配置MMSeg4j中文分词器、把Mysql中的数据导入到Solr索引库上 第4课、Solr增量数据导入及新管理UI实战     知识点:把Mysql的数据增量导入到Solr索引库上、对Solr5最新的UI进行全面介绍 第5课、Solr数据查询详解     知识点:基于UI管理界面,实战Solr q查询、fq查询以及分页、高亮、Facet等高级特性的使用 第6课、Solrj编程实战之索引增删改     知识点:基于Eclipse开发环境、搭建Solrj工程项目,对Solr的索引库的进行增、删、改的操作 第7课、Solrj编程实战之索引查询与分页     知识点:基于Solrj实现q查询、fq查询以及分页查询的操作 第8课、Solrj编程实战之高亮与Facet     知识点:基于Solrj实现高亮查询、Facet查询的操作 第9课、Solrj编程实战之设计模式     知识点:基于前阶段所写的代码,发现代码中的不足,并使用单例模式、模块方法、回调方法的设计模式进行仿Spring Data的开发 第10课、Solr缓存与预热机制剖析     知识点:从算法、应用场景以及实例的多个维度,剖析Solr中的四大缓存,并且站在SolrIndexSearcher的生命周期上解剖预热机制及其注意事项 第11课、Solr高级特性之近实时、实时检索     知识点:从概念、原理以及实例的多个维度,剖析Solr近实时、实时检索 第12课、Solr高级特性之原子更新     知识点:Solr在应用层面上对Lucene进行了封装,在Solr4之后提出了原子更新的新概念,从此在应用层面操作上方便我们进行索引更新 第13课、Solr高级特性之深度分页及性能调优     知识点:Solr4的又一大特性,在面临海量据的情况下,占用更低的资源进行数据检索正是深度分页的一大亮点、后半节结合讲师的实际开发经验,分享Solr性能调优的策略 第14课、SolrCloud部署运维之集群搭建     知识点:基于Centos、zookeeper环境下,搭建SolrCloud系统  第15课、SolrCloud部署运维之库管理     知识点:SolrCloud的运维之道,从UI管理界面以及命令行的两个维度去剖析SolrCloud库的管理,包括库的新增、删除以及动态更新  第16课、SolrCloud部署运维之副本与扩容     知识点:SolrCloud的运维之道,从UI管理界面以及命令行的两个维度去剖析SolrCloud分片的管理,包括分片的备份与库的扩容 第17课、中文分词器配置与使用Solrj操作SolrCloud     知识点:配置中文分词器以及使用Solrj操作SolrCloud来实现增、删、改、查  第18课、项目介绍与环境搭建     知识点:介绍项目的背景以及总体架构、突出Solr在实际项目中的角色。基于Maven搭建开发环境  第19课、框架代码开发之Spring集成Solrj之CRUD(maven版)     知识点:Spring是一个JavaEE企业级框架,它很多主流的主件都进行集成支持。本节学习Spring与Solrj的集成,进行增、删、改、查操作 第20课、框架代码开发之Spring集成Solrj之(maven版)     知识点:Spring是一个JavaEE企业级框架,它对很多主流的组件都进行集成支持。本节学习Spring与Solrj的集成,进行实时检索、高亮、深度分页、Facet查询操作 第21课、基于dom4j的导库组件开发(maven版)     知识点:基于dom4j解析XML文件,并将数据批量高效导入到SolrCloud分布式索引库上进行检索分析 第22课、高级检索组件开发一     知识点:基于SolrCloud实现高级检索,包括多条件查询、高亮、分页操作 第23课、高级检索组件开发二         知识点:基于SolrCloud实现高级检索,包括多条件查询、高亮、分页操作 第24课、相似匹配组件开发一     知识点:基于SolrCloud实现相似性检索操作 第25课、相似匹配组件开发二     知识点:基于SolrCloud实现相似性检索操作 第26课、课程总结与Solr6的展望     知识点:课程大总结,并对最新版的Solr6进行亮点分析以及未来的展望

kun坤 2020-06-01 09:57:39 0 浏览量 回答数 0

问题

运维人员处理云服务器故障方法七七云转载

杨经理 2019-12-01 22:03:10 9677 浏览量 回答数 2

回答

Performance Insight是专注于实例负载监控、关联分析、性能调优的利器,帮助您迅速评估数据库负载,找到性能问题的源头,提升数据库的稳定性。 前提条件 实例版本如下: MySQL 8.0 MySQL 5.7 内核小版本需要为20190915或以上。 说明 您可以在基本信息页面的配置信息区域查看是否有升级内核小版本按钮。如果有按钮,您可以单击按钮查看当前版本;如果没有按钮,表示已经是最新版。详情请参见升级内核小版本。 Performance Insight介绍 Performance Insight由如下两部分组成: Object statistics Object statistics查询表和索引的统计信息,包括如下两个表: TABLE_STATISTICS:记录读取和修改的行。 INDEX_STATISTICS:记录索引的读取行。 Performance point Performance point提供实例的详细性能信息,方便您更快更准确地量化SQL的开销。Performance point包括如下三个维度: CPU:包括执行任务的总时间(Elapsed time)、CPU执行任务的时间(CPU time)等。 LOCK:包括服务器MDL锁时间、存储事务锁时间、互斥冲突(仅调试模式)、读写锁冲突等。 IO:数据文件读写时间、日志文件写入时间、逻辑读取、物理读取、物理异步读取等。 Object statistics使用方法 确认参数OPT_TABLESTAT和OPT_INDEXSTAT的值为ON。示例如下: mysql> show variables like "opt_%_stat"; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | opt_indexstat | ON | | opt_tablestat | ON | +---------------+-------+ 说明 如果参数找不到或参数值不为ON,请确认您的实例版本是否为MySQL 5.7。 在information_schema数据库查询TABLE_STATISTICS表或INDEX_STATISTICS表,查看表和索引的统计信息。示例如下: mysql> select * from TABLE_STATISTICS limit 10; +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+ | TABLE_SCHEMA | TABLE_NAME | ROWS_READ | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES | ROWS_INSERTED | ROWS_DELETED | ROWS_UPDATED | +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+ | mysql | db | 2 | 0 | 0 | 0 | 0 | 0 | | mysql | engine_cost | 2 | 0 | 0 | 0 | 0 | 0 | | mysql | proxies_priv | 1 | 0 | 0 | 0 | 0 | 0 | | mysql | server_cost | 6 | 0 | 0 | 0 | 0 | 0 | | mysql | tables_priv | 2 | 0 | 0 | 0 | 0 | 0 | | mysql | user | 7 | 0 | 0 | 0 | 0 | 0 | | test | sbtest1 | 1686 | 142 | 184 | 112 | 12 | 18 | | test | sbtest10 | 1806 | 125 | 150 | 105 | 5 | 15 | | test | sbtest100 | 1623 | 141 | 182 | 110 | 10 | 21 | | test | sbtest11 | 1254 | 136 | 172 | 110 | 10 | 16 | +--------------+--------------+-----------+--------------+------------------------+---------------+--------------+--------------+ mysql> select * from INDEX_STATISTICS limit 10; +--------------+--------------+------------+-----------+ | TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | ROWS_READ | +--------------+--------------+------------+-----------+ | mysql | db | PRIMARY | 2 | | mysql | engine_cost | PRIMARY | 2 | | mysql | proxies_priv | PRIMARY | 1 | | mysql | server_cost | PRIMARY | 6 | | mysql | tables_priv | PRIMARY | 2 | | mysql | user | PRIMARY | 7 | | test | sbtest1 | PRIMARY | 2500 | | test | sbtest10 | PRIMARY | 3007 | | test | sbtest100 | PRIMARY | 2642 | | test | sbtest11 | PRIMARY | 2091 | +--------------+--------------+------------+-----------+ 参数说明如下。 参数 说明 TABLE_SCHEMA 数据库名称。 TABLE_NAME 表名称。 ROWS_READ 读的行数。 ROWS_CHANGED 修改的行数。 ROWS_CHANGED_X_INDEXES 索引修改的行数。 ROWS_INSERTED 插入的行数。 ROWS_DELETED 删除的行数。 ROWS_UPDATED 更新的行数。 INDEX_NAME 索引名称。 Performance point使用方法 确认Performance point的相关参数。正常的示例如下: mysql> show variables like "%performance_point%"; +---------------------------------------+-------+ | Variable_name | Value | +---------------------------------------+-------+ | performance_point_dbug_enabled | OFF | | performance_point_enabled | ON | | performance_point_iostat_interval | 2 | | performance_point_iostat_volume_size | 10000 | | performance_point_lock_rwlock_enabled | ON | +---------------------------------------+-------+ 说明 如果参数找不到,请确认您的实例版本是否为MySQL 5.7。 在performance_schema数据库查询events_statements_summary_by_digest_supplement表,查看排名前10的SQL语句。示例如下: mysql> select * from events_statements_summary_by_digest_supplement limit 10; +--------------------+----------------------------------+-------------------------------------------+--------------+ | SCHEMA_NAME | DIGEST | DIGEST_TEXT | ELAPSED_TIME | ...... +--------------------+----------------------------------+-------------------------------------------+--------------+ | NULL | 6b787dd1f9c6f6c5033120760a1a82de | SELECT @@version_comment LIMIT ? | 932 | | NULL | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS | 2363 | | NULL | 8a93e76a7846384621567fb4daa1bf95 | SHOW VARIABLES LIKE ? | 17933 | | NULL | dd148234ac7a20cb5aee7720fb44b7ea | SELECT SCHEMA ( ) | 1006 | | information_schema | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS | 2156 | | information_schema | 74af182f3a2bd265678d3dadb53e08da | SHOW TABLES | 3161 | | information_schema | d3a66515192fcb100aaef6f8b6e45603 | SELECT * FROM TABLE_STATISTICS LIMIT ? | 2081 | | information_schema | b3726b7c4c4db4b309de2dbc45ff52af | SELECT * FROM INDEX_STATISTICS LIMIT ? | 2384 | | information_schema | dd148234ac7a20cb5aee7720fb44b7ea | SELECT SCHEMA ( ) | 129 | | test | 2fb4341654df6995113d998c52e5abc9 | SHOW SCHEMAS | 342 | +--------------------+----------------------------------+-------------------------------------------+--------------+ 参数说明如下。 参数 说明 SCHEMA_NAME 数据库名称。 DIGEST Digest_text进行hash计算得到的64字节的hash字符串。 DIGEST_TEXT SQL语句的特征。 ELAPSED_TIME 实际运行时间。单位:μs。 CPU_TIME CPU运行时间。单位:μs。 SERVER_LOCK_TIME 服务器锁定时间。单位:μs。 TRANSACTION_LOCK_TIME 存储事务锁定时间。单位:μs。 MUTEX_SPINS 互斥旋转次数。 MUTEX_WAITS 互斥等待次数。 RWLOCK_SPIN_WAITS 读写闩锁的自旋等待数。 RWLOCK_SPIN_ROUNDS 读写闩锁的旋转循环圈数。 RWLOCK_OS_WAITS 读写闩锁的操作系统等待数。 DATA_READS 数据文件读取次数。 DATA_READ_TIME 数据文件读取时间。单位:μs。 DATA_WRITES 数据文件写入次数。 DATA_WRITE_TIME 数据文件写入时间。单位:μs。 REDO_WRITES 日志文件写入次数。 REDO_WRITE_TIME 日志文件写入时间。单位:μs。 LOGICAL_READS 逻辑页读取次数。 PHYSICAL_READS 物理页读取次数。 PHYSICAL_ASYNC_READS 物理异步页读取次数。 在information_schema数据库查询IO_STATISTICS表,查看最近的数据读写情况。示例如下: mysql> select * from IO_STATISTICS limit 10; +---------------------+-----------+----------------+ | TIME | DATA_READ | DATA_READ_TIME | ...... +---------------------+-----------+----------------+ | 2019-08-08 09:56:53 | 73 | 983 | | 2019-08-08 09:56:57 | 0 | 0 | | 2019-08-08 09:59:17 | 0 | 0 | | 2019-08-08 10:00:55 | 4072 | 40628 | | 2019-08-08 10:00:59 | 0 | 0 | | 2019-08-08 10:01:09 | 562 | 5800 | | 2019-08-08 10:01:11 | 606 | 6910 | | 2019-08-08 10:01:13 | 609 | 6875 | | 2019-08-08 10:01:15 | 625 | 7077 | | 2019-08-08 10:01:17 | 616 | 5800 | +---------------------+-----------+----------------+ 参数说明如下。 参数 说明 TIME 日期。 DATA_READ 数据读取次数。 DATA_READ_TIME 数据读取总时间。单位:μs。 DATA_READ_MAX_TIME 数据读取最长时间。单位:μs。 DATA_READ_BYTES 数据读取总大小。单位:byte。 DATA_WRITE 数据写入次数。 DATA_WRITE_TIME 数据写入总时间。单位:μs。 DATA_WRITE_MAX_TIME 数据写入最长时间。单位:μs。 DATA_WRITE_BYTES 数据写入总大小。单位:byte。

游客yl2rjx5yxwcam 2020-03-08 13:34:03 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播