Posts

Gentoo emerge命令 Gentoo的包管理工具称为portage。emerge是这个portage的字符界面管理工具,图形界面工具还有portato,porthole,kuroo,himerge等。 ebuild ebuild是Portage包管理程序的根本。它是一个纯文本文件,而每一个ebuild都会对应一个包 (软件包) 。ebuild会告诉 portage要下载的文件、该包可运行的平台、如何编译它、它所依赖的ebuild和一些修补代码的patch。Portage内有一个ebuild大集合,称为Portage tree,是gentoo网站所提供的ebuild。它包含了大部份常用的包,并会不时更新。如果要使用的包不在其内,也可以手动加入。 USE标志 USE标志的设置位于Gentoo系统的/etc/make.conf文档中,作用是使得Emerge在处理依赖关系的时候可以做到不安装不需要的软件包 (例如安装Gnome的用户没有必要因为一个软件包的依赖关系而安装KDE与Qt) ,而安装指定的软件包 (同样以Gnome举例,Gnome的用户基本上都会安装GTK+) ,把系统的设置专注化。 Gentoo的emerge命令参数用法详解 查找名称包含mozilla的包 emerge -s mozilla emerge search mozilla 查找描述包含mozilla emerge -S mozilla emerge -searchdesc mozilla 使用本地编好的包,没有就下源码(尽量避免编译) emerge -k mozilla emerge -usepkg mozilla 只使用本地编好的,否则不安装(绝对不编译,所有依赖的包都有binary才装) emerge -K mozilla emerge -usepkgonly mozilla 卸载 emerge -C mozilla emerge unmerge mozilla 升级portage树 emerge -sync 下载snapshot包来完成sync emerge-webrsync 查看已安装包的changelog emerge -pl mozilla emerge -pretend -changelog mozilla 查看依赖关系(这个包还没装) (–pretend保证这一次操作实际上不做任何事情,可以跟任何options组合) emerge -p mozilla emerge -pretend mozilla ...

gentoo emerge install unstable version 安装特定版本的软件 emerge “=python-3.2” emerge “<python-3.2” You can also manually edit the /etc/portage/package.keywords file to unmask keyword_masked packages Code: echo www-client/seamonkey » /etc/portage/package.keywords If /etc/portage doesn’t exist then create it Code: mkdir /etc/portage

