优化有BLOB,TEXT类型字段的查询

2016年4月29日 804 views 没有评论

由于MySQL的内存临时表不支持blob,text值,如果包含blob(text)列的查询需要用到临时表,就会使用基于磁盘的临时表,性能将急剧降低。所以编写查询语句,如果没有必要包含blob、text列,就不要也写入查询条件。

可以规避的办法有2种:

q  1.使用SUBSTRING( ) 函数。

q  2. 把临时表存放在基于内存的文件系统. 如linux下的tmpfs 。设置MySQL变量tmpdir ,可以设置多个临时表位置(用分号分割),MySQL将使用轮询方式。

优化办法有。

q  如果必须使用,可以考虑拆分表,把blob,text字段分离到单独的表。

q  如果有许多大字段,可以考虑合并这些字段到一个字段,存储一个大的200kb比存储20个10kb更高效。

q  考虑使用COMPRESS( ),或者在应用层进行压缩,再存储到blob字段中。

注意:如果BLOB列很大,可能需要增大innodb_log_file_size (MySQL错误日志内可能有提示事务日志小了)。

VARCHAR, BLOB和TEXT列,最大行长度稍微小于数据库页的一半。即,最大行长度大约8000字节,在8k以内的话,是可以存储在单个页块里的。

分类: 数据库 标签:

MySQL索引介绍

2016年4月20日 963 views 没有评论

目前MySQL主要支持的几种索引:B树索引(B-tree),哈希索引( hash) ,空间索引Spacial(R-tree),全文索引(full-text)

B树索引介绍

实际MySQL实现的B+树,它的索引如下图(摘录自high performance MySQL )

1

以上是一个简单的图,包括了一个节点块,块内包含一定数量的键值(如key1…keyn) 以及它的叶块(leaf pages),页块内的所有值(Val…)按大小顺序排列,各页块用指针进行连接。

实际的系统,根(root)节点到叶块之间可能有多层的节点块(node page),树的深度取决于表的大小.假设一个块内能存放256个元素,那么3层的树可以存储>1千万的元素.由于有这样的一个层次结构,往往经过2、3次的索引查找,就可以定位到记录,可以大大减少磁盘的读取次数。各页块之间有指针连接,那么还可以方便的进行顺序范围查找。

参考:http://zh.wikipedia.org/wiki/B%2B%E6%A0%91

 

估计查询性能

对小的表,通常能在1次磁盘搜索中找到行(因为索引可能被缓存)。对更大的表,可以使用B-树索引进行估计,将需要log(row_count)/log(index_block_length/3 * 2/(index_length + data_pointer_length))+1次搜索才能找到行。

 

在MySQL中,索引块通常是1024个字节,数据指针通常是4个字节,这对于有一个长度为3(中等整数)的索引的500,000行的表,通过公式可以计算出log(500,000)/log(1024/3*2/(3+4))+1= 4次搜索。

 

上面的索引需要大约500,000 * 7 * 3/2 = 5.2MB,(假设典型情况下索引缓存区填充率为2/3),可以将大部分索引保存在内存中,仅需要1、2次调用从OS读数据来找到记录。

 

然而对于写,将需要4次搜索请求(如上)来找到在哪儿存放新索引,并且通常需要2次搜索来更新这个索引并且写入行。

 

注意,上述讨论并不意味着应用程序的性能将缓慢地以logN 退化!当表格变得更大时,所有内容缓存到OS或SQL服务器后,将仅仅或多或少地更慢。在数据变得太大不能缓存后,将逐渐变得更慢,直到应用程序只能进行磁盘搜索(以logN增加)。为了避免这个问题,应随数据增加而增加innodb_buffer_pool的大小。尽量缓存大部分索引和热点数据。

 

 

哈希索引(hash indexes)

哈希索引是通过构建哈希数组(表) ,通过对值进行hash,查找hash表, 找到真实的行记录的(hash表存储了行记录的指针)。

哈希索引目前只在memory storage engine中支持,也是它的默认索引类型。这是一个不常用的功能。如需了解,可参考

http://dev.MySQL.com/doc/refman/5.1/zh/storage-engines.html

 

空间索引(spacial indexes)

目前在myisam engine中支持. 如需了解,请参考

http://dev.MySQL.com/doc/refman/5.1/zh/spatial-extensions-in-MySQL.html#creating-spatial-indexes

 

 

全文索引(full-text indexes)

