ByteCoding

sar1yum install sysstat CPU12345678910$ sar -u ALL 1 5Linux 2.6.32-696.el6.x86_64 (xxx) 2019年10月15日 _x86_64_ (40 CPU)17时25分50秒 CPU %usr %nice %sys %iowait %steal %irq %soft %guest %idle17时25分51秒 all 14.75 0.00 1.13 0.00 0.00 0.00 0.25 0.00 83.8717时25分52秒 all 11.17 0.00 1.74 0.00 0.00 0.00 0.25 0.00 86.8417时25分53秒 all 12.31 0.00 1.61 0.00 0.00 ...

基本结构 超级块 在ext4文件系统最开头的部分 记录了整个文件系统中所包含的文件的元数据，df命令读取的就是超级块中的内容，所以执行很快 超级块副本 inode 记录每个文件的大小（非实际大小，用于ls命令）、权限、编号等信息，但文件名是记录在父目录的inode中 文件的r权限，是读取文件内容；而目录的r权限，是读取目录下的文件名称 datablock 记录数据，inode和datablock是链式结构 ls统计的是inode里面的文件大小，而du统计的是文件datablock的总大小 12[root@localhost ~]# ls -li anaconda-ks.cfg33574978 -rw-------. 1 root root 1260 12月 15 19:25 anaconda-ks.cfg ext412345678910111213[root@localhost sdb1]# df -Th文件系统 类型 容量 已用 可用 已用% 挂载点devtmpfs devtmpfs 475M 0 47 ...

duestimate file space usage 非空洞文件12345678[root@localhost dd]# dd if=/dev/zero bs=4M count=10 of=afile记录了10+0 的读入记录了10+0 的写出41943040字节(42 MB)已复制，0.0569579 秒，736 MB/秒[root@localhost dd]# ls -lh afile-rw-r--r--. 1 root root 40M 12月 16 20:55 afile[root@localhost dd]# du -sh afile40M afile 空洞文件12345678[root@localhost dd]# dd if=/dev/zero bs=4M count=10 seek=20 of=bfile记录了10+0 的读入记录了10+0 的写出41943040字节(42 MB)已复制，0.0357481 秒，1.2 GB/秒[root@localhost dd]# ls -lh bfile-rw-r--r--. 1 root root 120M 12月 16 20:58 bf ...

nohup & VS 守护进程 nohup命令使得进程忽略hangup（挂起）信号 守护进程 不需要终端就能启动 输出会打印到特定的文件中 守护进程占用的目录是根目录 nohup &Session A1234567891011[root@localhost ~]# tail -f /var/log/messagesDec 16 06:39:44 localhost NetworkManager[758]: <info> [1576496384.0844] dhcp4 (ens33): nameserver '192.168.206.2'Dec 16 06:39:44 localhost NetworkManager[758]: <info> [1576496384.0844] dhcp4 (ens33): domain name 'localdomain'Dec 16 06:39:44 localhost NetworkManager[758]: <info> [1576496384.0844] ...

man Executable programs or shell commands System calls (functions provided by the kernel) Library calls (functions within program libraries) Special files (usually found in /dev) File formats and conventions eg /etc/passwd Games Miscellaneous (including macro packages and conventions), e.g. man(7), groff(7) System administration commands (usually only for root) Kernel routines [Non standard] 123456$ ls /usr/bin/passwd /etc/passwd/etc/passwd /usr/bin/passwd$ man 1 passwd$ man 5 passwd$ man - ...

调优目标 主要目标：高吞吐量、低延时 吞吐量 即TPS，指的是Broker端进程或Client端应用程序每秒能处理的字节数或消息数 延时，可以有两种理解 从Producer发送消息到Broker持久化完成之间的时间间隔 端到端的延时，即从Producer发送消息到Consumer成功消费该消息的总时长 优化漏斗优化漏斗是调优过程中的分层漏斗，层级越靠上，调优的效果越明显 操作系统层 mount -o noatime 在挂载文件系统时禁用atime（Access Time）更新，记录的是文件最后被访问的时间 记录atime需要操作系统访问inode资源，禁用atime可以避免inode访问时间的写入操作 文件系统选择ext4、XFS、ZFS 将swappiness设置成一个很小的值（1~10，默认是60），防止Linux的OOM Killer开启随机杀掉进程 swappiness=0，并不会禁止对swap的使用，只是最大限度地降低使用swap的可能性 因为一旦设置为0，当物理内存耗尽时，操作系统会触发OOM Killer OOM Killer会随机挑选一个进程然后kill掉，不会给出 ...