DataX http://www.open-open.com/lib/view/open1325771223625.html DataX是什么? DataX是一个在异构的数据库/文件系统之间高速交换数据的工具,实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem) 之间的数据交换,由淘宝数据平台部门完成。 DataX用来解决什么? 目前成熟的数据导入导出工具比较多,但是一般都只能用于数据导入或者导出,并且只能支持一个或者几个特定类型的数据库。这样带来的一个问题是,如果我们拥 有很多不同类型的数据库/文件系统(MySQL/Oracle/Rac/Hive/Other…),并且经常需要在它们之间导入导出数据,那么我们可能需 要开发/维护/学习使用一批这样的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader /MySQLdumper…)。而且以后每增加一种库类型,我们需要的工具数目将线性增长。(当我们需要将MySQL的数据导入oracle的时候,有没 有过想从jdbcdump和dbloader上各掰下来一半拼在一起到冲动？) 这些工具有些使用文件中转数据,有些使用管道,不同程度的为数据中转带来额外开销,效率差别很非常大。很多工具也无法满足ETL任务中常见的需求,比如日 期格式转化,特性字符的转化,编码转换。另外,有些时候,我们希望在一个很短的时间窗口内,将一份数据从一个数据库同时导出到多个不同类型的数据库。 DataX正是为了解决这些问题而生。 我们只需要针对新增的数据源开发的一套Reader/Writer插件,即可实现任意数据的互导 DataX特点? 在异构的数据库/文件系统之间高速交换数据 采用Framework + plugin架构构建,Framework处理了缓冲,流控,并发,上下文加载等高速数据交换的大部分技术问题,提供了简单的接口与插件交互,插件仅需实现对数据处理系统的访问 运行模式: stand-alone 数据传输过程在单进程内完成,全内存操作,不读写磁盘,也没有IPC 开放式的框架,开发者可以在极短的时间开发一个新插件以快速支持新的数据库/文件系统。 (具体参见《DataX插件开发指南》) DataX结构模式 (框架+插件) Job: 一道数据同步作业 Splitter: 作业切分模块,将一个大任务与分解成多个可以并发的小任务. Sub-job: 数据同步作业切分后的小任务 Reader(Loader): 数据读入模块,负责运行切分后的小任务,将数据从源头装载入DataX Storage: Reader和Writer通过Storage交换数据 Writer(Dumper): 数据写出模块,负责将数据从DataX导入至目的数据地 DataX框架内部通过双缓冲队列、线程池封装等技术, 集中处理了高速数据交换遇到的问题, 提供简单的接口与插件交互, 插件分为Reader和 Writer 两类, 基于框架提供的插件接口,可以十分便捷的开发出需要的插件。比如想要从oracle导出数据到MySQL,那么需要做的就是开发出 OracleReader和MySQLWriter插件,装配到框架上即可。并且这样的插件一般情况下在其他数据交换场合是可以通用的。更大的惊喜是我们 已经开发了如下插件: Reader插件 hdfsreader : 支持从hdfs文件系统获取数据。 MySQLreader: 支持从MySQL数据库获取数据。 sqlserverreader: 支持从sqlserver数据库获取数据。 oraclereader : 支持从oracle数据库获取数据。 streamreader: 支持从stream流获取数据 (常用于测试) httpreader : 支持从http URL获取数据。 Writer插件 hdfswriter: 支持向hdbf写入数据。 ...

正则, 惰性匹配(lazy) .*? http://www.nowamagic.net/librarys/veda/detail/1038 使用场景 有时，我们想用正则匹配以某个子串开头，且以某个子串或字符结尾的子字符串，但是结尾的字串或字符在原字符串中出现了多次，但我们只想匹配从开始处到第一次出现的地方，换句话说，想得到开始和结尾之间内容最少的匹配。 正则的贪婪与非贪婪（惰性） 通常使用如下字符类描述前导字符的重复特征： ?: 告诉引擎匹配前导字符0次或一次。事实上是表示前导字符是可选的。 +: 告诉引擎匹配前导字符1次或多次。 *: 告诉引擎匹配前导字符0次或多次。 {min, max}: 告诉引擎匹配前导字符min次到max次。min和max都是非负整数。如果有逗号而max被省略了，则表示max没有限制；如果逗号和max都被省略了，则表示重复min次。 因此 {0,} 和 * 一样，{1,} 和 + 的作用一样。 贪婪 默认情况下，? + * {min, max}都是贪婪的，也就是说，它会根据前导字符去匹配尽可能多的内容。 非贪婪（惰性） 非贪婪就是匹配尽可能少的内容。 原理浅析 结合实例来分析哈基于正则的引擎对文本的匹配过程。原始字符串：This is a first test，使用正则<.+>来匹配HTML标签，期望第一次匹配得到，第二次匹配得到，实际却是第一次匹配就得到了first。 来看看匹配过程，第一个记号是<，这是一个文本字符，匹配其自身。第二个符号是.，匹配了字符E，然后+一直可以匹配其余的字符，直到一行的结束。然后到了换行符，匹配失败（.不匹配换行符）。于是引擎开始对下一个正则表达式符号进行匹配，即试图匹配>。到目前为止，<.+已经匹配了first test。引擎会试图将>与换行符进行匹配，结果失败了。于是引擎进行回溯。回溯后的匹配状况是 <.+ 匹配 first tes。于是引擎将>与t进行匹配。显然还是会失败。这个过程继续，直到 <.+ 匹配 first</EM，>与>匹配。于是引擎找到了一个匹配first。记住，正则导向的引擎是急切的，所以它会急着报告它找到的第一个匹配。而不是继续回溯，即使可能会有更好的匹配，例如。所以我们可以看到，由于+的贪婪性，使得正则表达式引擎返回了一个最左边的最长的匹配。 ...