全文索引)在myisam engine中支持,如果是其他引擎,一般需要采用第三方的方案,如sphinx,Lucene, Solr等(有个好消息,MySQL 5.6 InnoDB开始支持全文索引了). MySQL在大数据量下的全文索引性能不佳,且无法支持正确的支持中文,一般中文的解决方案,建议采用第三方的解决方案,可参考sphinx等全文索引方案,sphinx可实现快速,高效,可扩展的全文搜索,其性能大大超过MySQL内建的全文搜索

 

一般如果没有特别指明,就是B-Tree索引.由于索引是在存储引擎层实现的,不同的存储引擎的索引实现会有一些差异,以下所述是一些较通用的索引的知识.

逻辑上可以分为:单列索引,复合索引(多列索引),唯一索引(unique),非唯一索引(Non Unique)

 

索引键值的逻辑顺序与索引所服务的表中相应行的物理顺序相同的索引,被称为聚集索引(cluster index),也就是说数据和索引(B+树)在一起,记录是真实的保存在索引的叶子中。有些人也称之为索引组织表,反之为非聚集索引。我们常用的InnoDB表其实就是使用的聚集索引。

聚集索引是一个很重要的概念,InnoDB作为我们最常使用的引擎,我们熟悉了它的数据存储方式,才可能有针对性的对它进行调优。

簇索引的一些优点:

保持相关的的数据在一起,叶子内可保存相邻近的记录。

查找数据通常比非簇索引更快,因为索引和数据存储在一起。

如果充分利用以上,簇索引可极大提升性能, 但簇索引也有许多不足:

簇索引对i/o密集型负荷性能提升最佳,但如果数据是在内存中(访问次序不怎么重要),那么簇索引并没有明显益处;

插入操作很依赖于插入的次序,按primary key的顺序插入是最快的;

更新簇索引列的成本比较高,因为InnoDB不得不移动更新的行到新的位置;

全表扫描的性能差,尤其是行存储的不那么紧密,或者因为页分裂(page split)而存储不连续;

二级索引的叶节点中存储了主键索引的值,如果主键采用得是较长的字符,那么索引可能很大,且通过二级索引查找数据也需要两次索引查找;

 

以下图(来自high performance MySQL 3rd)很好的说明了MYisam和InnoDB的怎样排列我们的表数据。我们对比下InnoDB和MyISAM的数据分布.

2

如上的索引是B+树,各存储引擎大致类似,一颗二叉树,从根节点出发,各子节点指向更深层的子节点或者叶子节点。

我们对比下主键索引和二级索引

InnoDB

主键是一个B树的结构,数据是按照主键(primary key)的顺序来存储的,由于主键是有序的,很显然,对于InnoDB表,最高效的存取方式是按主键取唯一记录或者小范围的主键扫描。如果是其他二级索引(secondary key), 那么也是一个B树的的结构,但是它的leaf page (leaf nodes)存储的不是实际数据指针而是主键的值(key+PKcols). 如果按照二级索引去检索记录,会需要通过存储的主键值再去查找记录,即多了一层join ,这样的好处是当行移动或者页分裂的时候,不用维护二级索引. 当然,如果主键占据过多字节,那么会造成二级索引[……]

Read more

分类: 数据库 标签:

“我看电商”,“再看电商” 读书笔记

2015年6月1日 1,753 views 没有评论

我看电商,再看电商

这是一个运营资深人士-黄岩 写的书,还是很有见地的。推荐对电商运营感兴趣的同学看。

百度腾讯为什么电商领域失败
理念上出了问题

想用模仿淘宝的方式来蚕食淘宝,在对方的地盘上,用对方发明并使用娴熟的武器来试图攻击对方。

缺乏有商务头脑的领军人物

度腾讯都是技术人才汇聚的IT公司,商务人才缺乏,在电商布局上,试图内部繁衍,过于自负,犯了以为自己一样能,样样能的毛病

对电商的定位缺乏深思熟虑

机会很多,比如B2C,比如移动端,需要考虑其他的形态,不一定必须做淘宝类型的平台型

 

电商领域的3个错误

 

认为规模就是效益

规模有可能带来单位成本降低的效益,但规模和效益没有直接因果关系,这个世界有规模没效益的公司比比皆是.

认为流量就是一切

有流量/有客人 固然重要,但更重要的是顾客买单,顾客留存.电商行业往往过分强调登录的用户数,忽视了购买转化过程中的客户流失.

过度依赖价格战

