今天来说说两款压测工具sysbench,swingbench,早些时候傻傻分不清楚,其实两个差别大了去了。 swingbench 先来说说swingbench,这款工具是Oracle英国的一个员工用Java开发的，没想到一下子成了压测Oracle的不二之选。当然Oracle还有不少这样的工具，比如DUL（Data UnLoader）,是新西兰的一个员工用c开发，一个可以直接读取数据文件的工具，基本是ACS部门在提供高级服务所用。还有一款是SQLT也叫作SQLTXPLAIN，是Oracle Serv
今天抽时间在整理一个关于MySQL和Oracle共同面临的问题，但是它们有着不同的解决方案，就是经典的partial write问题，我也看到网上有很多DBA在纠结，在争论，相比而言，Oracle这边更沉默一些。我认真看了他们的讨论，但是到目前为止没有看到一个把两方面都照顾到的解读，而且这个问题可以继续扩展开来，从存储层面也可以有一些解读，所以我决定做这个事情。至于文章最近应该会从社群中看到，对于内容，我还是抱着谨慎的态度，想让几位朋友审阅之后再说会比较好。如果你对此有一定的基础，对此有浓厚的兴趣，也
我们可以使用swingbench这个工具对数据库性能进行压力测试，得到一些性能指标作为参考。 SwingBench下载： http://www.dominicgiles.com/downloads.html
之前也分享过一篇关于swingbench测试Oracle的文章，图形工具和命令行的博弈-swingbench配置(r8笔记第63天)，也算是一个起步了。 新业务要上线，不跑个压力测试还真说不过去，当然对于Oracle压测我比较喜欢swingbench的一点就是它可以模拟一些OLTP的场景，比如订单类业务，新建客户，订购，下单等这样一个流程的操作算是一个模拟真实的事务。 当然swingbench还有几个地方做得挺有特色，一个是我们压力测试是指定数据量，比如1G,5G,100G,初始化数据就
对于图形工具，很多人都会抱有一种不太理性的想法，感觉只要一图形界面就失去技术含量，图形能点点的东西，操作太容易，太简单就没有技术含量。 我有时候就有些矛盾，但是可以这样理解，图形工具本身就是解放哪些复杂的工作的，图形工具如果还不好用，那要手工处理复杂的工作就更不太实际了。 而我们是使用工具，创造工具的专业人士，如果在图形的使用上更上一个层次，这个时候命令行我认为是比图形好的。打个比方，因为我们工作的环境限制，所有的 客户环境都是要跳n多个代理，网段，最后才能登陆到客户的线上环境，使用图形工具是根本不现实的，
今天在地铁上，一直在琢磨高可用测试的一些补充场景，除了功能之外，就是一些异常场景的考虑，总之，能想到可能发生的任何场景，然后和实际应用场景结合起来，给出对策，我觉得就是一个相对比较完善的测试预期了。 但是高可用测试，性能基线测试，中间件测试，这些说白了都是测试，提出方案给出测试计划和方案，这不可厚非，但是我感觉不对，这些场景的一个关键词都是测试。 相比于测试，很多开发同学都会有一种优越感，有没有，要不要我不评价，但是优越感爆棚了就有问题了，比如前几天看到有些所谓的大牛在说，只有那些年薪3
OGG有传统的经典架构，也有最新的微服务，2个都可以远程捕获和应用数据，对数据库服务器是0侵入，而传统的经典架构是纯命令行模式，最新的微服务架构是图形化界面操作，几乎所有操作都可以在界面进行。相关文章可以参考：
即将上线的数据库如何来评估其性能呢，swingbench是除了Benchmark Factory for Databases的不二之选，可以用短小精悍来形容，而且完全免费，也不用成天到晚google注册码，还等什么呢，赶紧来瞧瞧......
Oracle Data Guard对归档的传输提供了很多辅助的选项，这个可 以通过log_archive_dest_x看到。 一般说这类的优化，如果有大批量的归档需要传输，对于网络带宽还真是一个不小的冲击，有一种改进方法，就是打包压缩归档，然后传输到备库，然后解压应用，整个过程有几个地方需要注意，整个过程肯定会有延迟，而且还不小，在压缩和解压的过程对系统资源会有一个持续的耗用。而好处也相对明显很多，就是对于带宽的占用会有一定的压缩。所以一句话总结，如果压缩备份，对系统会有额外的资源消耗，节约流量
在有些场景下，图形模式可能本身消耗资源过大，尤其在生成大量测试数据时，很可能会由于图形本身的不稳定导致卡死甚至直接中途退出，严重影响效率和测试体验。 而如果采用静默模式，直接使用xml编辑又不能很好的确认改的是否正确。 本文主要介绍下我在做某次压力测试时发现的小技巧。
昨天对Data Guard的归档压缩进行了一个初步的测试，我今天又做了一些补充。 1.昨天测试的是默认50M的redo，如果redo增大，在IO bound的场景中，是否有很大的变化 2.对于归档压缩来说，数据量如果增大，是否会有较大的抖动，昨天测试的是20G的数据量，初始化了50% 3.对于整个数据初始化的过程中，主备的延迟到底有多大，是否有延迟回落的现象。 我们一个一个来做解答。 首先是redo的大小调整，我们需要设置redo大小为200M,备库的standby logfile也
更换某个数据库进行各种前期的测试和比对是非常正常的事情，但是再正常的事情中，可以包含无数的你意料以外的事情，今天就所说最近遇到了一次有意思的数据库测试POC中的问题。
CDB现在支持类型复制类型比较多，我这里选择以下几种复制类型压测对比： MySQL 5.6[异步|半同步|增强半同步]复制，5.7异步复制（当时5.7只支持异步复制).
最近看到一句话是MySQL的TPS是4000，这句话是不严谨的，因为没有说服务器的配置。所以自己买了个服务器做了一个压测。希望自己对数据有一个概念。 注意：服务器不同结果不同，结果不具有普适性。
mysql数据库已经没得连接了, 却使用了超过 80%的内存...., 导致其它应用没得内存用了, 触发了os的oom....
中间件dble测试成员，主要负责dble的日常测试工作，热衷于探索发现，学习新技术。
某项目压测后发现qps达标，服务器cpu和内存占用均在70%以下，然而mysql服务的内存占用高达100%，且并没有因为压测而产生波动。
在前面的压力测试过程中，主要关注的是对接口以及服务器硬件性能进行压力测试，评估请求接口和硬件性能对服务的影响。但是对于多数Web应用来说，整个系统的瓶颈在于数据库。
计划今年将数据库服务器的os 从centos 6 升级到centos 7,根据惯例,升级之前我们要进行一次性能压测。本文分享一下我们的压测记录和结果。
MySQL性能压测或者基准测试看起来很简单，使用sysbench，tpcc工具跑跑拿到数据就好，其实压测是一个技术活儿，尤其是涉及到性能对比的测试，因为不同场景/不同厂商的产品的参数设置不同，测试的结果也不一样。如果不阐明具体的参数配置差异，直接给出压测结果可能给其他人带来误导。
本节内容讲述线上的调优手段以及压力测试的相关工具，结合一些实际的命令参数，我们将会介绍运行结果的具体含义。本节内容为大致的介绍如何压力测试和如何阅读参数，具体的运行效果需要自己部署一台机器测试，关于这部分的内容受到不同的机器影响会出现完全不同的效果，需要实际测试所以没有进行记录。
BenchmarkSQL 是一个支持众多关系型数据库的基准测试工具，通过使用 BenchmarkSQL 对数据库进行 TPC-C 标准测试，即模拟多种事务处理：新订单、支付操作、订单状态查询、发货、库存状态查询等，从而获得最终的压测值。相较于 Sysbench 的单一，它更能贴切的模拟出真实的应用场景，因此越来越多的客户在对数据库进行压测时，更多的选择使用 BenchmarkSQL 。
在经历了惨痛的黑天鹅事件以及激烈的数据恢复过程后，作为微盟DBA的我们进行了深刻的反省和自查，作为公司的核心资产，数据库也得到了前所未有的重视。如何保证数据安全以及用户服务的高可用性是我们要解决的首要问题。
在本节中，我们对VMware FT在一些应用工作负载和网络基准方面的性能做了基本评估。对于这些结果，我们在相同的服务器上运行主虚拟机和备份虚拟机，每台服务器有8个英特尔至强2.8Ghz CPU和8G字节的内存。这些服务器通过一个10Gbit/s的交叉网络连接，尽管在所有情况下都会看到，使用的网络带宽远低于1Gbit/s。两台服务器通过一个标准的4Gbit/s光纤通道网络连接的EMC Clariion访问它们的共享虚拟磁盘。用于驱动一些工作负载的客户端通过1 Gbit/s网络与服务器相连。
在对系统进行压测时有时要进行局部压测，比如对数据库的读写性能压测，使用过数据库以及搜索引擎的小伙伴相信对缓存这个东西一定不会陌生，如果我们在对数据库或者es之类的搜索引擎进行压测时一定要采用随机的参数，否则压测意义就不大了，因为从缓存返回数据跟从io读取数据后返回是两码事，这两种情况在性能上相差太大，当然是用一定固定值进行压测也不符合实际生产过程中使用场景，本文主要介绍一种使用jmeter压测mysql数据库时的一种随机参数生成方式，当然这也不符合实际应用场景，尤其是一些涉及多个关联查询的情况，如果一个查询查不到可能直接返回了，这样也不够真实，更真实一些的方式应该是将系统中已有的数据放在jmeter中进行压测，本文先简单介绍下jmeter随机参数压测mysql的方法：
本文的宗旨在于通过简单干净实践的方式，向读者展示 SpringBoot 应用程序对接 MySQL 时，在使用不同连接池以及不使用连接池时，在增删改查的一个性能对比。这也包括更新和查询时，索引字段的关键性。
事情的背景是这样的：一个朋友今年年初新开了一家公司，自己是公司的老板，不懂啥技术，主要负责公司的战略规划和经营管理，但是他们公司的很多事情他都会过问。手下员工30多人，涵盖技术、产品、运营和推广，从成立之初，一直在做一款社交类的APP。平时，我们一直保持联系，我有时也会帮他们公司处理下技术问题。
Mysql在写入压力很大，怎么办？ 高并发下的性能最大的问题，大都在数据库，以前我们做二十万超级群，mongodb每个月都会出事故. 我们聊聊,高并发下如何缓解mysql的压力 ⚠️：mysql是锁锁表不锁库，sqlite是锁库不锁表 环境准备 Mac mysql navicat wrk压测工具 node.js环境 下载wrk brew install wrk 如果这里卡住，可以调整 `替换brew.git: cd "$(brew --repo)" git remote set-url origin htt
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程
在大量并发读请求、读多写少的业务场景下，本文利用 Sysbench 性能测试工具，调研基于【负载均衡 + ProxySQL Cluster + MySQL MGR 的读写分离架构】能否有效利用横向扩展的 MySQL 实例的读能力，并最终提高应用系统 QPS。
出自percona公司，是一款多线程系统压测工具，可以根据影响数据库服务器性能的各种因素来评估系统的性能。例如，可以用来测试文件IO，操作系统调度器，内存分配和传输速度，POSIX线程以及数据库服务器等。sysbench支持Lua脚本语言，Lua对各种测试场景的设置可以非常灵活。sysbench支持MySQL，操作系统和硬件的测试。
公司最近大量的MYSQL要上线，不做压力测试时说不过去的，所以拿出一直使用的sysbench 来压测一下MYSQL ，问题就开始了，最早用的是0.5 version.
本文是一篇译文，介绍 Percona 的工程师对 ScaleFlux 的性能压测报告。
前段时间，测试了国内主要云原生数据库PolarDB、TDSQL-C、GaussDB的性能，参考：《再测云原生数据库性能》。在上次测试结果中，由于地域版本差异，腾讯云的TDSQL-C并没有表现出“重磅升级”的效果，现在两个月过去了，我们再来重测TDSQL-C。先说结论：
作者介绍： 赵守斌，十年银行业数据库管理经验，熟悉各种Oracle数据库系统方案，对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务化平台建设。 背景 Background 很多关注数据库技术的IT人士可能记不住去年双十二都剁手买了什么东西，但是一定会有人对当时一篇“Galera将死——MySQL Group Replication正式发布”的文章还有印象。 长期以来MySQL官方都缺少原生的MySQL集群多活方案，所以也给第三方公司提供了发展的机会。Galera就是其中的
作者介绍： 赵守斌，十年银行业数据库管理经验，熟悉各种Oracle数据库系统方案，对MySQL开源数据库也有涉猎。目前牵头负责恒丰银行数据库管理和各类数据库服务化平台建设。 背景 Backgroun
MIUI 是小米公司旗下基于 Android 系统深度优化、定制、开发的第三方手机操作系统，也是小米的第一个产品。MIUI 在 Android 系统基础上，针对中国用户进行了深度定制，在此之上孕育出了一系列的应用，比如主题商店、小米音乐、应用商店、小米阅读等。
爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。
最近作者有一个针对ScaleFlux 的产品也叫做 CSD 2000 进行压测的机会. 本文中作者将介绍使用 Intel SSD 和ScaleFlux 存储设备进行压测的对比结果。
有赞的基础架构使用了UCloud的基础服务，我们有相当比例的数据库是UCloud的RDS(一部分使用云RDS，一部分使用购买他们的物理服务器自建数据库)。
在云上环境进行压测的场景，主要有单链路和全链路压测。其中，单链路压测用于业务添加新的接入模块和单业务架构迁移后稳定性评估；全链路压测则更多是在割接上云前演练，大促前容量评估等几个场景。
最近一直在做性能压测相关的事情，有公众号的读者朋友咨询有赞的数据库服务器有没有开启huge page，我听说过huge page会对性能有所提升，本文就一探究竟。对过程没有兴趣的可以直接看结论。
TiDB正式线上前，总是要对TiDB做个压测来为后续的业务接入做评估依旧；本次针对TiDB 5.0以及MySQL 8.0在同等规格配置下，性能做一个对比，尽管来说这么对比，可比性不是很强，但是起码能为后续业务的接入以及上线有一个理论依旧；
SysBench是一个跨平台且支持多线程的模块化基准测试工具，用于评估系统在运行高负载的数据库时相关核心参数的性能表现。可绕过复杂的数据库基准设置，甚至在没有安装数据库的前提下，快速了解数据库系统的性能。
在基于微服务的分布式应用架构下，业务需要的多个服务是通过一系列的服务、中间件的调用来完成，所以单个服务的压力测试已无法代表真实场景。在测试环境中，如果重新搭建一整套与生产环境类似的压测环境，成本过高，并且往往无法模拟线上环境的复杂度以及流量。因此，业内通常选择全链路压测的方式，即在生产环境进行压测，这样所获得的测试结果能够准确地反应系统真实容量和性能水平。
作为一个 MySQL DBA，查看分析 binlog 是日常工作的一部分。不知道你是否遇到过这样的需求：查询一个时间段内各个表的 dml 统计情况。但，如果 binlog 文件很多呢？又或者负责的业务线比较多，有多个业务都有这种需求呢？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