Redis客户端 http://ourjs.com/detail/555975b9329934463f00000f Redis是一个超精简的基于内存的键值对数据库 (key-value) ，一般对并发有一定要求的应用都用其储存session，乃至整个数据库。 参见: node.js与redis结合使用。 不过它公自带一个最小化的命令行式的数据库管理工具，有时侯使用起来并不方便。不过Github上面已经有了很多图形化的管理工具，而且都针对REDIS做了一些优化，如自动折叠带schema的key等。 Redis Desktop Manager 一款基于Qt5的跨平台Redis桌面管理软件 支持: Windows 7+, Mac OS X 10.10+, Ubuntu 14+ 特点: C++ 编写，响应迅速，性能好。但不支持数据库备份与恢复。 项目地址: https://github.com/uglide/RedisDesktopManager Redis Client 项目简介: 使用Java编写，功能丰富，缺点是性能稍差，网络不好时，会不时断线。 项目地址: https://github.com/caoxinyu/RedisClient Redis Studio 项目简介: 又一个C++编写的redis管理工具，仅支持windows平台，支持xp操作系统。 项目地址: https://github.com/cinience/RedisStudio ps: 后面两款为国人开发。

english words right now, currently “Right now” 和 “currently” 在英语中都指“现在”，但在用法和强调的侧重点上存在一些区别。 “Right now” 强调即时性: “Right now” 强调“此时此刻”，表示事情正在发生，或者需要立即发生。它通常指一个非常具体、短暂的时间点。 紧迫性: 它常常带有紧迫感或命令的意味，尤其是在祈使句中。 例如：“We need a doctor, right now!"（我们现在就需要医生！）这句话表达了强烈的紧迫性。 “Stop it right now!"（立刻停止！） 口语化: “Right now” 在口语中更常见，语气通常比 “currently” 更不正式。 例子: “I can’t talk right now, but I’ll call you this evening."（我现在不能说话，但我今晚会给你打电话。） “We’re very busy right now."（我们现在非常忙。） “It is raining right now."（现在正在下雨。） “Currently” 强调持续性/一段时间: “Currently” 指的是“目前”或“当前”，表示事情在一段时间内持续进行，不一定是精确到某个瞬间。它暗示了情况可能会在将来发生变化。 例如：“Syria is currently at war."（叙利亚目前处于战争状态。）这句话更合适，因为它反映了战争的“持续性”。 “Currently, there is no peer-reviewed research on this subject."（目前，关于这个主题还没有经过同行评审的研究。）这暗示了这种情况可能已经持续了一段时间。 正式语境: “Currently” 通常比 “right now” 更正式，在书面语和商务语境中更常用。 暗示变化: 使用 “currently” 常常暗示当前的状态不是永久的，未来可能会改变。 例如：“If you say you’re not currently dating anyone, you’re hinting that you might in the future."（如果你说你目前没有和任何人约会，你暗示你将来可能会。） 例子: “She is currently working as a lab technician."（她目前是一名实验室技术员。） “The Director is currently having talks in the US."（主管目前正在美国进行会谈。） “Our social club currently has about 80 members."（我们的社交俱乐部目前大约有80名成员。）

java.sql.Timestamp cannot be cast to java.sql.Date java.sql.Timestamp cannot be cast to java.sql.Date date数据库sqlstringjava java.lang.ClassCastException: java.sql.Timestamp cannot be cast to java.sql.Date 我在往数据库插入数据时用的是string型,SQL应该会转换为java.sql.Date型,但是取出值的时候不也应该是java.sql.Date型么? 但是这么会报这样的错误?还有一个问题,用你说的这种方式生成的java.sql.Date好像只有年月日, 我想要取到很详细的当前时间,包括到毫秒级别,这样应该怎样生成呢??? java.sql.Date->java.sql.Timestamp new java.sql.Timestamp(yourDate.getTime()); java.sql.Timestamp->java.sql.Date new java.sql.Date(yourTimestamp.getTime()); 界面要显示毫秒的话,在date传到前面时转化格式即可！ Date b_date = new Date();(着这是util类型的)！ ps.setDate(new java.sql.Date(b_date.getTime()));(这是插入数据库是的Date)! 其中 (new java.sql.Date(b_date.getTime()));是把java类型的Date转换成sql类型的Date