准确的说,电商的价格战,只是一场口水战,并没有真正让顾客得到实惠.

 

怎样管理上市公司的心得

少说,一个人说

不要随意发表言论,要讲的话,归口一个人负责

必践

公布一个预算,或者一个年度目标时,心里要有充分的把握,误差要小于3%,否则人们会怀疑公司管理者的业务把控能力.

 

国内互联网公司,过去这些年大多是借助市场红利,先行一步抢占商机做起来的,内部运营的效率,企业经营的定位,方方面面的管理,都还相当薄弱,小到类似开会要有明确主题,会议要有纪要和落实方案这样很基本的管理要求,很多互联网公司都不到位,往往是老板口头说一个要求,马上实施.

 

 

电商模式

两种模式

买卖模式:如沃尔玛,家乐福,京东的自营。挣的是商品流通效率的钱,通过规模化的采购,降低单件商品销售成本,从中获利。零售公司最基本的任务,就是组织专业化的买卖,营销团队,运用其专业能力和专业知识把货源更精准地组织起来,然后卖给消费者。它最核心的人才在于其买手团队。用户忠诚度高

平台模式:如淘宝,各种B2C网站的开放平台,国内的各种百货公司,平台模式实质上是商业房地产,平台其实就是靠出售顾客流量挣钱.追求顾客客流量的最大化。很难培养用户的忠诚度。

全世界各地的零售业,绝大部分国家,社会零售的主力形态通常都是买卖模式。但在中国,到目前为止,零售业的运行是以平台模式为主的,有各种原因导致出现这种现象。这体现了国内流通领域的低效,以及买卖双方大量额外的交易成本支出。

 

 

亚马逊不用PPT

他们会议一开始递给你一份简要介绍相关数据或现况的A4纸打印稿,几乎都是workd文档,一目了然的把基础数字用书面呈现给你。
因为 不想让大家把精力放在琢磨PPT的格式、字体、图表剪裁上。同时他们认为,任何事情,不管多大的事,如果用两页A4纸不能叙述清楚,那这个人就跟不不明白他自己想要说什么。

 

 

唯品会

代销代运营,唯品会把销售运营的各个环节都自己承担下来,从而保证品牌公司能用最省心的方法去销售自己的商品。对运营有非常高的要求。
模式、经营效率、顾客留存率均有闪亮的表现
唯品会的商业模式有三个基本的支撑点

品牌商品、特价销售、限时。品牌让消费者注意,特价刺激消费者的欲望,限时促成消费者的行为,同时不会对线下渠道造成冲击。这是很完整的用户购买从吸引到想拥有,到掏钱包的连贯营销流程。

唯品会的限时特卖销售的增长,主要来自于三四线品牌,由三四线城镇的用户们所购买,这样的契合,一下子把限时特卖推到一个非常广阔的商品空间。
限时特卖普遍采用聚焦的营销方式,即在一个时间段内,只推出几十款到几百款价格震撼的商品,这就使这些商品有了充足的曝光机会。唯品会的平均每个单品的销售值远高于其他电商。

 

 

传统行业做电商

要有归零的心态
把电商当做一次创业,适宜采用新团队
把电商当作一次投资行为,赋予其早期成长足够的自主空间,不要一上来就干预太多。
 
电商企业的投资可能性
企业的经营模式
企业的运营效率
顾客留存率

 

 

 

 

 

分类: 读书 标签: , ,

关于庆安枪击

2015年5月18日 1,656 views 没有评论

我一般不写非技术的话题,但有些思考需要记录下。

1、基本上,这次的宣传是失败了,但玩政治、宣传的人手段是很强的,总是会先用一个低级别的部门去调查,然后观察舆情而定下一步的策略,只是没有想到公众的反应这么大;

2、民智已开,想用一些剪辑的录像去忽悠人,已经很难了,公众很怕的是公权力不受约束,特别是中国这样的,民间不持枪的国家,如果不加以规范,和加强训练,每个人都可能成为下一个徐;

3、深层次的原因,还是现在经济形势越来越不好,相当一部分人,已经沦为社会底层,“弱势群体”这个词不知道谁造出来的,一个人怎么生下来就成了弱势群体呢?现在的规则,很多人没有上升通道,几乎自我放逐,自我放弃,徐就是典型,徐这种人可恨吗,许多人都认为活该,但这样的人太多,罪不至死;

