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 码值进行比较，最后将他们按升序输出 ...

TCP 粘(nián)包 拆包 这两个词并没有一一对应的英文 tcp 文档中并不存在 粘包拆包的描述, 一般粘包抓包是指应用层协议的边界定义和数据报读取/处理的问题 tcp是面向流的协议, 在tcp上接收数据报(datagram) 就需要处理 流(stream) 到 数据报的过程. https://www.zhihu.com/question/20210025 TCP是面向字节流的协议，就是没有界限的一串数据，本没有“包”的概念，“粘包”和“拆包”一说是为了有助于形象地理解这两种现象。 粘包拆包发生场景 因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。 如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。 如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。 正常的理想情况，两个包恰好满足TCP缓冲区的大小或达到TCP等待时长，分别发送两个包； 粘包：两个包较小，间隔时间短，发生粘包，合并成一个包发送； 拆包：一个包过大，超过缓存区大小，拆分成两个或多个包发送； 拆包和粘包：Packet1过大，进行了拆包处理，而拆出去的一部分又与Packet2进行粘包处理。 粘包 TCP协议中，发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。 TCP网络通信时候会发生粘包/拆包的问题，接下来探讨其解决之道。 什么是粘包/拆包 一般所谓的 TCP 粘包是在一次接收数据不能完全地体现一个完整的消息数据。 TCP通讯为何存在粘包呢？主要原因是TCP是以流的方式来处理数据，再加上网络上 MTU 的往往小于在应用处理的消息数据，所以就会引发一次接收的数据无法满足消息的需要，导致粘包的存在。 处理粘包的唯一方法就是制定应用层的数据通讯协议，通过协议来规范现有接收的数据是否满足消息数据的需要。 情况分析 TCP 粘包通常在流传输中出现，UDP 则不会出现粘包，因为 UDP 有消息边界，发送数据段需要等待缓冲区满了才将数据发送出去，当满的时候有可能不是一条消息而是几条消息合并在换中去内，在成粘包；另外接收数据端没能及时接收缓冲区的包，造成了缓冲区多包合并接收，也是粘包。 解决办法 消息定长，报文大小固定长度，不够空格补全，发送和接收方遵循相同的约定，这样即使粘包了通过接收方编程实现获取定长报文也能区分。 包尾添加特殊分隔符，例如每条报文结束都添加回车换行符 (例如FTP协议) 或者指定特殊字符作为报文分隔符，接收方通过特殊分隔符切分报文区分。例如，FTP协议； 将消息分为消息头和消息体，消息头中包含表示信息的总长度 (或者消息体长度) 的字段 更复杂的自定义应用层协议 http://my.oschina.net/imhoodoo/blog/357290 为什么UDP没有粘包？ 粘包拆包问题在数据链路层、网络层以及传输层都有可能发生。日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。 https://cloud.tencent.com/developer/article/1804413 Netty对粘包和拆包问题的处理 Netty对解决粘包和拆包的方案做了抽象，提供了一些解码器 (Decoder）来解决粘包和拆包的问题。如： LineBasedFrameDecoder：以行为单位进行数据包的解码； DelimiterBasedFrameDecoder：以特殊的符号作为分隔来进行数据包的解码； FixedLengthFrameDecoder：以固定长度进行数据包的解码； LenghtFieldBasedFrameDecode：适用于消息头包含消息长度的协议 (最常用）； 基于Netty进行网络读写的程序，可以直接使用这些Decoder来完成数据包的解码。对于高并发、大流量的系统来说，每个数据包都不应该传输多余的数据 (所以补齐的方式不可取），LenghtFieldBasedFrameDecode更适合这样的场景。 小结 TCP协议粘包拆包问题是因为TCP协议数据传输是基于字节流的，它不包含消息、数据包等概念，需要应用层协议自己设计消息的边界，即消息帧 (Message Framing）。如果应用层协议没有使用基于长度或者基于终结符息边界等方式进行处理，则会导致多个消息的粘包和拆包。 虽然很多框架中都有现成的解决方案，比如Netty，但底层的原理我们还是要清楚的，而且还要知道有这么会事，才能更好的结合场景进行使用。