redis data type, 数据类型 https://redis.io/topics/data-types https://redis.io/topics/data-types-intro String - 字符串 List - 列表 Set - 无序集合 Hashes - 哈希/散列表 Sorted sets - 有序集合 Stream - 消息队列 Bitmaps, url: redis-bitmap HyperLogLogs Hyperloglog https://segmentfault.com/a/1190000020523110 geospatial https://blog.csdn.net/zhang197093/article/details/72979038

java main函数 执行spring 代码 package com.zuidaima.test; import org.springframework.context.support.GenericXmlApplicationContext; import com.service.UserService; public class Main { public static void main(String[] args) throws InterruptedException { GenericXmlApplicationContext context = new GenericXmlApplicationContext(); context.setValidating(false); context.load("classpath\*:applicationContext\*.xml"); context.refresh(); UserService userService = context.getBean(UserService.class); while (true) { System.out.println(userService.findUser()); Thread.sleep(10000); } } }

GPU # AMD 显卡 查看 显存等信息, 显存使用率 sudo apt install radeontop radeontop

描述性统计与性能结果分析 http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html 版权声明: 本文可以被转载，但是在未经本人许可前，不得用于任何商业用途或其他以盈利为目的的用途。本人保留对本文的一切权利。如需转载，请在转载是保留此版权声明，并保证本文的完整性。也请转贴者理解创作的辛劳，尊重作者的劳动成果。 作者: 陈雷 (Jackei) 邮箱: jackeichan@gmail.com Blog: http://jackei.cnblogs.com LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出"描述性统计"方法在性能测试结果分析中的应用。 为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？ 假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？ 假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？ 为了解答上面的疑问，我们先来看一张表: 在上面这个表中包含了几个不同的列，其含义如下: CmdID 测试时被请求的页面 NUM 响应成功的请求数量 MEAN 所有成功的请求的响应时间的平均值 STD DEV 标准差 (这个值的作用将在下一篇文章中重点介绍) MIN 响应时间的最小值 50 th(60/70/80/90/95 th) 如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义 MAX 响应时间的最大值 我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下: 90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％； 对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况； 从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的； 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的； 如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况； 在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的； 上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。 事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。 ...

JMeter Aggregate Report 是 JMeter 常用的一个 Listener，中文被翻译为"聚合报告"。今天再次有同行问到这个报告中的各项数据表示什么意思，顺便在这里公布一下，以备大家查阅。 如果大家都是做Web应用的性能测试，例如只有一个登录的请求，那么在Aggregate Report中，会显示一行数据，共有10个字段，含义分别如下。 Label: 每个 JMeter 的 element (例如 HTTP Request) 都有一个 Name 属性，这里显示的就是 Name 属性的值 #Samples: 表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100 Average: 平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间 Median: 中位数，也就是 50％ 用户的响应时间 90% Line: 90％ 用户的响应时间 Note: 关于 50％ 和 90％ 并发用户数的含义，请参考下文 http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html Min: 最小响应时间 Max: 最大响应时间 Error%: 本次测试中出现错误的请求的数量/请求的总数 Throughput: 吞吐量——默认情况下表示每秒完成的请求数 (Request per Second) ，当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数 KB/Sec: 每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec 一、基本概念 ...

