Hunter的大杂烩 技术学习笔记

2018-04-11

因为selinux导致的openssh免密码登录失败

Filed under: 技术话题 — hunter @ 7:03 pm

(高版本linux中,缺省启用了selinux,也导致了很多莫名的问题)
按常规配置openssh 免密登录:
1. 创建密钥 ssh-keygen -f xxx -t rsa
2. 修改服务端 /etc/ssh/sshd_config,放开pubkey认证
3. 将客户端的 id_rsa.pub 文件拷贝到 服务端,命名为 authorized_keys
4. 重启服务端sshd

测试时发现pubkey 不生效,反复提示要密码,用sshd 的非daemon模式进行调试,发现 免密码的pubkey可以生效,换成 daemon模式就出错
(more…)

2018-04-10

[原创]获取tomcat status信息的统计脚本

Filed under: 技术话题 — hunter @ 9:12 pm

网上找了一上午,没有合用的脚本,花半天用python写了一个简单的脚本,用来获取tomcat status信息,计划上报到ganglia中

(more…)

2018-03-30

jenkins通过外部脚本执行git shortlog命令无输出的问题

Filed under: 技术话题 — hunter @ 7:56 pm

最近尝试用jenkins在定时构建环节统计开发人员的代码变更情况,统计方法参考http://qa.blog.163.com/blog/static/19014700220142131203191/。结果实际运行时遇到一个奇怪的问题,在命令行中明明运行很好的git shortlog命令,放到jenkins里面运行,总是无输出,在度娘上搜了一个下午,一开始以为是环境变量问题(参考https://blog.csdn.net/zzusimon/article/details/57080337),加上”#!/bin/bash -ilex”后,仍然不行,最后还是bing搜索给力,在stackoverflow上找到解决方案(https://stackoverflow.com/questions/43041659/git-shortlog-does-not-show-output-in-jenkins-shell),最后成型的脚本如下,供参考(btw:博客黏贴代码时缩进没了,请自行处理吧~~):

(more…)

2018-03-07

[转]linux下的缓存机制及清理buffer/cache/swap的方法梳理

Filed under: 技术话题 — hunter @ 6:04 pm

from:https://www.cnblogs.com/kevingrace/p/5991604.html

1)缓存机制介绍
在Linux系统中,为了提高文件系统性能,内核利用一部分物理内存分配出缓冲区,用于缓存系统操作和数据文件,当内核收到读写的请求时,内核先去缓存区找是否有请求的数据,有就直接返回,如果没有则通过驱动程序直接操作磁盘。
缓存机制优点:减少系统调用次数,降低CPU上下文切换和磁盘访问频率。
CPU上下文切换:CPU给每个进程一定的服务时间,当时间片用完后,内核从正在运行的进程中收回处理器,同时把进程当前运行状态保存下来,然后加载下一个任务,这个过程叫做上下文切换。实质上就是被终止运行进程与待运行进程的进程切换。

2)查看缓存区及内存使用情况

1
2
3
4
5
[root@localhost ~]# free -m
total       used free shared    buffers     cached
Mem:          7866       7725        141         19         74       6897
-/+ buffers/cache:        752       7113
Swap:        16382         32      16350

(more…)

2018-02-26

【转】生产环境使用 pt-table-checksum 检查MySQL数据一致性

Filed under: 技术话题 — hunter @ 2:20 pm

from:https://segmentfault.com/a/1190000004309169

公司数据中心从托管机房迁移到阿里云,需要对mysql迁移(Replication)后的数据一致性进行校验,但又不能对生产环境使用造成影响,pt-table-checksum 成为了绝佳也是唯一的检查工具。

pt-table-checksum 是 Percona-Toolkit 的组件之一,用于检测MySQL主、从库的数据是否一致。其原理是在主库执行基于statement的sql语句来生成主库数据块的checksum,把相同的sql语句传递到从库执行,并在从库上计算相同数据块的checksum,最后,比较主从库上相同数据块的checksum值,由此判断主从数据是否一致。检测过程根据唯一索引将表按row切分为块(chunk),以为单位计算,可以避免锁表。检测时会自动判断复制延迟、 master的负载, 超过阀值后会自动将检测暂停,减小对线上服务的影响。

pt-table-checksum 默认情况下可以应对绝大部分场景,官方说,即使上千个库、上万亿的行,它依然可以很好的工作,这源自于设计很简单,一次检查一个表,不需要太多的内存和多余的操作;必要时,pt-table-checksum 会根据服务器负载动态改变 chunk 大小,减少从库的延迟。

为了减少对数据库的干预,pt-table-checksum还会自动侦测并连接到从库,当然如果失败,可以指定--recursion-method选项来告诉从库在哪里。它的易用性还体现在,复制若有延迟,在从库 checksum 会暂停直到赶上主库的计算时间点(也通过选项--设定一个可容忍的延迟最大值,超过这个值也认为不一致)。

为了保证主数据库服务的安全,该工具实现了许多保护措施:

  1. 自动设置 innodb_lock_wait_timeout 为1s,避免引起
  2. 默认当数据库有25个以上的并发查询时,pt-table-checksum会暂停。可以设置 --max-load 选项来设置这个阀值
  3. 当用 Ctrl+C 停止任务后,工具会正常的完成当前 chunk 检测,下次使用 --resume 选项启动可以恢复继续下一个 chunk

(more…)

« Newer PostsOlder Posts »

Powered by WordPress