linux jmeter 分布式测试 http://www.51testing.com/html/55/383255-847895.html 我将使用3台linux测试机部署jmeter,部署方法也是非常简单,打包后放在指定的目录就ok了, 先定义了 A服务器:控制机 B C服务器为负载机 主意如果要运行jmeter一定要安装1.6以上版本的jdk并正确配置环境变量, 首先在bin目录下 启动B C 服务器 jmeter的jmeter-server服务器,如果启动报错请根据报错内容检查对应的环境配置,我这边报错的原因是hosts没有指定地址, jmeter-server正常启动会提示"创建远程服务" 接下来是准备测试脚本,可以在windows环境下先创建jmx文件,主意最好不要添加监听器,应为命令行启动的话监听器可能会占用资源而且有没有任何视图效果. 将生成好的jmx文件上传到A服务器 jmeter目录的bin目录下,然后在bin目录下创建xx.jtl文件.jtl文件用来接收测试中产生的测试结果 好了 现在进bin目录 打入启动命令,当然你也可以用绝对路径来运行启动命令 ./jmeter -n -t xx.jmx -R B服务器ip,C服务器ip -l $jmeterpath/bin/xx.jtl 参数说明 : -n 告诉jmeter使用nogui模式运行测试 -t 执行的测试脚本名 -R 后面跟随负载机的ip地址 ,注意用逗号隔开 -l 后面跟着测试结果记录的路径与文件名,主意这个文件jmeter不会自己创建,请预先创建好, 万事俱备 按下回车 ! 就开始虐待你的测试项目吧 测试完成后把xx.jtl文件下载到windows机上在不同的监听器上分析测试结果 如果想修改测试脚本,起始也不必把脚本在windows机上打开gui界面修改,直接编辑.jmx文件 你就可以看到许多熟悉的名字,这里就简单介绍几个 5 5 ...

http load http://blog.chinaunix.net/uid-488742-id-2113649.html http://www.acme.com/software/http_load/ Web测试工具 http_load 一个httpd 压力测试工具 2007-12-02 09:42:15 分类: LINUX 到http://www.acme.com/software/http_load/ 下载http_load ,安装也很简单直接make;make instlall 就行。 http_load的标准的两个例子是: http_load -parallel 5 -fetches 1000 urls.txt http_load -rate 2 -seconds 300 urls.txt 例子只是个参考,参数其实可以自由组合,参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds 300 urls.txt也是可以的。我们把参数给大家简单说明一下。-parallel 简写-p : 含义是并发的用户进程数。 -fetches 简写-f : 含义是总计的访问次数 -rate 简写-p : 含义是每秒的访问频率 -seconds简写-s : 含义是总计的访问时间 urls.txt 是一个url 列表,每个url 单独的一行。当然也可以直接跟一个url 而不是url 列表文件。 实例: http_load -rate 5 -seconds 10 urls 49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds ...

Web服务 压力测试工具,goreplay gor, http_load、webbench、apabhe ab、siege goreplay, Gor https://github.com/buger/goreplay 一、http_load 程序非常小,解压后也不到100K http_load以并行复用的方式运行,用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试工具,它可以以一个单一的进程运行,一般不会把客户机搞死。还可以测试HTTPS类的网站请求。 下载地址: http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz 安装 tar zxvf http_load-12mar2006.tar.gz cd http_load-12mar2006 make && make install ...