Netty 下载文件 http://www.open-open.com/lib/view/open1409642102932.html 本实例主要参考的是官网的examples: 点击这里使用场景: 客户端向Netty请求一个文件,Netty服务端下载指定位置文件到客户端。 本实例使用的是Http协议,当然,可以通过简单的修改即可换成TCP协议。 需要注意本实例的关键点是,为了更高效的传输大数据,实例中用到了ChunkedWriteHandler编码器,它提供了以zero-memory-copy方式写文件。 第一步: 先写一个HttpFileServer ? package NettyDemo.file.server; import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.Channel; import io.netty.channel.ChannelInitializer; import io.netty.channel.ChannelPipeline; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioServerSocketChannel; import io.netty.handler.codec.http.HttpObjectAggregator; import io.netty.handler.codec.http.HttpServerCodec; import io.netty.handler.logging.LogLevel; import io.netty.handler.logging.LoggingHandler; import io.netty.handler.stream.ChunkedWriteHandler; /*************************** Reserved. BidPlanStructForm.java Created on 2014-8-19 Author: <a href=mailto:wanghouda@126.com>wanghouda @Title: HttpFileServer.java @Package NettyDemo.file.server Description: Version: 1.0 **************************/ public class HttpFileServer { static final int PORT = 8080; public static void main(String[] args) throws Exception { ...

PostgreSQL execution plan, explain, 执行计划 -- 查看执行计划 EXPLAIN select * from table_0 where id < 1000; -- EXPLAIN ANALYZE - 查看实际执行情况（推荐） EXPLAIN ANALYZE select * from table_0 where id < 1000; -- 更详细的执行计划 EXPLAIN (ANALYZE, BUFFERS, VERBOSE, FORMAT TEXT) select * from table_0 where id < 1000; Seq Scan, 全表扫描，顺序扫描 全表扫描，也叫顺序扫描，扫描时把表中所有的数据块从头到尾遍历一边，找到复合条件的数据块。全表扫描在在explain中使用Seq Scan表示 IndexOnly Scan IndexOnly Scan 是覆盖索引扫描，所需的返回结果能被所扫描的索引全部覆盖 https://www.jianshu.com/p/682d798aee1f 了解 PostgreSQL 执行计划对于开发人员来说是一项关键技能，执行计划是我们优化查询，验证我们的优化查询是否确实按照我们期望的方式运行的重要方式。 PostgreSQL 数据库中的查询生命周期 每个查询都会经历不同的阶段，了解每个阶段对数据库的意义很重要。 查询生命周期 第一阶段是通过 Postgres 的客户端连接到数据库。 ...

jmap 、基本参数: -dump:[live,]format=b,file= 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件. -finalizerinfo 打印正等候回收的对象的信息. -heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况. -histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀"*". 如果live子参数加上后,只统计活的对象数量. -permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来. -F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效. -h | -help 打印辅助信息 -J 传递参数给jmap启动的jvm. pid 需要被打印配相信息的java进程id,创业与打工的区别 - 博文预览,可以用jps查问. 4、使用示例 1)、[fenglb@ccbu-156-5 ~]$ jmap -histo 4939 sudo ./jmap -dump:format=b,file=/tmp/917dump.dat 8949 If you take a look at the source code for com.sun.tools.hat.internal.parser.Reader, you'll see that it's looking for the magic number 0x4a415641. This value is used to help identify valid heap dump files. jmap should append this value as the first four bytes of any heap dump file it creates. http://stackoverflow.com/questions/15507047/jhat-throwing-unrecognized-magic-number http://blog.csdn.net/gtuu0123/article/details/6039474