4、网上竟然有人宣传底层垃圾可以去死,其实这是法西斯主义,正常的国度,这种人应该抓起来,但还有一大堆人较好,也是蛮可悲的;

5、公众素质都有待提高,因为谩骂很正常,我也会说人五毛,脑残,这点要反省。其实道理很明白,扣帽子,给人贴以标签,对于事情的解说,毫无帮助,贴标签的人多了,往往证明公民社会不够发达,大家没有基本的逻辑辩论能力。

6、现在大讨论是该杀不该杀,这样的倾向很有问题,正常的情况,应该是问责,需要问清楚当时发生了什么?如果这种论调成为主流,那么公众才会放心。

7、律师这个群体良莠不齐,大部分人也是混饭吃,为名利,不过要推动改变的话,还是要靠他们。

分类: 互联网技术 标签:

如何成为一名合格的MySQL DBA

2015年4月30日 870 views 没有评论

我曾经做过研发、也做过系统管理员、也做过Oracle DBA,至今从事MySQL也有7年时间,从一名Oracle DBA转型为一名MySQL DBA,从传统领域到互联网公司,我想分享给读者一些自己心得,成为一名MySQL DBA并不难,MySQL DBA并不神秘,也容易入门,但成为一名高水平的DBA需要时间,希望我的经历能给大家一些启动,希望热爱数据库技术的同学少走弯路。

2008年,在经历了多年的传统行业之后,我因为机缘巧合进入了移动互联网行业。角色也从专职 Oracle DBA 过渡到了Mysql DBA。MySQL当时不太懂,但以前做Oracle DBA的时候也做过一些MySQL的测试,慢慢就熟悉了。互联网公司的MySQL DBA对比传统行业的DBA工作节奏会快些,所需面对和处理的事情也不一样了。传统的行业,许多Oracle DBA会更偏向网络、存储、小机、OS,Oracle自身产品够强大,很解决很多问题 ,但在互联网行业,Mysql DBA会需要更前进一些, 参与系统架构的评审,和研发团队、监控团队、甚至是运营团队、产品团队互动。

如何做一名合格的MySQL DBA呢,我觉得首先要问自己一个问题,你是否适合做一名DBA。从事DBA工作,往往意味着你需要7*24小时待命,意味着你会承受比其他职业更大的心理压力,有时你可能需要在工作之外升级服务。除了知识、技能的考虑,我们更需要的是心理素质,你需要胆大心细,遇事冷静,这会让你在处理故障的时候表现得又稳又好。

作为一名DBA,我们往往需要其他领域的知识,用户访问应用服务,往往经历许多环节,DBA不一定精通每个环节,但对离自己最近的环节,都应该熟悉、甚至精通,比如,数据库与操作系统联系非常紧密,要求我们对操作系统很熟悉,数据库很大一部分调优,都是对存储系统进行调优,我们也需要对磁盘系统,RAID等技术很熟悉,同时,DBA必须理解应用软件的行为,如果你不了解应用,不了解应用系统的架构,你就难以提出有效的建议给研发人员,DBA不能仅仅维护自己的数据,还应该能给研发人员、系统架构人员足够的好多建议,协助创建出可靠的、健壮的应用程序。所以DBA往往需要熟悉硬件、操作系统、应用开发,一般DBA会有系统管理或者研发的背景,不同的DBA可能关注的面不一样,如果你有两方面的背景会更好。

作为DBA,必然应该对自己使用的产品很熟悉,我们作为一名MySQL DBA,应该深刻了解InnoDB引擎的行为,它是如何工作的,它有哪些特性,这样我们才能充分利用它。你需要熟悉关系数据库理论,熟悉查询语言,

作为一名DBA,你需要乐于接受挑战,数据库的性能诊断调优、故障处理,往往需要你在很短的时间内处理完毕,你也可能碰到短期内你解决不了的问题,如果没有一种迎接困难,有困难就上的心态,你难以获得别人的认同,也无助于团队的成长。或者说,如果碰到困难,你出错了怎么办?考虑到严重的后果,你是否仍然愿意接受这个挑战呢?

作为一名MySQL DBA,你需要注重团队协作,MySQL数据库对于应用程序、系统架构甚至是前端依赖很深,如果你的应用程序写得不好,或者你的WEB服务器,或者你的前端设计有问题,可能最终会反映或者被人误以为是数据库的性能问题,我们需要熟悉和不同领域的人士打交道,很多时候,从其他团队、部门着手,会让问题得到更快的解决。

