Linux Shell 命令小技巧

Top 监控某一多进程任务

以nginx 为例: d PL=`pidof nginx`

PL=${PL//\ /,}

top -p $PL

SSH

ssh scp等消除每次问yes/no

ssh -o "StrictHostKeyChecking no" dev.zuocheng.net

grep

常用参数 -Irn

find

清空所有log文件

find ./ -name *.log | xargs truncate -s 0

删除所有nohup文件

find ./ -name nohup.out | xargs rm -rf

find ./ -name *.swp | xargs rm -rf

删除过期日志(60天前)

find ./ -mtime +60 -name "log.*" -exec rm -rf {} \;

把当前目录下所有文件都MD5

find ./ -type f -exec md5sum {} \; | sort -k 2 > md5sum

date

依据时间戳获取时间

date -d @1525856172

比较两个文件夹的不同

生成MD5值 find ./dir -type f -exec md5sum {} \; > md5sum.txt

校验md5值 md5sum -c > md5sum.txt

工程师手记-将Memcached内存管理机制移植至Redis

Idea 的提出

  • Redis 有其高效的异步网络框架
  • Memcached 有其高效的内存管理机制

将这两者结合在一起后,会如何呢?开始试验将Memcached内存管理机制移植至Redis。

本篇博客的姊妹篇链接: 《工程师手记-将Redis异步网络框架移植至Memcached》

调研和选型

Redis内存管理的几个缺点:

  • 使用tcmalloc 或者 jmalloc 库,这两个库封装较重,内部特性也较多。
  • tcmalloc 适合小空间分配,稍大的空间分配会有瓶颈。
  • Redis 主要是单线程运行(只在后台任务cache持久化功能处又启动了新线程), tcmalloc 和 jmalloc 有保证线程安全,但对redis来说是不必要的功能。尤其是jmalloc,为线程安全做了很重的设计。

软件选型

  • 并不是把 Memcached 的内存管理直接替换redis的内存分配,而是使用ae-memcached的内存分配方式。
  • ae-memcached 的内存分配和 Memcached在原理上毫无不同,仅是从软件架构上对其进行重构和优化。具体参考:《AE-Memcached 优化记录》
  • 选择 Redis 2.8.24 作为移植受体

Redis代码修改和编译 / 移植方案

  • 从ae-memcached中拿出mem_cache / slab 两个类,直接移植到Redis src 目录中
  • 新建两个文件 mc_malloc.h mc_malloc.c,封装mem_cache,让其提供类似 malloc、 alloc、realloc、free的接口
  • 修改 zmalloc.c zmalloc.h 这两个文件,让其支持mc_malloc
  • 修改 Makefile ,默认MALLOC 使用 mc_malloc
  • 修改bio.c 文件,把zmalloc 和 zfree用 libc的 malloc 和 free 代替,这么做主要考虑到线程安全
  • 编译、运行

代码托管地址

给新的redis起了一个新名字mc-redis,源代码托管于Github上:

https://github.com/zuocheng-liu/mc-redis

性能测试实验

硬件

  • Redis-server 服务端 GenuineIntel 6 Common KVM processor 6 核 2.0GHZ 4G 内存
  • redis-benchmark 和服务端部署在同一台服务器上

测试方法

  • 分别运行原本Redis 和 mc-redis, 分别作为实验和对照,参数为 redis-server --port 7777
  • 启动Redis,运行redis-benchmark 测试三次。重复前面步骤,Redis共重启3次,redis-benchmark共测试9次。
  • mc-redis 的测试也使用上面方法
  • 测试命令 ./redis-benchmark -h 127.0.0.1 -p 7778 -q -d 100
  • 只观察set / get 命令的并发度

测试结果

启动一次redis,做了三组实验,数据如下:

  • mc-redis GET 62972.29 / 58275.06 / 55897.15 (requests per second)
  • redis GET 47281.32 / 62034.74 / 51759.83 (requests per second)
  • mc-redis SET 64808.82 / 59031.88 / 56915.20 (requests per second)
  • redis SET 51733.06 / 53676.86 / 56947.61 (requests per second)

结论

在刚启动时(预热阶段),mc-redis 的 set 和 get 操作,比原版redis 的并发处理能力高大约有 15%-20%。 但是稳定运行后, mc-redis 和 原版redis,性能相差较小。

AE-Memcached 优化记录

优化背景和目的

  • 学习Memcached 代码
  • 将 Memcached 的代码成为自己的技术积累
  • 优化Memcache 代码,提高自己系统分析能力

源代码托管于Github上:

https://github.com/zuocheng-liu/ae-memcached

性能优化

网络模型的优化

  • 网络IO多路复用 + 单线程

  • 将 Redis 异步库 移植至 Memcached

优化动态申请内存机制

  • 使用预分配,减小系统调用 malloc、realloc、free的次数,主要出现在新建/关闭链接时,会有较多的系统调用

部分小的函数使用宏代替

优化Memcache协议命令的解析

  • 调整各个命令的解析顺序,把get 和 set 命令放到最前面

软件架构优化

软件架构优化,保证关键代码性能不变

使用宏加强代码复用

  • 重构verbose日志
  • 重构网络库
  • 重构slab

命令模式重构 Memcache 协议

  • 创建command_service类,统一管理命令的解析、处理

更深层次的抽象

将 stats 、 settings 、 logger 和全局资源进行抽象

解耦

  • 将各个模块接口化,减少模块间耦合,尤其是 slab item memcached之间的耦合
  • 依赖注入原则,增强各个模块的复用,其中mem_cache模块 settings等可以形成框架。
  • logger
  • command service

Git 使用经验总结

常用命令

按使用频度排序

  • git pull
  • git log
  • git diff
  • git commit
  • git commit --amend
  • git review
  • git clone
  • git push
  • git reset --hard/soft
  • git checkout
  • git fetch
  • git merge

git 命令非常多,但常用的只有以上几个

常用配置

  • 用户名和密码

$ git config --global user.name "liuzuocheng"

$ git config --global user.email zuocheng.liu@gmail.com

  • 默认编辑器

$ git config --global core.editor vim

  • 配置比较工具

git config --global merge.tool vimdiff

git config --global diff.tool vimdiff

git config --global difftool.prompt false

git config --global alias.d difftool

  • 或者直接更改配置文件 ~/.gitconfig,添加手工添加配置

常用经验

  • 将远程主干合并到本地分支

在代码上线前,这一步非常重要

git fetch && git rebase origin/master

git fetch --all && git merge origin master

  • 解决版本冲突

暂存本地修改

$ git stash

拉取版本库中最新版本

$ git pull

将本地修改与版本库中最新版本合并

$ git stash pop stash@{0}

解决冲突,使用下面的工具会非常方便

$ git d

  • 将源码导出tar包

git对应的功能是归档

mkdir ../working

git archive master | tar -x -C ../working

Git 高级功能

submodule

git submodule add 仓库地址 路径

git submodule update --init

git submodule update

fork后如何同步源的新更新 ?

  • 首先要先确定一下是否建立了主repo的远程源

git remote -v

  • 如果里面只能看到你自己的两个源(fetch 和 push),那就需要添加主repo的源:

git remote add upstream URL

  • 查看主repo的远程源

git remote -v

  • 拉取主repo源的代码

git fetch upstream

  • 合并

git merge upstream/master

  • 提交

git push

git 项目打包导出

示例, 项目中有为1.0的tag

git archive 1.0 | bzip2 > v1.0.tar.bz2

与 Gerrit 配合使用

提交代码审核 git push origin HEAD:refs/for/mybranch

Redis 和 Memcahe 比较和总结

Redis 和 Memcahe 比较和总结
项目 Redis Memcache
读速率 - 批量读效率高
写速率 - -
冗余备份 master-slave模式,交换文件备份,支持binlog
内存使用率 依赖具体使用场景
主从复制 支持master - slaver 不支持 ,若需支持需要代理软件memagent
数据结构 key-value 、Set、 List 、Zset、hash key-value
数据的持久化 支持 不支持
特性 内存数据库、VM特性 内存缓存
存储方式 内存 + 交换文件备份 内存
未来发展 支持cluster -

apache nginx 配置多端口监听,浏览器自动跳转到80端口

       最近两天在分别在配置apache 和 nginx 时,都遇到了一个相同的问题:        

为apache和nginx开启监听多个端口(比如监听80和8080端口)时,改好配置,重启服务。

在浏览器端访问8080端口,url自动跳转到80端口,例如url输入http://**.**.**.**:8080, 则浏览器自动跳转到http://**.**.**.**。

而如果如果在url中的8080端口的后面添加访问文件,则正常展示8080端口下的目录或文件。

离奇的是,过一段时间,大约1个小时后,再访问http://**.**.**.**:8080,就不会跳转到http://**.**.**.**了。

网上搜索,记录此问题的网文不多。 然后自己分析了一下,大概有2种可能性。

1.浏览器端的缓存造成。但是,我换了浏览器,清空了缓存,依然如上。

2.服务器端缓存,1小时后才能恢复正常。 第2种情况比较靠谱些,顺着这个思路,最终找到了答案: 是因为开启了RPCBind服务造成。

解决方法是,将RPCBind的缓存清空。

LNMP启停控制自动脚本

常常在更改LNMP配置之后,需要重启LNMP,在此写了一个自动化脚本,方便重启LNMP。 除了方便重新启动,还增加了关闭与开启功能。 Operating System: Ubuntu Server 代码


# !/bin/bash
function start(){ sudo service nginx start sudo service php5-fpm start } 
function startall(){ start sudo service mysql start }
function stop(){ sudo service nginx stop sudo service php5-fpm stop } 
function stopall(){ stop sudo service mysql start } 
function restart(){ sudo service nginx restart sudo service php5-fpm restart } 
function restartall(){ restart sudo service mysql restart }

## main()

case "$1" in 
    "start") start ;; 
    "startall") startall ;; 
    "stop") stop ;; 
    "stopall") stopall ;; 
    "restart") restart ;; 
    "restartall") restartall ;; 
    "configtest") configtest ;; 
*) echo "Usage: $0 {start|stop|restart|startall|stopall|restartall}" 

esac exit 0 

webserver restart //重启nginx 和 php-fpm