linux DBUS D-Bus三层架构 D-Bus是一个为应用程序间通信的消息总线系统, 用于进程之间的通信。它是个3层架构的IPC 系统，包括: 函数库libdbus ，用于两个应用程序互相联系和交互消息。 一个基于libdbus构造的消息总线守护进程，可同时与多个应用程序相连，并能把来自一个应用程序的消息路由到0或者多个其他程序。 基于特定应用程序框架的封装库或捆绑 (wrapper libraries or bindings ) 。例如，libdbus-glib和libdbus-qt，还有绑定在其他语言，例如Python的。大多数开发者都是使用这些封装库的API，因为它们简化了D-Bus编程细节。libdbus被有意设计成为更高层次绑定的底层后端 (low-levelbackend ) 。大部分libdbus的 API仅仅是为了用来实现绑定。 总线 在D-Bus中，“bus"是核心的概念，它是一个通道: 不同的程序可以通过这个通道做些操作，比如方法调用、发送信号和监听特定的信号。在一台机器上总线守护有多个实例(instance)。这些总线之间都是相互独立的。 一个持久的系统总线 (system bus) : 它在引导时就会启动。这个总线由操作系统和后台进程使用，安全性非常好，以使得任意的应用程序不能欺骗系统事件。它是桌面会话和操作系统的通信，这里操作系统一般而言包括内核和系统守护进程。这种通道的最常用的方面就是发送系统消息，比如: 插入一个新的存储设备；有新的网络连接；等等。 还将有很多会话总线 (session buses) : 这些总线当用户登录后启动，属于那个用户私有。它是用户的应用程序用来通信的一个会话总线。同一个桌面会话中两个桌面应用程序的通信，可使得桌面会话作为整体集成在一起以解决进程生命周期的相关问题。这在GNOME和KDE桌面中大量使用。 对于一些远程的工作站，在system bus中可能会有一些问题，例如热插拔，是否需要通知远端的terminal，这会使得kernel暴露一些设备的能力，不过，我们现在关心D-Bus，是因为手持终端设备的使用，这些将不会出现。在Internet Tablet，也包括我们的手机系统，所有的应用程序都是使用一个用户ID运行的，所以只有一个会话通道，这一点是和Linux桌面系统是有明显区别的。 D-Bus是低延迟而且低开销的，设计得小而高效，以便最小化传送的往返时间。另外，协议是二进制的，而不是文本的，这样就排除了费时的序列化过程。从开发者的角度来看，D-BUS 是易于使用的。有线协议容易理解，客户机程序库以直观的方式对其进行包装。D-Bus的主要目的是提供如下的一些更高层的功能: A、结构化的名字空间 B、独立于架构的数据格式 C、支持消息中的大部分通用数据元素 D、带有异常处理的通用远程调用接口 E、支持广播类型的通信 Bus daemon总线守护 Bus daemon是一个特殊的进程: 这个进程可以从一个进程传递消息给另外一个进程。当然了，如果有很多applications链接到这个通道上，这个 daemon进程就会把消息转发给这些链接的所有程序。在最底层，D-Bus只支持点对点的通信，一般使用本地 socket (AF_UNIX) 在应用和bus daemon之间通信。D-Bus的点对点是经过busdaemon抽象过的，由busdaemon来完成寻址和发送消息，因此每个应用不必要关心要把消息发给哪个进程。D-Bus发送消息通常包含如下步骤 (正常情况下) : 创建和发送消息 给后台bus daemon进程，这个过程中会有两个上下文的切换。 后台bus daemon进程会处理该消息，并转发给目标进程，这也会引起上下文的切换目标程序接收到消息，然后根据消息的种类，做不同的响应: 要么给个确认、要么应答、还有就是忽略它。最后一种情况对于"通知"类型的消息而言，前两种都会引起进一步的上下文切换。 综上原因，如果你准备在不同的进程之间传递大量的数据，D-Bus可能不是最有效的方法，最有效的方法是使用共享内存，但是对共享内存的管理也是相当复杂的。