作为一名MySQL DBA,你需要密切了解趋势,比如一些NoSQL产品,如Redis、TokuMX。在一些特殊的场合,在数据规模在增大后,你需要NoSQL产品来存储不同的数据,以充分发挥组合的优势。

以上几点,我想是作为一名合格的MySQL DBA需要具备的,当你成为了一名合格的DBA,你会发现有更多的挑战等着你。

 

稀缺

2015年2月22日 1,435 views 没有评论
中文版和英文kindle版都买了
中文版笔记:
资源稀缺不可怕,就怕有稀缺心态
稀缺是一门“正在形成中的科学”。这门科学旨在揭示稀缺的心理学基础,并利用这一知识去解释各式各样的社会现象和行为方式。
稀缺,是“拥有”少于“需要”的感觉。对稀缺的感觉,取决于可用的资源和我们自身的体验。拥有的比需要的少,结果很简单:人们会变得不幸福。
稀缺造成的后果不仅仅是因为我们会因拥有的太少而感到不悦,而是因为它会改变我们的思维方式,会强行侵入我们的思想之中。
稀缺对人类大脑产生的的影响,也存在于潜意识之中。无论大脑的主人是否愿意,稀缺都会牢牢地俘获他的注意力。
稀缺对注意力的俘获,不仅会影响我们的所见和所见的速度,而且也会影响我们对周遭世界的认识。
稀缺会进一步延续并加剧稀缺。
带宽(bandwidth) 就是心智的容量,包括两种能力,分别为认知能力和执行控制力。稀缺会降低所有这些带宽的容量,致使我们缺乏洞察力和前瞻性,还会减弱我们的执行控制力。
稀缺会俘获我们的注意力,并带来一点点好处:我们能够在应对迫切需求时,做得更好。但从长远的角度来看,我们的损失更大:我们会忽视其他需要关注的事项,在生活的其他方面变得不那么有成效。
 
专注的“得”与管窥的“失”
佯装稀缺是很难做到的
稀缺会自动将干扰和诱惑等因素推至一旁,让我们做到凭一己之力很难做到的事情,这就是专注红利。但是,专注于某一事物意味着我们会忽略原本很重要的其他事务,导致我们有了“管窥”之见,也叫做“隧道视野”。我们专注、管窥、着手做事、疏忽其他事,都出于同样的原因:那些存在于“管子”视野之外的事务被抑制了。
 
带宽负担会降低人的智商
稀缺会直接减少带宽–不是减少某人与生俱来的带宽容量,而是减少其当下能用得上的容量。
认知能力(cognitive capacity) :它是我们解决问题、获得信息、进行逻辑推理等能力背后的心理学机制。认知能力中最突出的就是“流体智力”,即在进行抽象思维和推理时,在无须特定学习或体验的情况下解决问题的能力。
执行控制力(executive control) :其作用存在于我们管理自身认知能力的过程中,包括计划、关注、发起并抑制行为和控制冲动等。
稀缺会形成带宽负担,而这就意味着,稀缺不仅会降低流体智力,而且会降低自我控制力。有一点可以明确:贫穷会成为心智的负担。就算没有实验人员去提醒稀缺的存在,贫穷状态也会削弱流体智力和执行控制力,所有人一旦身陷贫穷,其有效带宽都会变窄。
稀缺完全不同于压力和忧虑,稀缺,不仅仅会令我们入不敷出,不知如何分配资源,而且还会让我们在生活的其他方面手足无措。稀缺会使人变笨,变得更加冲动。我们不得不在流体智力和执行控制力被减弱的情况下,依靠更为有限的脑力去勉强度日。生活,就这样变得举步维艰起来。
 
装箱、余闲和权衡式思维
用大行李箱收拾行李时,人们总是十分随意;而用小行李箱收拾行李时,人们便会变得小心翼翼,思索再三。
稀缺迫使我们产生了权衡式思维。所以那些没有被满足的需要俘获了我们的大脑,成为我们时时刻刻念念不忘的事情。
余闲(slack):就是我们在拥有很大空间,不存在稀缺心态时的产物,也是我们在资源丰富时进行资源管理的特定方式。余闲可以将我们从做权衡的苦差事中解脱出来,让我们轻松的避免选择负担。我们所谓的余闲不是可以预留的空间,而是因为装箱时空间充裕而产生的“副产品”。
没有余闲时犯错,后果很严重。稀缺不仅意味着人们没有失误的空间,也意味着人们更有可能会出现失误。稀缺不仅提高了失误的成本,也为人们创造了更多机会去犯下错误,做出不明智的选择。稀缺的本质就是没有余闲。一个人的富有程度,与他所能舍弃之物的数量成正比。
 
