优化

从网上搜集的各种优化，标记下。 1. 网络带宽 Hadoop集群的服务器在规划时就在统一的交换机下，这是在官方文档中建议的部署方式。 但是我们的这台交换机和其他交换机的互联带宽有限，所以在客户端遇到了HDFS访问速度慢的问题。 把操作集群的客户端也联入DataNode的交换机内部，解决了这个问题。 2. 系统参数 对ulimit -c的修改也是官方文档建议的修改，在集群只有10台服务器时，并没有遇到问题。 随着机器增加和任务增加，这个值需要改的更大。 3. 配置文件管理 这个集群用的是Cloudera发行的版本，配置文件默认存在/etc/hadoop/conf位置。这是一个只有root才能修改的位置。 为了修改方便，我把配置文件统一保存在一台机器上，修改后用脚本分发。保证所有服务器都是统一的配置。 4. mapred.tasktracker.map.tasks.maximum 这个参数控制每个TaskTracker同时运行的Map任务数。 以前的设置是和CPU核数相同的，偶尔遇到任务挤占DataNode资源的问题。 现在改成map+reduce+1==num_cpu_cores。 5. 严格控制root权限 Cloudera的发行版会创建一个hadoop用户，各种守护进程都应该以这个用户运行。 曾经有误操作（/usr/lib/hadoop/bin/hadoop datanode &

当我们被人雇来监测MySQL性能时，人们希望我们能够检视一下MySQL配置然后给出一些提高建议。许多人在事后都非常惊讶，因为我们建议他们仅仅改动几个设置，即使是这里有好几百个配置项。这篇文章的目的在于给你一份非常重要的配置项清单。 我们曾在几年前在博客里给出了这样的 建议 ，但是MySQL的世界变化实在太快了！ 写在开始前… 即使是经验老道的人也会犯错，会引起很多麻烦。所以在盲目的运用这些推荐之前，请记住下面的内容： 一次只改变一个设置！这是测试改变是否有益的唯一方法。 大多数配置能在运行时使用SET GLOBAL改变。这是非常便捷的方法它能使你在出问题后快速撤销变更。但是，要永久生效你需要在配置文件里做出改动。 一个变更即使重启了MySQL也没起作用？请确定你使用了正确的配置文件。请确定你把配置放在了正确的区域内(所有这篇文章提到的配置都属于 [mysqld]) 服务器在改动一个配置后启不来了：请确定你使用了正确的单位。例如，innodb_buffer_pool_size的单位是MB而max_connection是没有单位的。 不要在一个配置文件里出现重复的配置项。如果你想追踪改动，请使用版本控制。 不要用天真的计算方法，例如”现在我的服务器的内存是之前的2倍，所以我得把所有数值都改成之前的2倍“。 基本配置 你需要经常察看以下3个配置项。不然，可能很快就会出问题。 innodb

Python编程规范及性能优化 Ptyhon编程规范 编码 所有的 Python 脚本文件都应在文件头标上 # -*- coding:utf-8 -*- 。设置编辑器，默认保存为 utf-8 格式。 注释 业界普遍认同 Python 的注释分为两种的概念，一种是由 # 开头的“真正的”注释，另一种是 docstrings。前者表明为何选择当前实现以及这种实现的原理和难点，后者表明如何使用这个包、模块、类、函数（方法），甚至包括使用示例和单元测试。 坚持适当注释原则。对不存在技术难点的代码坚持不注释，对存在技术难点的代码必须注释。但与注释不同，推荐对每一个包、模块、类、函数（方法）写 docstrings，除非代码一目了然，非常简单。 缩进 Python 依赖缩进来确定代码块的层次，行首空白符主要有两种：tab 和空格，但严禁两者混用。如果使用 tab 缩进，设定 tab 为 4 个空格。 公司内部推荐使用 4 个空格的 tab 进行缩进。 空格 空格在 Python 代码中是有意义的，因为 Python 的语法依赖于缩进，在行首的空格称为前导空格。在这一节不讨论前导空格相关的内容，只讨论非前导空格。非前导空格在 Python 代码中没有意义，但适当地加入非前导空格可以增进代码的可读性。 1）在二元算术、逻辑运算符前后加空格：如 a = b + c； 2）在一元前缀运算符后不加空格