kill, killall, signal kill by key ps -ef |grep java ps -ef |grep java|awk '{print $2}'|xargs -t -n 1 kill -9 ps -ef |grep java killall 命令 killall命令杀死同一进程组内的所有进程。其允许指定要终止的进程的名称，而非PID。 killall java http://www.cnblogs.com/itech/archive/2012/03/05/2380794.html kill命令用于终止指定的进程 (terminate a process) ，是Unix/Linux下进程管理的常用命令。通常，我们在需要终止某个或某些进程时，先使用ps/pidof/pstree/top等工具获取进程PID，然后使用kill命令来杀掉该进程。kill命令的另外一个用途就是向指定的进程或进程组发送信号 (The command kill sends the specified signal to the specified process or process group) ，或者确定进程号为PID的进程是否还在。比如，有许多程序都把 SIGHUP 信号作为重新读取配置文件的触发条件。 一 常用参数 格式: kill 格式: kill -TERM 发送SIGTERM信号到指定进程，如果进程没有捕获该信号，则进程终止 (If no signal is specified, the TERM signal is sent. The TERM signal will kill processes which do not catch this signal.) ...

负载测试、压力测试和性能测试的区别 性能测试 (Performance Test) 通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。测试软件在系统中的运行性能，度量系统与预定义目标的差距。 关注点: how much和how fast 负载测试 (Load Test) 负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。通过逐步增加系统负载，确定在满足性能指标的情况下，系统所能承受的最大负载量。 关注点: how much 压力测试 (Stress Test) 压力测试是一种高负载下的负载测试，也就是说被系统处于一个负载的情况，再继续对他进行加压，形成双重负载，知道系统崩溃，并关注崩溃后系统的恢复能力，以前再加压的一个过程，看看系统到底是否已经被彻底破坏掉了。 http://www.cnblogs.com/ITwangy/archive/2010/02/24/1672077.html 负载测试 (Load testing) 、压力测试 (Stress Test，应称为强度测试) 和性能测试，这三个概念常常引起混淆，难以区分，从而造成不正确的理解和错误的使用。目前对性能测试没有明确的定义，一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，批量业务处理能力等。 负载测试、压力测试和性能测试的测试目的不同，但其手段和方法在一定程度上比较相似，通常会使用相同的测试环境和测试工具，而且都会监控系统所占用资源的情况以及其它相应的性能指标，这也是造成人们容易产生概念混淆的主要原因。 我们知道，软件总是运行在一定的环境下，这种环境包括支撑软件运行的软硬件环境和影响软件运行的外部条件。为了让客户使用软件系统感到满意，必须确保系统运行良好，达到高安全、高可靠和高性能。其中，系统是否具有高性能的运行特征，不仅取决于系统本身的设计和程序算法，而且取决于系统的运行环境。系统的运行环境会依赖于一些关键因素，例如: 系统架构，如分布式服务器集群还是集中式主机系统等。 硬件配置，如服务器的配置，CPU、内存等配置越高，系统的性能会越好。 网络带宽，随着带宽的提高，客户端访问服务器的速度会有较大的改善。 支撑软件的选定，如选定不同的数据库管理系统 (Oracle、MySQL等) 和web应用服务器 (Tomcat、GlassFish、Jboss、WebLogic等) ，对应用系统的性能都有影响。 外部负载，同时有多少个用户连接、用户上载文件大小、数据库中的记录数等都会对系统的性能有影响。一般来说，系统负载越大，系统的性能会降低。 从上面可以看出，使系统的性能达到一个最好的状态，不仅通过对处在特定环境下的系统进行测试以完成相关的验证，而且往往要根据测试的结果，对系统的设计、代码和配置等进行调整，提高系统的性能。许多时候，系统性能的改善是测试、调整、再测试、再调整、……一个持续改进的过程，这就是我们经常说的性能调优 (perormance tuning) 。 在了解了这样一个背景之后，就比较容易理解为什么在性能测试中常常要谈负载测试。从测试的目的出发、从用户的需求出发，就比较容易区分性能测试、负载测试和压力测试。性能测试是为了获得系统在某种特定的条件下 (包括特定的负载条件下) 的性能指标数据，而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常工作时所能承受的最大负载，这时负载测试就成为容量测试。通过压力测试，可以知道在什么极限情况下系统会崩溃、系统是否具有自我恢复性等，但更多的是为了确定系统的稳定性。 那么，如何给负载测试、压力测试下个定义呢？根据上述讨论，我们可以给出如下的定义: 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载 (如逐渐增加模拟用户的数量) 或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源 (如CPU、内存) 等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。 压力测试是在强负载 (大数据量、大量并发用户等) 下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间 (如24小时以上) 的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。 压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载 (压力测试) 下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在 50个并发用户时错误率是1%，而在200个并发用户时错误率是20％。 负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所使用的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。 通过负载测试和压力测试都可以获得系统正常工作时的极限负载或最大容量。容量测试，自然也是采用负载测试技术来实现，而在破坏性的压力测试中，容量的确定可以看作是一种副产品——间接结果。 综合所述，负载测试、压力测试和性能测试的概念可以概括如下: 负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用。负载测试的加载方式也有很多种，可以根据测试需要来选择。 性能测试是为获取或验证系统性能指标而进行测试。多数情况下，性能测试会在不同负载情况下进行。 压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。 负载测试及压力测试特点: 性能测试方法通过模拟生产运行的业务压力量和使用场景组合测试性能是否能够满足需要。具备三个特点: (1) 这种方法的目的是验证系统是否具有系统宣称具有的能力。 ...