行为经济学告诉我们的道理
我们在小物件上连几毛几分钱都会计较,而在大物件上却挥金如土。所以,在某种程度上,默认对金钱的判断也是和背景相对的,人们对货币价值的衡量是相对的。虽然相对性认知是大脑处理信息时的固有特征,但经验与专业技能还是能让我们摆脱这一限制。炒股也是如此。要珍视每一分钱。OK。 专业技能,也就是对某一领域知识的深度理解,能够对认知形成改变。
我们之所以会对物品的价值感到模糊和混淆,是因为我们在资源充裕的情况下是不会进行权衡的。
 
借用与短视
今天的稀缺,将造成明天更大的稀缺。当我们为了解决眼下的难题而极度专注时,就无法有效地规划未来,这样一来,向前看的能力就很可能会因管窥负担而丧失。
借用(borrowing):当人们面临资源短缺时,就会通过借用相应的时间或金钱来应对突发事件。从长远来看,借用会进一步加剧稀缺。我们借用时,就是给自己的将来挖下了更深的坑。
明天的稀缺注定无法像今天的稀缺一样俘获你的注意力。原因很简单–当下的一切都会自动加载你的身上,但未来却不然。
稀缺,尤其是管窥心态,会让你搁置那那些重要但不紧急的事务。将重要却不紧急的事务搁置,这种倾向不仅有关于时间,也有关于金钱。
当我们我为了解决眼下的难题而极度专注时,就无法有效地规划未来。
 
稀缺陷阱
对稀缺进行放大的行为,就像复利一样,会使最初的稀缺变本加厉。
当有了管窥心态后,我们就只能局部地、暂时地解决问题。
逃离稀缺陷阱,首先就需要指定计划,而在稀缺心态的控制之下,我们很难集中精力去做到这一点。指定计划很重要,但并不紧急,而这类事情正是管窥心态导致我们所忽略的事情。
稀缺陷阱尤其会令人感到心酸的是,它会让人产生一种感觉:只要在多一点资源,就能摆脱欠下的所有债务,就能逃脱这个恶性循环。其实不然,问题的核心在于余闲的缺乏。为了远离稀缺陷阱,仅拥有比寻常欲望更多的资源是不够的。我们要拥有足够的余闲(或其他一些机制),以应对任何时候都有可能突然出现的重大事件。社会学家,特别是经济学家,很早就了解到不确定性会对结果产生绝大的影响。我们知道,不确定的回报会减少投资,不确定的收入会让人焦虑、迟疑。阶段性的稀缺会引发一些行为,而这些行为会最终将我们拖回稀缺陷阱之中。原理稀缺陷阱的威胁,需要拥有足够的余闲去应对这个世界中林林总总的突发事件。
人们可能认为,在资源充裕阶段,我们会精打细算,充满远见卓识。事实并非如此。研究证明,在资源充裕的时候,我们尤其容易犯下拖延的毛病。
改变心态,套利稀缺陷阱的唯一希望。稀缺并非个人特质,而是自身创造的环境条件所引发的结果,而这些条件是可以被管理的。
 
穷人为什么穷
无能可以导致贫穷,贫穷也可以导致无能。
大脑自由才能成为合格家长。
穷人缺钱又缺带宽
任何形式的技能习得,无论是去学习社交技巧还是养成良好的消费习惯,都需要带宽。如果穷人缺少带宽,那么他们就无法很好的掌握这些使实用技能。
 
如何从稀缺走向富足
节省带宽的方法才是好方法
让”警报“来得更早些
包容穷人的不当行为
 
如何解决组织中的时间稀缺
不要救火,救火不仅仅会导致失误,而且还会导致完全可以被预见的失误类型:重要但不紧急的任务会被人们所忽略
对组织而言,有一种解决方法就是,对余闲进行明确的管理,确保余闲的存在。
真正有效率的劳动者,不会整天马不停蹄地工作,而是闲庭信步般轻松愉悦[……]

Read more

分类: 读书 标签:

许多人没有理解透彻的一些基础概念

2015年2月8日 1,963 views 没有评论

基础概念的交流和理解一致,才有助于意识的沟通一致。才有助于意识层面的交流。