由于关键代码区可以跨越了多个函数或数据结构，需要有更通用的同步方法：锁。 内核中最常见的一种锁就是自旋锁。相同的锁可用于多处。 自旋锁可用在不可睡眠的场景，如中断处理函数。自旋锁是一种互斥设备，只有两个值： “ 锁定 ” 和 “ 非锁定 ” 。它通常实现为一个整数值的某个比特位。想获取某个锁的代码首先测试相关的位，如果锁可得，则该位的 “ 锁定 ” 位被置位，代码继续执行，反之，代码将进入一个紧凑的循环，不停地检测锁定位直至自旋锁变得可得。该循环是自旋锁的 “ 旋转 ” 部分。自旋锁主要用于多处理器的情况下。 1. 通用自旋锁 相关操作： DEFINE_SPINLOCK(mr_lock) spinlock_tmy_lock = SPIN_LOCK_UNLOCKED;// 静态初始化 或 voidspin_lock_init(spinlock_t *lock);// 动态初始化 获取自旋锁 voidspin_lock(spinlock_t *lock);// 不可中断的 释放自旋锁 voidspin_unlock(spinlock_t *lock); 使用自旋锁时要禁止中断，禁止睡眠，并且应当尽可能减少占用自旋锁的时间。 其他函数 voidspin_lock(spinlock_t *lock); // 在获取自旋锁之前，禁止中断 voidspin_lock_irqsave

请求数量 合并脚本和样式表，拆分初始化负载 请求带宽 移除重复脚本 缓存利用 使Ajax可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 来源： oschina 链接： https://my.oschina.net/u/1011494/blog/163945

现有问题 创建项目失败 mysql插入失败,资源忙/主键重复 无法正常发送EDM redis数据丢失 设计不合理，自增ID改用hash；项目与ID映射改为sorted set redis耗费大量内存 考虑导出到csv 设置过期时间，从redis剔除 搜索 引入搜索引擎whoosh 现有分页功能不完善 优化分页方案，更人性化。 来源： oschina 链接： https://my.oschina.net/u/2351685/blog/603349

前言 SQL优化是程序开发中经常遇到的问题，尤其是在程序规模不断扩大的时候。SQL的好坏不仅制约着程序的规模，影响着用户的体验，甚至威胁着信息的安全。 我们经常听到说哪家平台挂了，哪家网站被黑了，但我们不知道，其实这些平台挂了、被黑了的原因很多时候在于SQL不够健壮。SQL不够健壮易造成数据查询超时、SQL注入、信息泄漏等问题。 SQL优化归根到底是SQL语句的优化，索引的优化。由于很多数据库自带的分析工具不够强大便捷，很多时候要想写出好一点的SQL语句完全凭经验。这也是为什么有人说看一个程序员资历深不深就看他写的SQL好不好的原因。 凭经验做事不总是那么可靠的，况且也并不是人人都有那么多的经验。那如果不靠经验，那新手怎么办？答，使用SOAR！ 什么是SOAR SOAR是SQL Optimizer And Rewriter的简称。SOAR是一个对SQL进行优化和改写的自动化工具，由小米人工智能与云平台的数据库团队开发与维护。现在在GitHub上有4000多星。 功能特点 SOAR有如下功能特点： 跨平台支持（支持Linux,、Mac、Windows环境） 目前只支持 MySQL 语法族协议的SQL优化 支持基于启发式算法的语句优化 支持复杂查询的多列索引优化（UPDATE, INSERT, DELETE, SELECT） 支持EXPLAIN信息丰富解读 支持SQL指纹、压缩和美化