LinkedBlockingQueue 基于链表的阻塞队列，同 ArrayBlockingQueue 类似，其内部也维持着一个数据缓冲队列 (该队列是一个链表) ，生产者存入的数据会缓存在队列内部，生产者立即返回；只有当队列缓冲区达到最大值缓存容量时 (LinkedBlockingQueue 可以通过构造函数指定该值) ，才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端 分别采用了独立的锁 来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。 作为开发者，我们需要注意的是，如果构造一个 LinkedBlockingQueue 对象，而没有指定其容量大小，LinkedBlockingQueue 会默认一个类似无限大小的容量 (Integer.MAX_VALUE) ，这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。 此队列按 FIFO (先进先出) 排序元素。队列的头部 是在队列中时间最长的元素。队列的尾部 是在队列中时间最短的元素。 新元素插入到队列的尾部，并且队列检索操作会获得位于队列头部的元素。链接队列的吞吐量通常要高于基于数组的队列， 但是在大多数并发应用程序中，其可预知的性能要低。 可选的容量范围构造方法参数作为防止队列过度扩展的一种方法。 如果未指定容量，默认容量为 Integer.MAX_VALUE ，容量范围可以在构造方法参数中指定作为防止队列过度扩展。 此对象是线程阻塞-线程安全的 不接受 null 元素 它实现了BlockingQueue接口。 实现了 Collection 和 Iterator 接口的所有可选方法。 在JDK5/6中，LinkedBlockingQueue和ArrayBlocingQueue等对象的poll(long timeout, TimeUnit unit)存在内存泄露Leak的对象AbstractQueuedSynchronizer.Node，据称JDK5会在Update12里Fix，JDK6会在Update2里Fix 下面介绍几种常用的方法: 定义一个输出方法: static void v(Object s){System.out.println(s.toString());} LinkedBlockingQueue bq=new LinkedBlockingQueue(); for(int i=0;i<100;i++) { bq.add(“i”+i);//如果空间已满，此方法会抛出异常，所以这就是put，或者offer方法的优势所在 } String s1=bq.take();//i0 String s2=bq.take();//i1 bq.offer(“ix”,5,TimeUnit.SECONDS);//在尾部插入一个元素，如果有必要 ，等待 指定的时间，使得队列变得可用。返回boolean值 表示是否插入成功。 ...

LinkedTransferQueue LinkedTransferQueue是在JDK1.7时，J.U.C包新增的一种比较特殊的阻塞队列，它除了具备阻塞队列的常用功能外，还有一个比较特殊的transfer方法。 我们知道，在普通阻塞队列中，当队列为空时，消费者线程（调用take或poll方法的线程）一般会阻塞等待生产者线程往队列中存入元素。而LinkedTransferQueue的transfer方法则比较特殊： 当有消费者线程阻塞等待时，调用transfer方法的生产者线程不会将元素存入队列，而是直接将元素传递给消费者； 如果调用transfer方法的生产者线程发现没有正在等待的消费者线程，则会将元素入队，然后会阻塞等待，直到有一个消费者线程来获取该元素。 有一篇论文讨论了其算法与性能: 地址: http://www.cs.rice.edu/~wns1/papers/2006-PPoPP-SQ.pdf LinkedTransferQueue 实现了一个重要的接口 TransferQueue, 该接口含有下面几个重要方法: transfer(E e) 若当前存在一个正在等待获取的消费者线程，即立刻移交之；否则，会插入当前元素e到队列尾部，并且等待进入阻塞状态，到有消费者线程取走该元素。 tryTransfer(E e) 若当前存在一个正在等待获取的消费者线程 (使用take()或者poll()函数) ，使用该方法会即刻转移/传输对象元素e； 若不存在，则返回false，并且不进入队列。这是一个不阻塞的操作。 tryTransfer(E e, long timeout, TimeUnit unit) 若当前存在一个正在等待获取的消费者线程，会立即传输给它; 否则将插入元素e到队列尾部，并且等待被消费者线程获取消费掉, 若在指定的时间内元素e无法被消费者线程获取，则返回false，同时该元素被移除。 hasWaitingConsumer() 判断是否存在消费者线程 getWaitingConsumerCount() 获取所有等待获取元素的消费线程数量 其实transfer方法在SynchronousQueue的实现中就已存在了,只是没有做为API暴露出来。SynchronousQueue有一个特性:它本身不存在容量,只能进行线程之间的 元素传送。SynchronousQueue在执行offer操作时，如果没有其他线程执行poll，则直接返回false.线程之间元素传送正是通过transfer方法完成的。 有一个使用案例，我们知道ThreadPoolExecutor调节线程的原则是: 先调整到最小线程，最小线程用完后，他会将优先将任务放入缓存队列(offer(task)),等缓冲队列用完了，才会向最大线程数调节。这似乎与我们所理解的线程池模型有点不同。我们一般采用增加到最大线程后，才会放入缓冲队列中，以达到最大性能。ThreadPoolExecutor代码片段: public void execute(Runnable command) { if (command == null) throw new NullPointerException(); if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) { if (runState == RUNNING && workQueue.offer(command)) { if (runState != RUNNING || poolSize == 0) ensureQueuedTaskHandled(command); } else if (!addIfUnderMaximumPoolSize(command)) ...

SynchronousQueue http://wsmajunfeng.iteye.com/blog/1629352/ SynchronousQueue 是这样一种阻塞队列,其中每个 put 必须等待一个 take, 反之亦然。同步队列没有任何内部容量,甚至连一个队列的容量都没有。 不能在同步队列上进行 peek,因为仅在试图要取得元素时,该元素才存在； 除非另一个线程试图移除某个元素, 否则也不能 (使用任何方法) 添加元素; 也不能迭代队列, 因为其中没有元素可用于迭代。队列的头是尝试添加到队列中的首个已排队线程元素； 如果没有已排队线程,则不添加元素并且头为 null。 对于其他 Collection 方法 (例如 contains) ,SynchronousQueue 作为一个空集合。此队列不允许 null 元素。 它非常适合于传递性设计,在这种设计中,在一个线程中运行的对象要将某些信息、 事件或任务传递给在另一个线程中运行的对象,它就必须与该对象同步。 对于正在等待的生产者和使用者线程而言,此类支持可选的公平排序策略。默认情况下不保证这种排序。 但是,使用公平设置为 true 所构造的队列可保证线程以 FIFO 的顺序进行访问。 公平通常会降低吞吐量,但是可以减小可变性并避免得不到服务。 注意1: 它一种阻塞队列,其中每个 put 必须等待一个 take,反之亦然。同步队列没有任何内部容量,甚至连一个队列的容量都没有。 注意2: 它是线程安全的,是阻塞的。 注意3:不允许使用 null 元素。 注意4: 公平排序策略是指调用 put 的线程之间, 或 take 的线程之间。公平排序策略可以查考 ArrayBlockingQueue 中的公平策略。 注意5: SynchronousQueue 的以下方法: iterator() 永远返回空,因为里面没东西。 peek() 永远返回null。 put() 往queue放进去一个element以后就一直wait直到有其他thread进来把这个element取走。 offer() 往queue里放一个element后立即返回,如果碰巧这个element被另一个thread取走了,offer方法返回true,认为offer成功；否则返回false。 offer(2000, TimeUnit.SECONDS) 往queue里放一个element但是等待指定的时间后才返回,返回的逻辑和offer()方法一样。 take() 取出并且remove掉queue里的element (认为是在queue里的。。。) ,取不到东西他会一直等。 ...

gentoo mount /dev/sda3 /mnt/gentoo mount /dev/sda1 /mnt/gentoo/boot chmod 1777 /mnt/gentoo/tmp mount -t proc proc /mnt/gentoo/proc mount -rbind /sys /mnt/gentoo/sys mount -make-rslave /mnt/gentoo/sys mount -rbind /dev /mnt/gentoo/dev mount -make-rslave /mnt/gentoo/dev mount -t tmpfs -o nosuid,nodev,noexec shm /dev/shm chmod 1777 /dev/shm chroot /mnt/gentoo /bin/bash source /etc/profile export PS1="(chroot) $PS1" the minimal install cds have the ability to run isohybrid on them and then you can dd that image to a removable device. ...