资源(resource)物理服务器的功能组件,一些软件资源也可以被衡量,比如线程池、进程数等。系统的运行,需要各种资源,对于资源列表的确定,我们可以凭借对系统的了解确定,也可以通过绘制系统的功能块图的方式确定要衡量的资源。

常见的物理资源如下,

CPU(cpu sockets)、CPU核(cores)、硬件线程(虚拟线程)hardware threads( virtual threads)

内存

网络接口

存储设备

存储或者网络的控制器

内部高速互联

 

负载(load):有多少任务正在施加给系统,也就是系统的输入,要被处理的请求。对于数据库,那么负荷就包括了客户端段发送过来的命令和查询。

负载如果超过了设计能力,往往导致性能问题。应用程序可能因为软件应用的配置或者系统架构导致性能降低,比如,如果一个应用程序是单线程的,无疑它会受制于单线程架构,因为只能利用一个核,后续的请求都必须排队,不能利用其他核,但也可能仅仅是因为负载太多了。负载太多将导致排队、高延时,比如,一个多线程应用程序,你发现所有cpu都是忙的,都在处理任务,这个时候,仍然发生排队,系统负载很高,这个时候很可能是施加了过高的负荷。

如果在云中,你也许可以简单地增加更多的节点来处理过高的负荷,在一般的生产应用中,简单增加节点有时解决不了问题,你需要进行调优和架构迭代。

 

利用率(ulilization)利用率用来衡量提供服务的资源的忙碌程度,它基于某一段时间间隔内,系统资源用于真正执行工作的时间百分比。即,

利用率 = 忙的时间  /  总计时间

利用率可以是基于时间的,比如cpu的利用率:某颗cpu的利用率或者整体系统的cpu利用率。比如磁盘的利用率,我们可使用iostat命令检查%util。

利用率也可以是基于容量的,它可以表示我们的磁盘或者内存或者网络的使用程度,比如90%的磁盘空间被使用,80%的内存被使用,80%的网络带宽被使用。

可以用高速公路的收费站的例子来类比:

利用率表现为当前有多少收费亭正在忙于服务一辆车。利用率100%,就表示所有收费亭都正在处理收费,你找不到空闲的收费亭,你必须排队。那么在高峰时刻,可能许多时候是100%的利用率,但如果给出全天的利用率数据,也许只有40%,那么如果只关注全天的这个利用率数据就会掩盖一些问题。

往往利用率的高位会导致资源饱和。利用率100%往往意味着有瓶颈,可以检查饱和度、系统性能加以确定。该资源不能提供服务的程度被标识为它的饱和度,见下面饱和的详细解释。

利用率超过60%也可能有问题,如果是检测的粒度比较大,很可能掩盖了偶尔的100%的峰值,一些资源,如磁盘,在60%的利用率的时候,就开始性能变差了。

 

响应时间(response time)也叫延迟,指操作执行需要的耗时。它包括了等待时间和执行时间。对于一个数据库查询,那么响应时间包括了从客户端发布查询命令到数据库处理查询,传输结果给客户端的所有时间。延迟可以在不同的环节衡量,比如访问站点的装载时间包括DNS延迟、tcp连接延迟、tcp数据传输时间。延迟也可以在更高的级别理解,包括数据传输时间和其他时间,比如从用户点击链接到网页内容传输,并在用户的电脑屏幕上渲染完毕,这也是一种延迟。延迟是以时间做量度来衡量的,可以很方便地进行比较,其他的一些指标不容易衡量、比较,比如IOPS,那么,你可以转化为延迟来进行比较。

 

 

伸缩性(scalability)我们可以理解为两个层面的意思。一、在资源的利用率不断增加的情况下,响应时间和资源利用率之间的关系,资源利用率越高,响应时间仍然能保持稳定,那么我们说他的伸缩性好,但如果资源利用率高,响应时间开始劣化,我们认为其伸缩性不佳。二、伸缩性还有一层意义,表征系统不断扩展的能力,系统通过不断增加节点或者资源,处理不断增长的负荷,同时依然能够保持合理的响应时间。

吞吐(throughput)处理任务的速率。对于网络传输,吞吐一般指每秒传输的字节数,对于数据库来说,指的是每秒查询数(QPS)或者每秒事务数。

并发(concurrency)指得是系统能够并行执行多个操作的能力。如果数据库能够充分利用CPU的多核能力,那么往往意味着更高的并发处理能力。

