好像有几年没写函数了,写了一个,记录一下,便于后续粘贴。
用了几年了,还是四五年前做的性能测试。目前遇到性能瓶颈,为了找出真因,不得不测试下,得到基准线,再根据测试基准线寻求优化。 测试结果: direct 类型 比 topic 吞吐率快2倍左右; 自动ack 比 手动ack 吞吐率快2倍左右; 短期消息持久化对吞吐率无明显影响; rabbitmq使用建议:无额外需求,建议采用direct类型,且自动ACK; 备注:消息量超过2KB后,吞吐较低的原因目前来看,大部分因素的网卡流量问题,4*2KB队列,网卡流量已达到400Mb/S,与峰值几乎一致。其CPU与内存用量未达顶峰…
经常会遇到此问题,每次都要百度,过于麻烦,遂记录。 一、查看正在执行的SQL 应用场景:通过用于查找执行时间巨长的SQL 或 二、查看历史执行的SQL 应用场景:生产环境出现错误,临时看下执行了哪些sql
部署优点:浏览器访问时,无#锚点,均为全路径,例如: 废话就不说了,nginx.conf配置见下:
一、问题概览 Clickhouse单表,5W个分区,存储了100亿条数据, clickhouse 重启了45分钟才可以写入数据 。 表结构: 重启期间,内存、CPU资源均不高。 启动成功负载见下: 该问题暂未解决,待博主后续再观察解决。 N、参考资料 链接: https://www.jianshu.com/p/8ef21b2f9244 ;
参考资料: 《ClickHouse原理解析与应用实战》 原始链接: https://ld246.com/article/1517214401442 一、介绍 Buffer,指把数据先写入内存 Buffer 表,再周期性的刷入磁盘表中。读取数据时,会同时从 Buffer 表和磁盘表读取。 Buffer表引擎完全使用内存装载数据,不支持文件的持久化存储,所以当服务重启之后,表内的数据会被清空。Buffer表引擎不是为了面向查询场景而设计的,它的作用是充当缓冲区的角色。假设有这样一种场景,我们需要将数据写入目标Merge…
刚用,拿来存储物联网数据,一个坑一个坑踩。 一、分区方面 1.1 分区数量过多问题 分区策略:终端ID+年月日 数据测试阶段,很快超过十万个分区后,数据无法插入: 解决方法:分区策略:终端ID+年月 1.2 同分区多个分区目录问题 以为max_parts_in_total 已经解决了,但是很快又报错max_parts_in_total错误。 排查后发现,分区出现列表,导致分区数量激增,最多一个分区裂变为28个分区目录,占用了分区数量。具体看下图(1,201911)产生了多个分区目录。 阅读《ClickHouse原理…
一、介绍 参考《ClickHouse原理解析与应用实战》图书,作者:朱凯。 二、使用入门 2.1目录结构 核心目录 (1)/etc/clickhouse-server:服务端的配置文件目录,包括全局配置config.xml和用户配置users.xml等。(2)/var/lib/clickhouse:默认的数据存储目录(通常会修改默认路径配置,将数据保存到大容量磁盘挂载的路径)。(3)/var/log/clickhouse-server:默认保存日志的目录(通常会修改路径配置,将日志保存到大容量磁盘挂载的路径)。 配…
有时,只想用些数据测试,但又不想从数据库或Excel输入,这时就可以生成随机数。 拓扑如下 生成记录 随机数: 测试 点击启动后,可看到测试数据: