1、ll -h /opt/zimbra/data/ldap/mdb/db/data.mdb看到是80G，但 du -sh 看只有4M，这样带来的问题是，当用rsync备份目录的时候，同步到远程的就是80G，十分坑爹
2、官方的说明
OpenLDAP_Performance_Tuning_8.0
3、解决方法
a、修改文件大小：solvedcritical-ldap-primary-mdb-database-is-90-full-in-zimbra
b、利用mdb_copy来备份：ldap data.mdb after upgrade from 8.0.0 -> 8.0.1 has a size of 85GB
有几台Esxi，虚拟机较多，有时要找一台虚拟机是在哪台物理机上，很不方便，上网找到这个Python模块，可以列出某台物理机上所有虚拟机
一、安装模块
pip install pyvmomi
二、获取Esxi下所有虚拟机列表
先下载脚本
git clone https://github.com/vmware/pyvmomi.git
开始使用
cd pyvmomi/sample python getallvms.py -s 192.168.8.xxx -u xxxx -p xxxxx
今天XenServer重启，发现有个SR不可用，进控制台,lvdisplay还可以看到，但lvscan发现是inactive状态
解决办法： vgchange -a y
没什么技术含量，年纪大，记性差，作个记录
没有办法直接获取，通过一些非常规手段来
1、telnet上去
telnet 127.0.0.1 11211
2、根据items获取slab的id，items后面的数字，就是slab id
stats items
STAT items:3:number 1
STAT items:3:age 498
STAT items:22:number 1
STAT items:22:age 498
END
3、获取某slab id下的所有key
其中，3为slab id，100为取100个
stats cachedump 3 100
最近有台MySQL，在运行一段时间后，res和virt内存都会去到很高，res会占到物理内存的90%，
期间做过的尝试：
1、用tcpcopy来把生产环境的流量导到测试服，但MySQL内存并无异常
2、将innodb_file_per_table=1修改为innodb_file_per_table=0，运行1天后，内存飙升还是比较厉害
同事看监控，发现在凌晨，MySQL备份后，内存才飙升
最后查找到MySQL内存异常的原因是以下2个：
1、xxx_db下表太多：近2W了
2、由于表太多，${MYSQLDUMP} -uroot -p${MYSQLPASSWORD} -d $1 > “${BACKUPDIR}/$1_db_struc.sql”这个指令把整个库的表结构导出来的时候，估计会把整个结构先写入内存
解决办法：
1、减少表数量
2、不导整个库的结构，一个表一个表地导（这个也是目前的做法），或者直接就不导结构，因为都是一样的
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
|---|---|---|---|---|---|---|
| « 5月 | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||