容量(capacity)容量指的是系统可以提供的处理负荷的能力。我们日常运维中有一项很重要的工作就是容量规划,即确保随着负荷增长,我们的系统仍然能够处理负荷,也就是说,当我们的吞吐增加后,我们仍然能够确保服务良好、稳定。容量也指我们的资源使用极限,比如我们的磁盘空间占用,在磁盘空间到达一定阀值后,我们可能要考虑扩容。

我们需要熟悉以上概念,并了解他们之间的关系,一般来说,随着负荷上升,吞吐率将上升,吞吐曲线会一直是线性的,我们的系统的响应时间开始一个阶段会保持稳定,但是到达某个点后,性能开始变差,响应时间变得更长,以后随着负荷继续增加,此时我们的吞吐将不能再继续增长,甚至下降,而响应时间可能变得不可接受。有一种例外情况是,应用服务器返回错误状态码,比如web服务器返回503错误,由于基本不消耗资源,难以到达极限,所以返回错误码的的吞吐曲线会保持线性。

 

 

MongoDB 3.0到来

2015年2月4日 2,711 views 没有评论

MongoDB 3.0:7到10 倍的性能提升、减少80%的存储,还有宣称的大大提高的维护性。

对比之下,以前的存储引擎就是个渣,当然,我早知道,它的存储引擎一直就是个渣,所以关注,但一直拒绝在生产上用。

其实MongoDB的问题一直存在,只是市场营销部门太过抢眼,商业公司在这方面很强大,因为你必须给外面一种光鲜的外表,你才能有更好的估值,你才能上市,各种场合下,它都是高大上,任何一个小小的利好,都会被放大,你可以看到各种统计,它貌似比任何产品的风头都更劲,所以我对于一些引用的数据库产品的占用率保持怀疑。

而对于用户出现的问题,官方却各种回避,不愿意承认其固有的存储引擎问题。我以前断言,这家公司只有被收购了,换一个引擎,他才可能发展起来,没想到他能够收购另一家公司,换掉自己的存储引擎。

一家公司的市场部门太过强势,不一定是好事,因为社区会不买账,用户对官方的宣告越来越怀疑,这个世界永远不缺“小白用户” ,许多公司的各种CIO,也许仅仅是相信他们,就引入了这个产品,我们也经常看到各种分享mongoDB的演讲,许多研发人员投入了很多精力,也有许多线上的案例,但这中间的选择,被坑,却不得而知,看来国人和外国人都比较好面子,分享成果,分享实践是开心的,分享被坑的经历则缺少动力, 所以我们无从知道这些选择了MongoDB的公司最终发生了什么?他们的项目是否跑得很好,是否崩溃而无计可施,是否性能很差而仍然不得不使用?

这次换了存储引擎,期望走得更好。

分类: 数据库 标签:

MySQL DBA职位

2015年2月3日 2,267 views 没有评论
分类: 互联网技术 标签:

web服务器优化(笔记)

2014年12月22日 2,309 views 没有评论

web服务器问题.

  1. 如果使用prefork的是有问题,不过现在的维护人员使用apache一般是work模式的了.

2. apache注释掉多余的模块,php.ini注释掉多余的模块, 虽然apache是通用的,但专用的话,我们会获得更好得多的性能. 比如静态内容的话,前端可以用nginx来代替.

3. 使用squid或者vanish缓存内容;

  1. 对于静态和动态的内容设置过期策略;

5. Don’t let Apache spoon-feed the client . 这不仅慢,也让dos攻击变得容易. 前端可以放置负载均衡设备(有buffer),nginx,squid或者Apache in event-driven mode 在应用前端;

6. 启用gzip;

7. apache的keep alive 不要设置得太长. 如果前端有负载均衡设备的话,负载均衡设备可以让连接apache的连接少很多的话,那么设置较大的值成为可能;

 

 

找到合适的并发设置

一般web服务器的连接有一个最优的值.

比如php-fpm的连接, 开得太多或者太少了,都不行. 需要自己小心找出一个比较良好的设置.

一般cpu瓶颈型的负载,最优的并发大概是cpu核的个数,但并发进程并不都是在run的,可能还在等待io,等待数据库查询,网络传输等, 所以最优的并发往往大于cpu核数.

可profiling下 ,调整不同的并发,检测性能

 

 

可参考下 High Performance Web Sites , Even Faster Web Sites

分类: 互联网产品 标签: ,