依据Hadoop的计算框架特性，衍生出来的问题？ 数据量大不是问题，数据倾斜是个问题。 jobs数比较多的作业运行效率相对比较低，比如即使有几百行的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的。 sum,count,max,min等UDAF，不怕数据倾斜问题,hadoop在map端的汇总合并优化，使数据倾斜不成问题。 count(distinct ),在数据量大的情况下，效率较低，如果是多count(distinct )效率更低，因为count(distinct)是按group by 字段分组，按distinct字段排序，一般这种分布方式是很倾斜的。举个例子：比如男uv,女uv，像淘宝一天30亿的pv，如果按性别分组，分配2个reduce,每个reduce处理15亿数据。 优化手段 好的模型设计事半功倍。 解决数据倾斜问题。 减少job数。 设置合理的map reduce的task数，能有效提升性能。(比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够)。 了解数据分布，自己动手解决数据倾斜问题是个不错的选择。set hive.groupby.skewindata=true;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据

优化级别说明（仅供参考） ： 则其中的 Code Optimization 栏就是用来设置 C51 的优化级别。共有 9 个优化 级别（书上这么写的） ，高优化级别中包含了前面所有的优化级别。现将各个级 别说明如下： 0 级优化： 1 、 常数折叠：只要有可能，编译器就执行将表达式化为常数数字的计算，其中 包括运行地址的计算。 2 、 简单访问优化：对 8051 系统的内部数据和位地址进行访问优化。 3 、 跳转优化：编译器总是将跳转延至最终目标上，因此跳转到跳转之间的命令 被删除。 1 级优化： 1 、 死码消除：无用的代码段被消除。 2 、 跳转否决：根据一个测试回溯，条件跳转被仔细检查，以决定是否能够简化 或删除。 2 级优化： 1 、 数据覆盖：适于静态覆盖的数据和位段被鉴别并标记出来。连接定位器 BL51 通过对全局数据流的分析，选择可静态覆盖的段。 3 级优化： 1 、 “ 窥孔 ” 优化：将冗余的 MOV 命令去掉，包括不必要的从存储器装入对象及 装入常数的操作。另外如果能节省存储空间或者程序执行时间，复杂操作将由简 单操作所代替。 4 级优化： 1 、 寄存器变量：使自动变量和函数参数尽可能位于工作寄存器中，只要有可能， 将不为这些变量保留数据存储器空间。 2 、扩展访问优化：来自 IDATA 、 XDATA 、 PDATA 和 CODE 区域的变量直接包

作为Python爱好者，需要了解.py脚本的基本运行机制及特性： 在很多工作上Python的运行流程基本上取决于用户，因此源码不需要编译成二进制代码（否则无法实现大部分贴近用户的特性），而直接从源码运行程序。当我们运行python文件程序的时候，Python解释器将源码转换为字节码，然后再由解释器来执行这些字节码。 因此总的来说，它具有以下三条特性 源码距离底层更远（根据官方文档的解释。不说，你们也感觉得到。） 运行时都需要生成字节码，交由虚拟机执行。（你们问我虚拟机在哪儿？！你们也不看看各自都是用什么软件执行的！没错，就是解释器，别和我说是IDLE啊。虚拟机具体实现了由switch-case语句构成的框架函数PyEval_EvalFrameEx，刚刚说的字节码就是这货执行的。） 每次执行脚本，虚拟机总要多出加载和链接的流程。（所以呢，相比于编译型语言就有点慢了。这与“有丝分裂间期”一样，准备东西也要花时间啊！） 那么，有人要问了：“不是说，运行时总要生成字节码么！那，字节码都去哪儿了？” 咳咳，别急！容我先说说，虚拟机它是怎么执行脚本的： 完成模块的加载和链接； 将源代码翻译为PyCodeObject对象（这货就是字节码），并将其写入内存当中（方便CPU读取，起到加速程序运行的作用）； 从上述内存空间中读取指令并执行； 程序结束后，根据命令行调用情况（即运行程序的方式