摘要: 最近国外blog上看到的一片资源分享博文,精而全,于是转帖分享Must-Read Books ListFirst of all, I would like to share a list of books I believe every professional in our field should read at some point in their life. You may notice that many of these books are not too technical or are not really related to the pure systems admini 阅读全文
posted @ 2013-09-25 10:45 cenalulu 阅读(1218) 评论(1) 推荐(0) 编辑
摘要: 遇到如题的这么一个场景:需要在MySQL的一张innodb引擎的表(tableA)上添加一个唯一索引(idx_col1_u)。但是表中已经有大量重复数据,对于每个key(col1),有的重复2行,有的重复N行。此时,做数据的手工清理,或者SQL处理无疑是非常耗时的。1. Alter ignore table come to help印象中MySQL有一个独有的 alter ignore add unique index的语法。语法如下:ALTER [ONLINE | OFFLINE] [IGNORE] TABLE tbl_name行为类似于insert ignore,即遇到冲突的unique数 阅读全文
posted @ 2013-09-13 15:07 cenalulu 阅读(6880) 评论(4) 推荐(0) 编辑
摘要: 背景:最近在做一台线上服务器IO负载情况的时候发现了以下现象:24小时的IO_UTIL 的曲线看似风平浪静,毛刺较少但当图片放大到半小时级别的时候发现IO_UTIL即磁盘使用率出现了规律性的波动,见下图:本文就将从这个现象触发,探究出现这样规律性波动的原因。Step1: 服务器上进行实时IO负载查看通过iostat -x 1 每隔一秒对IO使用情况进行一次负载查看。可以看到UTIL有规律性的波动(10秒1次)。且负载的主要来源在于写请求(负载高时,wsec/s 也同步升高)又由于服务器是MySQL独占,所以比较容易的就可以将原因归结为是MySQL的数据刷写导致(log/data)。看到这里大神 阅读全文
posted @ 2013-09-11 17:31 cenalulu 阅读(16200) 评论(9) 推荐(5) 编辑
摘要: 1 功能简述1.1 Automove功能背景由于memcache的内存分配是基于slab的,每个1M的page内只能存放对应slab大小范围的value值。具体原理见:http://dev.mysql.com/doc/refman/5.0/en/ha-memcached-using-memory.html 。因为这种模式带来的问题也会随着实例的运行时间的增加而凸显。假设实例在运行初期,业务模型存放的都是1k大小的value值,并且把memcache的内存耗尽。此时,memcache的内部全部都是1k类型的slab。随着业务发展value大小变化到了2k,此时需要2k类型的slab存放,这时me 阅读全文
posted @ 2013-09-09 16:02 cenalulu 阅读(2667) 评论(0) 推荐(0) 编辑
摘要: 最近由于 CPAN上 Net::ARP 这个包的稳定版本从 1.0 升级到了 1.0.8, 导致触发了mmm的一个bug。bug的现象:agent没有办法将VIP附着在本机上。agent日志中报错如下:2013/08/13 06:26:47 FATAL Couldn't configure IP '10.1.1.2' on interface 'eth0': undefbug原因:MMM/Agent/Helpers/Network.pm 文件中136行,使用了如下语句:if ($Net::ARP::VERSION < 1.0) {原来版本是1.0 阅读全文
posted @ 2013-09-02 11:56 cenalulu 阅读(852) 评论(0) 推荐(0) 编辑
摘要: 前段时间在阿里嘉年华的workshop做了一些关于memcache高可用和MMM Mod的分享。下面是相关的PPT,特此分享。ADC官网直接在线查看:http://adc.alibabatech.org/carnival/history/schedule/2013/detail/work/112我的微盘下载:http://vdisk.weibo.com/s/dWX58BdRixQC 阅读全文
posted @ 2013-08-14 11:34 cenalulu 阅读(505) 评论(0) 推荐(0) 编辑
摘要: 前言:在一般运维工作中经常会遇到这么一个场景,服务器的IO负载很高(iostat中的util),但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题。这个现象在MySQL上更为常见,在5.6(performance_schema提供io instrument)之前,我们通常只能猜到是MySQL导致的高IO,但是没法定位具体是哪个文件带来的负载。例如是ibdata的刷写?还是冷门ibd的随机读取?本文就将介绍一个比较简单的定位IO高负载的流程。工具准备:iotop:http://guichaz.free.fr/iotop/pt-ioprofile:http://www 阅读全文
posted @ 2013-04-12 16:19 cenalulu 阅读(10576) 评论(0) 推荐(3) 编辑
摘要: 前言:memcache自带的memslap功能无法满足性能测试需要。google以后找到了更为强大的工具memaslap(没错就是多了一个“a”)。具体功能见:http://docs.libmemcached.org/bin/memaslap.html但是在安装过程中不断碰壁,于是将安装过程记录如下Step1:下载安装包memaslap是 libmemcached的一个组件,因此需要编译安装。首先需要下载libmemcached。下载地址:https://launchpad.net/libmemcached/+downloadStep2:解压编译./configure --enable-mem 阅读全文
posted @ 2013-04-03 16:12 cenalulu 阅读(3255) 评论(0) 推荐(1) 编辑
摘要: 起因:开发报告说更新时出错。更新SQL如下:UPDATE table_name d SET d.column_name='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' WHERE d.ID=100976;报错信息如下:Error Code : 1118Row size too large. The maximum row size for the used table type, n 阅读全文
posted @ 2013-03-05 14:49 cenalulu 阅读(821) 评论(2) 推荐(0) 编辑
摘要: 前言:今天一个朋友问了一个问题,原文如下:mysql5.1,myisam的表,select count(*) as total FROM m_bff WHERE from_uid='73149293' AND isdeleted=0。from_uid上有索引,第一次执行这个句子速度慢,1秒多,用show profile看都慢在Sending data上。但是紧接着我加上sql_no_cache,执行只需要0.01秒了,有好多句子都是类似的情况第一次慢,后来加上sql_no_cache也不慢,Key_blocks_unused也很多,请教下这种是什么原因呢?问题总结一下就是:对于 阅读全文
posted @ 2013-02-26 17:22 cenalulu 阅读(1267) 评论(0) 推荐(0) 编辑