linux more http://www.cnblogs.com/peida/archive/2012/11/02/2750588.html 每天一个linux命令(12): more命令 more命令，功能类似 cat ，cat命令是整个文件的内容从上到下显示在屏幕上。 more会以一页一页的显示方便使用者逐页阅读，而最基本的指令就是按空白键 (space) 就往下一页显示，按 b 键就会往回 (back) 一页显示，而且还有搜寻字串的功能 。more命令从前向后读取文件，因此在启动时就加载整个文件。 1．命令格式: more [-dlfpcsu ] [-num ] [+/ pattern] [+ linenum] [file … ] 2．命令功能: more命令和cat的功能一样都是查看文件里的内容，但有所不同的是more可以按页来查看文件的内容，还支持直接跳转行等功能。 3．命令参数: +n 从笫n行开始显示 -n 定义屏幕大小为n行 +/pattern 在每个档案显示前搜寻该字串 (pattern) ，然后从该字串前两行之后开始显示 -c 从顶部清屏，然后显示 -d 提示"Press space to continue，‘q’ to quit (按空格键继续，按q键退出) “，禁用响铃功能 -l 忽略Ctrl+l (换页) 字符 -p 通过清除窗口而不是滚屏来对文件进行换页，与-c选项相似 -s 把连续的多个空行显示为一行 -u 把文件内容中的下画线去掉 4．常用操作命令: Enter 向下n行，需要定义。默认为1行 Ctrl+F 向下滚动一屏 空格键 向下滚动一屏 Ctrl+B 返回上一屏 = 输出当前行的行号 f 输出文件名和当前行的行号 ...

文本处理命令， text command sort command 排序规则受 LC_COLLATE 影响 LC_COLLATE=C 适用于 ASCII 编码, 按ASCII 排序 LC_COLLATE=C.UTF-8 适用于包含中文或者其它非 ascii 字符的情况, 对于英文或符号也是按ASCII排序 LC_COLLATE=en_US.UTF-8 这种情况 sort 在排序时会忽略大小写, 不是严格的按 ASCII 排序 LC_COLLATE=C 或 LC_COLLATE=C.UTF-8 的情况, 如果想忽略大小写, 可以加参数 -f, –ignore-case On Linux, when LC_COLLATE=“en_US.UTF-8” the LC_COLLATE definiton is non-standard. The default behavior of sort is to ignore-case and lowercase has precedence over uppercase. echo -e "c\nb\nB\na" | LC_COLLATE=C sort # 以 ',' 作为分隔符, 用第一列排序 sort -t ',' -k 1 foo.csv # 以 ',' 作为分隔符, 用第二列排序 sort -t ',' -k 2 foo.csv 命令说明: 将文本文件的内容按行排序。 sort将文件/文本的每一行作为一个单位，相互比较，比较原则是从首字符向后，依次按 ASCII 码值进行比较，最后将他们按升序输出 ...