主机监控 主机监控：监控Kafka集群Broker所在的节点机器的性能 常见的主机监控指标 机器负载 CPU使用率 内存使用率，包括空闲内存和已使用内存 磁盘IO使用率，包括读使用率和写使用率 网络IO使用率 TCP连接数 打开文件数 inode使用情况 JVM监控 重点指标 Full GC发生频率和时长 活跃对象大小 应用线程总数 设置堆大小 经历一次Full GC后，堆上存活的活跃对象大小为S，可以安全地将老年代堆大小设置为1.5S或者2S 从0.9.0.0版本开始，社区将默认的GC收集器设置为G1，而G1的Full GC是由单线程执行的，速度非常慢 一旦发现Broker进程频繁Full GC，可以开启G1的**-XX:+PrintAdaptiveSizePolicy，获知引发Full GC的原因** 集群监控 查看Broker进程是否启动，端口是否建立 在容器化的Kafka环境，容器虽然启动成功，但由于网络配置有误，会出现进程已经启动但端口未成功监听的情形 查看Broker端关键日志 Broker端服务器日志server.log – 最重要 控制器日志controller.l ...

背景 命令行脚本只能运行在控制台上，在应用程序、运维框架或者监控平台中集成它们，会非常困难 很多命令行脚本都是通过连接ZK来提供服务的，这会存在潜在的问题，即绕过Kafka的安全设置 运行这些命令行脚本需要使用Kafka内部的类实现，也就是Kafka服务端的代码 社区是希望用户使用Kafka客户端代码，通过现有的请求机制来运维管理集群 基于上述原因，社区于0.11版本正式推出Java客户端版的KafkaAdminClient 功能 主题管理 主题的创建、删除、查询 权限管理 具体权限的配置和删除 配置参数管理 Kafka各种资源（Broker、主题、用户、Client-Id等）的参数设置、查询 副本日志管理 副本底层日志路径的变更和详情查询 分区管理 创建额外的主题分区 消息删除 删除指定位移之前的分区消息 Delegation Token管理 Delegation Token的创建、更新、过期、查询 消费者组管理 消费者组的查询、位移查询和删除 Preferred领导者选举 推选指定主题分区的Preferred Broker为领导者 工作原理 KafkaA ...

脚本列表12345678connect-distributed kafka-consumer-perf-test kafka-reassign-partitions kafka-verifiable-producerconnect-standalone kafka-delegation-tokens kafka-replica-verification trogdorkafka-acls kafka-delete-records kafka-run-class zookeeper-security-migrationkafka-broker-api-versions kafka-dump-log kafka-server-start zookeeper-server-startkafka-configs ...

背景 Kafka和传统的消息引擎在设计上有很大的区别，Kafka消费者读取消息是可以重演的 像RabbitMQ和ActiveMQ等传统消息中间件，处理和响应消息的方式是破坏性 一旦消息被成功处理，就会从Broker上被删除 Kafka是基于日志结构（Log-based）的消息引擎 消费者在消费消息时，仅仅是从磁盘文件中读取数据而已，是只读操作，因为消费者不会删除消息数据 同时，由于位移数据是由消费者控制的，因此能够很容易地修改位移值，实现重复消费历史数据的功能 Kafka Or 传统消息中间件 传统消息中间件：消息处理逻辑非常复杂，处理代价高、又不关心消息之间的顺序 Kafka：需要较高的吞吐量、但每条消息的处理时间很短，又关心消息的顺序 重设位移策略 位移维度 直接把消费者的位移值重设成给定的位移值 时间维度 给定一个时间，让消费者把位移调整成大于该时间的最小位移 维度 策略 含义 位移维度 Earliest 把位移调整到当前最早位移处 Latest 把位移调整到当前最新位移处 Current 把位移调整到当前最新提交位移处 Specified-Of ...