AIX 5L 磁盘性能优化 第 2 部分

AIX 5L 磁盘性能优化: 第2 部分

关于本系列

本系列教程共有三篇文章（请参见参考资料），介绍了AIX? 磁盘和I/O 子系统，重点关注于在优化磁盘I/O 性能时的各种挑战。尽管磁盘优化很可能没有CPU 或者内存优化那么激动人心，但它是优化服务器性能的关键部分。事实上，其中部分原因是因为磁盘I/O 是最薄弱的子系统环节，与任何其他子系统相比，您可以执行更多的操作以提高磁盘I/O 性能。

引言

与其他子系统的优化工作不同，实际上在构建系统的体系结构设计阶段就应该开始进行磁盘I/O 优化。尽管存在一些I/O 优化参数的虚拟内存等价项（ioo 和lvmo），但是提高磁盘I/O 性能的最佳方法是正确地配置您的系统，而不是优化相关的参数。与虚拟内存优化不同，在创建了逻辑卷并开始运行之后，要更改它们的组织结构会变得更加复杂，所以您通常只有一次机会正确地完成这项任务。本文讨论了配置逻辑卷的方式，以及相对于物理磁盘应该将它们布置于何处，本文还介绍了用于监视您的逻辑卷的工具。其中，大多数工具并不适合于长期趋势研究，并且是AIX 特定的工具，它们可以提供相关信息以便了解如何配置逻辑卷，以及是否针对您的环境对它们进行了优化。

本系列文章的第 1 部分（请参见参考资料）介绍了iostat，但其中仅介绍了使用该工具来查看异步I/O 服务器。第2 部分使用iostat 来监视您的磁盘，并向您介绍了它能够完成哪些工作以帮助您快速地确定I/O 瓶颈。尽管iostat 是通用的UNIX? 实用工具之一，并且它不是专门为AIX 而开发的，但实际上，对于快速地确定系统的运行情况，它是非常有用的。更特定的AIX 逻辑卷命令可以帮助您更深入地研究逻辑卷，以帮助您真正地分析实际问题（如果存在任何问题）。在使用这些工具之前，您必须清楚地了解您需要哪些信息，这一点是很重要的。本文描述了相关的工具，并向您介绍了如何分析它们的输出，这将帮助您分析磁盘I/O 子系统。

逻辑卷和磁盘布置概述

这个部分定义了逻辑卷管理器（Logical V olume Manager，LVM），并介绍了它的一些特性。让我们深入地研究逻辑卷的概念，分析它们与提高磁盘I/O 使用率之间的关系，并通过定义和讨论intra-policy 和inter-policy 磁盘实践，从物理磁盘的角度介绍有关逻辑卷的布置。从概念上讲，逻辑卷层位于应用程序和物理层之间。在磁盘I/O 的上下文中，应用程序层是文件系统或者原始逻辑卷。物理层由实际的磁盘组成。LVM 是一种AIX 磁盘管理系统，它可以在逻辑和物理存储之间映射数据。这允许数据保存在多个物理盘片上，并使用专门的LVM 命令对其进行管理和分析。实际上，LVM 控制系统中所有的物理磁盘资源，并帮助提供存储子系统的逻辑视图。了解它位于应用程序层和物理层之间，应该可以帮助您理解它为什么很可能是所有层中最重要的一层。甚至您的物理卷本身就是逻辑层的一部分，因为物理层仅包含实际的磁盘、设备驱动程序和任何您可能已经配置的阵列。图1阐释了这个概念，并显示了逻辑I/O 组件与物理磁盘及其应用程序层非常紧密地结合在一起。

图 1. 逻辑卷图表

现在，让我们简要地、自底向上地介绍LVM 中的各个元素。每个驱动器作为一个物理卷进行命名。多个物理卷组成一个卷组。在卷组中，定义了逻辑卷。LVM 允许数据位于多个物理驱动器，尽管可能将它们配置为属于单个卷组。这些逻辑卷可以是一个或者多个逻辑分区。每个逻辑分区具有一个与其相关联的物理分区。在其中，您可以拥有物理部分的多个副本，以用于各种目的，如磁盘镜像。

让我们简要地介绍一下逻辑卷的创建与物理卷之间的关系。图2描述了物理磁盘盘片上的实际存储位置。

图 2. 物理磁盘盘片上的实际存储位置

作为一般规则，靠近中央的数据要比靠近外边缘的数据具有更快的寻道时间。这与数据的密度有关。因为越靠近中央，密度越大，实际上磁头只需移动更短的距离。内部边缘（inner edge）通常具有最短的寻道时间。作为最佳实践，应用程序使用I/O 越多，就应该使其位于越靠近物理卷中央的位置。请注意，对于这个最佳实践，有一些例外的情况。磁盘边缘的每个磁道比靠近中央的磁道能够保存更多的数据。虽然这样说，但是实际上应该顺序地访问位于边缘的逻辑卷，以获得更高的性能。对于开启了镜像写一致性检查（Mirror Write Consistency

Check，MWCC）的逻辑卷来说也一样。这是因为，MWCC 扇区位于磁盘边缘而不是中央，这与逻辑卷的intra-disk 策略有关。

让我们来讨论另一个重要的、称为逻辑卷inter-disk 策略的概念。inter-disk 策略定义了一个逻辑卷的物理分区实际驻留的磁盘的数目。一般规则是，最小的(minimum) 策略可以提供最大的可靠性和可用性，而最大的(maximum) 策略可以提高性能。简单地说，数据所分散到的驱动器越多，性能就越好。一些其他的最佳实践包括：分配密集的逻辑卷以分隔物理卷，定义所需的逻辑卷的最大大小，并将经常使用的逻辑卷布置在一起。这正是为什么在配置系统之前您必须了解具体的数据，以便您从一开始就可以创建有意义的策略的原因。

在创建逻辑卷时，您可以使用下面命令或者smit 快速路径定义自己的策略：# mklv 或# smitty mklv。

监视逻辑卷并分析结果

这个部分提供了有关如何监视您的逻辑卷并分析结果的介绍。介绍了各种各样的命令以及它们的用途，并且您还将检查输出内容。

刚刚接到了有关某个数据库服务器性能迟缓的报告。您怀疑可能出现了I/O 问题，所以您使用iostat 开始进行分析。如果您还记得，在本系列文章的第1 部分中曾介绍过这个命令（请参见参考资料），尽管只是用作查看异步I/O 服务器的目的。现在，让我们仔细地研究iostat。iostat，相当于用于虚拟内存的vmstat，很可能是概略了解I/O 子系统运行情况的最有效方式。

清单1. 使用iostat

# iostat 1

System configuration: lcpu=4 disk=4

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 392.0 5.2 5.5 88.3 1.1

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk1 0.5 19.5 1.4 53437739 21482563

hdisk0 0.7 29.7 3.0 93086751 21482563

hdisk4 1.7 278.2 6.2 238584732 832883320

hdisk3 2.1 294.3 8.0 300653060 832883320

这个示例中显示了哪些内容，而所有这些内容又是什么含义呢？

?% tm_act：报告物理磁盘处于活动状态，或者磁盘请求的总时间的时间百分比。

?Kbps：报告传输到驱动器的数据量（单位为千字节）。

?tps：报告每秒钟发送到物理磁盘的传输量。

?Kb_read：报告在测量间隔中从物理卷读取的总数据量（单位为千字节）。

?Kb_wrtn：报告在测量间隔中向物理卷写入的数据量（单位为千字节）。

您需要非常小心地监视% tm_act，因为当它的使用率超过大概百分之六十到七十时，这通常表示进程开始等待I/O。这可能是即将发生的I/O 问题的第一个征兆。将数据移动到更空闲的驱动器可以显著地帮助缓解这个负担。通常来说，您的数据位于越多的驱动器，性能

就越好。与其他的事物一样，物极必反，因为您必须确保不会有太多的驱动器连接到任何一个适配器。有一种方法可以确定一个适配器是否满负荷，将连接到该适配器的所有磁盘的Kbps 量累加起来。其总数应该小于磁盘适配器吞吐量速率，通常小于百分之七十。

使用-a 标志（请参见清单2）可以帮助您更深入地检查适配器的使用率。

清单2. 使用带-a 标志的iostat

# iostat -a

Adapter: Kbps tps Kb_read Kb_wrtn

scsi0 0.0 0.0 0 0

Paths/Disk: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk1_Path0 37.0 89.0 0.0 0 0

hdisk0_Path0 67.0 47.0 0.0 0 0

hdisk4_Path0 0.0 0.0 0.0 0 0

hdisk3_Path0 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn

ide0 0.0 0.0 0 0

Paths/Disk: % tm_act Kbps tps Kb_read Kb_wrtn

cd0 0.0 0.0 0.0 0 0

显然，其中不存在任何瓶颈。使用-d 标志允许您深入地研究一个特定的磁盘（请参见清单3）。

清单3. 使用带-d 标志的iostat

# iostat -d hdisk1 1

System configuration: lcpu=4 disk=5

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk1 0.5 19.4 1.4 53437743 21490480

hdisk1 5.0 78.0 23.6 3633 3564

hdisk1 0.0 0.0 0.0 0 0

hdisk1 0.0 0.0 0.0 0 0

hdisk1 0.0 0.0 0.0 0 0

hdisk1 0.0 0.0 0.0 0 0

让我们来研究一些特定的AIX LVM 命令。您已经了解了有关磁盘布置的内容，以及从一

开始就正确地设计系统体系结构的重要性。不幸的是，您并不总是能够使用这种方法。作为系统管理员，您有时可能会接手一些必须进行修复的系统。让我们研究一下磁盘上逻辑卷的布局，以确定您是否需要更改定义或者重新组织您的数据。

让我们首先了解一下卷组，并查找作为其中的一部分的逻辑卷。lsvg 命令可以提供卷组信息（请参见清单4）。

清单4. 使用lsvg

# lsvg -l data2vg

Data2vg:

LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT

data2lv jfs 128 256 2 open/syncd /data2

loglv00 jfslog 1 2 2 open/syncd N/A

appdatalv jfs 128 256 2 open/syncd /appdata

现在，让我们使用lslv，它可以提供关于逻辑卷的特定数据（请参见清单5）。

清单5. 使用lslv

# lslv data2lv

LOGICAL VOLUME: data2lv VOLUME GROUP: data2vg

LV IDENTIFIER: 0003a0ec00004c00000000fb076f3f41.1 PERMISSION: read/write VG STATE: active/complete LV STA TE: opened/syncd

TYPE: jfs WRITE VERIFY: off

MAX LPs: 512 PP SIZE: 64 megabyte(s) COPIES: 2 SCHED POLICY: parallel

LPs: 128 PPs: 256

STALE PPs: 0 BB POLICY: relocatable

INTER-POLICY: minimum RELOCA TABLE: yes

INTRA-POLICY: center UPPER BOUND: 32

MOUNT POINT: /data LABEL: /data

MIRROR WRITE CONSISTENCY: on/ACTIVE

EACH LP COPY ON A SEPARATE PV ?: yes

Serialize IO ?: NO

这个视图为您的逻辑卷属性提供了详细的描述。这些数据表示了什么含义呢？intra-policy 是center，它通常是面向使用大量I/O 的逻辑卷的最佳策略。正如前面的讨论中所介绍的，对于这个规则，有一些例外的情况。不幸的是，您碰到了这些情况之一。因为已经开启了镜像写一致性检查(MWC)，所以如果卷位于边缘，那么应该能够更好地为其提供服务。让我

们来研究一下inter-policy。inter-policy 是minimum，它通常是面向可用性高于性能的情况的最佳策略。而且，其中逻辑分区的数目是物理分区的两倍，这表示您正在对系统进行镜像。在这个示例中，对于您来说，原始性能是最重要的目标，所以逻辑卷的配置没有采用与如何使用卷的实际情况相关的方式。而且，如果您正在对系统进行镜像，并且使用了外部存储阵列，这种情况可能变得更糟，因为您已经在硬件层提供了镜像，而实际上，这比使用AIX 镜像的效率更高。

让我们更深入地研究清单6中的内容。

清单6. 带-l 标志的lslv

# lslv -l data2lv

data2lv:/data2

PV COPIES IN BAND DISTRIBUTION

hdisk2 128:000:000 100% 000:108:020:000:000

hdisk3 128:000:000 100% 000:108:020:000:000

lslv 的-l 标志列举了与逻辑卷和每个逻辑卷的分布（distribution）相关的所有物理卷。然后，您可以确定已经将磁盘上百分之百的物理分区都分配给了这个逻辑卷。其中的分布（distribution）部分显示了每个物理卷中的实际物理分区数目。从中，您可以详细地了解其intra-disk 策略。这些字段的顺序如下所示：

?边缘(Edge)

?中间(Middle)

?中央(Center)

?内部中间(Inner-middle)

?内部边缘(Inner-edge)

该报告显示了，大多数数据位于中间，有些数据位于中央。

让我们继续研究，并找出与一个物理卷相关联的逻辑卷。可以使用lspv 命令来完成这项任务（请参见清单7）。

清单7. 使用lspv 命令

# lspv -l hdisk2

hdisk2:

LV NAME LPs PPs DISTRIBUTION MOUNT POINT loglv01 1 1 01..00..00..00..00 N/A

data2lv 128 128 00..108..20..00..00 /data2

appdatalv 128 128 00..00..88..40..00 /appdata

现在，您可以实际地确定这个磁盘上的哪些逻辑卷实现了最大的性能。

您可以进行更深入地研究，以获取更具体的信息（请参见清单8）。

清单8. 带-p 标志的lspv

# lspv -p hdisk2

hdisk2:

PP RANGE STATE REGION LV ID TYPE MOUNT POINT

1-108 free outer edge

109-109 used outer edge loglv00 jfslog N/A

110-217 used outer middle data2lv jfs /data2

218-237 used center appdatalv jfs /appdata

238-325 used center testdatalv jfs /testdata

326-365 used inner middle stagingdatalv jfs /staging

366-433 free inner middle

434-542 free inner edge

这个视图告诉您，该物理卷中哪些是空闲的、哪些已经被使用，以及在什么地方使用了哪些分区。这是一个非常好的视图。

最好的工具之一是，使用lvmstat 查看LVM 的使用情况（请参见清单9）。

清单9. 使用lvmstat

# lvmstat -v data2vg

0516-1309 lvmstat: Statistics collection is not enabled for this logical device.

Use -e option to enable.

正如您可以从这个示例的输出中看到的，缺省情况下并没有启用它，所以在使用这个工具之前使用# lvmstat -v data2vg -e 来启动这个功能。下面的命令可以在10 个时间间隔内，每秒钟对LVM 信息进行一次快照：

# lvmstat -v data2vg 1 10

这个视图显示了从启动该数据收集工具以来，您的系统中利用率最高的逻辑卷。在优化系统时需要深入地研究逻辑卷层，这时候该视图是非常有价值的（请参见清单10）。

清单10. 带-v 标志的lvmstat

# lvmstat -v data2vg

Logical V olume iocnt Kb_read Kb_wrtn Kbps

appdatalv 306653 47493022 383822 103.2

loglv00 34 0 3340 2.8

data2lv 453 234543 234343 89.3

您需要在其中查找什么信息呢？

?% iocnt：报告读写请求的数目。

?Kb_read：报告在测量间隔中读取的总数据量（单位为千字节）。

?Kb_wrtn：报告在测量间隔中写入的数据量（单位为千字节）。

?Kbps：报告已传输的数据量（单位为千字节）。

在您将其添加到您的指令库中之前，请查看所有这些命令的man 页面。

使用lvmo 进行优化

这个部分介绍了使用特定的逻辑卷优化命令。lvmo 用于设置和显示您的pbuf 优化参数。它还可以用于阻塞I/O 统计信息。

lvmo 是在AIX Version 5.3 中首次引入的新的命令之一。请务必注意，使用lvmo 命令只允许更改那些专门用于特定卷组的LVM pbuf 可调参数。ioo 实用工具仍然是在系统范围内管理pbufs 的唯一方法。这是因为，在AIX Version 5.3 之前，pbuf 池参数是一种系统范围的资源。随着AIX Version 5.3 的出现，LVM 可以为每个卷组管理一个pbuf 池。什么是pbuf？最准确地说，pbuf 是一个固定的内存缓冲区。LVM 使用这些pbuf 来控制挂起的磁盘I/O 操作。

让我们显示一下data2vg 卷组的lvmo 可调参数（请参见清单11）。

清单11. 显示lvmo 可调参数

# lvmo -v data2vg -a

vgname = data2vg

pv_pbuf_count = 1024

total_vg_pbubs = 1024

mag_vg_pbuf_count = 8192

perv_blocked_io_count = 7455

global_pbuf_count = 1024

global_blocked_io_count = 7455

其中哪些是可调参数？

?pv_pbuf_count：报告在将一个物理卷添加到该卷组时所添加的pbuf 数目。

?Max_vg_pbuf_count：报告可以为一个卷组分配的最大pbuf 量。

?Global_pbuf_count：报告在将一个物理卷添加到任何卷组时所添加的pbuf 数目。让我们为这个卷组增加pbuf 计数：

# lvmo -v redvg -o pv_pbuf_count=2048

老实说，我通常并不使用lvmo，而是使用ioo。我更习惯优化全局参数。请务必注意，如果您将这个pbuf 值设置得太大，将会导致性能降低。

结束语

本文重点关注于逻辑卷以及它们与磁盘I/O 子系统的关系。本文概略地定义了逻辑卷，并说明了它与应用程序和物理层的关系。本文还定义和介绍了inter-disk 和intra-disk 策略的一些最佳实践，因为它们与创建和维护逻辑卷有关。您了解了为您的逻辑卷监视I/O 使用情况的各种方法，并且分析了从用于帮助确定问题的各种命令所捕获的数据。最后，您通过确定和增加特定卷组所使用的pbufs 量，对您的逻辑卷进行了优化。本系列文章的第 3 部分将在您继续研究文件系统的同时，重点关注于应用程序层，并使用各种命令以监视和优化您的文件系统和磁盘I/O 子系统。

性能优化的方法和技巧

性能优化方法和技巧：概述 性能优化有三个层次： ?系统层次 ?算法层次 ?代码层次 系统层次关注系统的控制流程和数据流程，优化主要考虑如何减少消息传递的个数；如何使系统的负载更加均衡；如何充分利用硬件的性能和设施；如何减少系统额外开销（比如上下文切换等）。 算法层次关注算法的选择（用更高效的算法替换现有算法，而不改变其接口）；现有算法的优化（时间和空间的优化）；并发和锁的优化（增加任务的并行性，减小锁的开销）；数据结构的设计（比如lock-free的数据结构和算法）。 代码层次关注代码优化，主要是cache相关的优化（I-cache, D-cache相关的优化）；代码执行顺序的调整；编译优化选项；语言相关的优化技巧等等。 性能优化需要相关的工具支持，这些工具包括编译器的支持；CPU的支持；以及集成到代码里面的测量工具等等。这些工具主要目的是测量代码的执行时间以及相关的cache miss, cache hit等数据，这些工具可以帮助开发者定位和分析问题。 性能优化和性能设计不同。性能设计贯穿于设计，编码，测试的整个环节，是产品生命周期的第一个阶段；而性能优化，通常是在现有系统和代码基础上所做的改进，属于产品生命周期的后续几个阶段（假设产品有多个生命周期）。性能优化不是重新设计，性能优化是以现有的产品和代码为基础的，而不是推倒重来。性能优化的方法和技巧可以指导性能设计，但两者的方法和技巧不能等同。两者关注的对象不同。性能设计是从正向考虑问题：如何设计出高效，高性能的系统；而性能优化是从反向考虑问题：在出现性能问题时，如何定位和优化性能。性能设计考验的是开发者正向建设的能力，而性能优化考验的是开发者反向修复的能力。两者可以互补。

Web网站大数据量的性能解决方案

W eb网站大数据量的性能解决方案 随着中国大型IT企业信息化速度的加快，大部分应用的数据量和访问量都急剧增加，大型企业网站正面临性能和高数据访问量的压力，而且对存储、安全以及信息检索等等方面都提出了更高的要求…… 本文中，我想通过几个国外大型IT企业及网站的成功案例，从Web技术人员角度探讨如何积极地应对国内大型网站即将面临的扩展（主要是技术方面，而较少涉及管理及营销等方面）矛盾。 一、国外大型IT网站的成功之道 (一)MySpace 今天，MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素，但是本节中我们却抛弃这一点，而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。 第一代架构—添置更多的Web服务器 MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。 第二代架构—增加数据库服务器 与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下让多个数据库分担压力。MySpace 运行在三个SQL Server数据库服务器上—一个为主，所有的新数据都向它提交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（存储区域网络）—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策略也变得难以维持下去。 第三代架构—转到分布式计算架构 几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用

Linux操作系统性能调优的方法

按照传统，Linux不同的发行版本和不同的内核对各项参数及设置均做了改动，从而使得系统能够获得更好的性能。下边将分四部分介绍在Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server系统下，如何用以下几种技巧进行性能的优化： QUOTE: 1、Disabling daemons （关闭 daemons) 2、Shutting down the GUI (关闭GUI) 3、Changing kernel parameters (改变内核参数） 4、Kernel parameters （内核参数） 5、Tuning the processor subsystem（处理器子系统调优） 6、Tuning the memory subsystem （内存子系统调优） 7、Tuning the file system（文件系统子系统调优） 8、Tuning the network subsystem（网络子系统调优） 1 关闭daemons 有些运行在服务器中的daemons (后台服务)，并不是完全必要的。关闭这些daemons可释放更多的内存、减少启动时间并减少CPU处理的进程数。减少daemons数量的同时也增强了服务器的安全性。缺省情况下，多数服务器都可以安全地停掉几个daemons。 Table 10-1列出了Red Hat Enterprise Linux AS下的可调整进程. Table 10-2列出了SUSE LINUX Enterprise Server下的可调整进程.

注意：关闭xfs daemon将导致不能启动X，因此只有在不需要启动GUI图形的时候才可以关闭xfs daemon。使用startx命令前，开启xfs daemon，恢复正常启动X。 可以根据需要停止某个进程，如要停止sendmail 进程，输入如下命令： Red Hat: /sbin/service sendmail stop SUSE LINUX: /etc/init.d/sendmail stop

浅谈AIX环境下的Java性能调优-Fangshuxin

浅谈AIX环境下的Java性能调优 1、什么是Java Java 是一种面向对象的编程语言。它以 C++ 为模型，被设计成小的、简单的、在源和二进制级别跨平台的可移植的语言，Java 程序（applets 和应用程序）可以运行于任何已经安装了 Java 虚拟机（JVM）的机器上。Java 相对其它计算机语言有显著的优势，适合于任何编程任务,Java 有以下优势： Java 是独立于平台的:Java 最显著的一个优势就是它轻易从一台计算机系统移动到另一台的能力。对于任何Web软件至关重要的就是在许多 不同系统上运行同一个程序的能力， Java 成功之处在于在源和二进制 级别能够独立于平台。 Java 是面向对象的:Java 的另外一个优点在于利用面向对象的方法。这允许你创建模块化程序和可重用代码。 Java 容易学习:Java 被设计成容易使用的语言，因此它更易于写、编译、调试以及学习。 Java 是电子商务的解决方案: 由于 Java 的健壮性、使用方便、跨平台的能力和安全性特点，它已成为了提供世界范围内因特网解决方案的选 择语言。 2、AIX环境下的Java版本 目前，AIX操作系统可以支持多个Java版本，可以在一个操作系统下同时安装多个Java版本，应用需要哪个版本时，可设置PATH路径到此版本所在的目录。以下是AIX可支持的Java版本信息： Java 1.1.8 Java 1.2.2 Java 1.3.0 Java 1.3.1 32bit Java 1.3.1 64bit Java 1.4 32bit Java 1.4 64bit 从性能来看，尽量使用高版本的AIX和高版本的Java，并且安装最新的操作系统和Java补丁包。当需要超过2GB的Java 堆时，需要使用64bit的Java。在AIX环境下，Java是免费使用的，可以从下列网址下载Java软件： https://www.wendangku.net/doc/8d3271614.html,/dl/dka/dka-p

大数据报表优化问题

大数据报表优化问题 方法一、优化设计器的配置，方法如下：在reportconfig.xml里面，您可以修改一下信息优化，单元格数，并发数等。 D:\润前报表\webapps\demo\WEB-INF 这个路径下的reportconfig.xml。 1）maxCellNum 当前报表系统能运算的最大单元格数，能够动态控制并发数。该数值的大小取决于硬件的配置，一般来说内存越大，这些数值可以设得越大，但最多建议不要超过2000000。 设置为-1 ，表示为无限大。 2）maxConcurrentForReport表示报表WEB应用中服务器可以同时计算的报表的个数，以便有效控制服务器的内存使用量。该数值的大小取决于硬件的配置，一般来说内存越大，这些数值可以设得越大，但最多建议不要超过100。 3）maxWaitForReport表示报表WEB应用中服务器可以等待计算的报表的个数，以便有效控制服务器的内存使用量。该数值的大小取决于硬件的配置，一般来说内存越大，这个数值可以设得越大，但最多建议不要超过100。 maxWaitTimeForReport表示内存溢出后，最长等待多久才允许新任务访问，以秒为单位，一般建议为30。 4）另外在D:\润前报表\bin 下startup.bat 里面可以修改设计器使用内存，可以根据计算机性能配置。Xms512m -Xmx1024m 这里一般改成1024 1024 startdemo.bat是设置ie浏览时的内存。 方法二、利用tag标签对报表进行分页运算和输出，您可以参考下《应用开发教程》--》2.6.3 autobig分页。 在一页一页计算报表的基础上，然后一页一页输出到文件。即在输出到文件时判断一下该文件是否有内容，如果有，则追加到后面。 实现方法：1）调API接口按常规的办法计算报表，获得结果报表iReport 2）调用ReportUtils.exportToText( OutputStream os, IReport report )方法即可实现流式输出到txt 文件 方法二需要将jar包更新，否则会提示autobig标签未定义错误。

系统性能优化方案

系统性能优化方案 (第一章) 系统在用户使用一段时间后（1年以上），均存在系统性能（操作、查询、分析）逐渐下降趋势，有些用户的系统性能下降的速度非常快。同时随着目前我们对数据库分库技术的不断探讨，在实际用户的生产环境，现有系统在性能上的不断下降已经非常严重的影响了实际的用户使用，对我公司在行业用户内也带来了不利的影响。 通过对现有系统的跟踪分析与调整，我们对现有系统的性能主要总结了以下几个瓶颈： 1、数据库连接方式问题 古典C/S连接方式对数据库连接资源的争夺对DBServer带来了极大的压力。现代B/S连接方式虽然不同程度上缓解了连接资源的压力，但是由于没有进行数据库连接池的管理，在某种程度上，随着应用服务器的不断扩大和用户数量增加，连接的数量也会不断上升而无截止。 此问题在所有系统中存在。 2、系统应用方式（架构）问题(应用程序设计的优化) 在业务系统中，随着业务流程的不断增加，业务控制不断深入，分析统计、决策支持的需求不断提高，我们现有的业务流程处理没有针对现有的应用特点进行合理的应用结构设计，例如在‘订单、提油单’、‘单据、日报、帐务的处理’关系上，单纯的数据关系已经难以承载多元的业务应用需求。 3、数据库设计问题（指定类型SQL语句的优化）

目前在系统开发过程中，数据库设计由开发人员承担，由于缺乏专业的数据库设计角色、单个功能在整个系统中的定位模糊等原因，未对系统的数据库进行整体的分析与性能设计，仅仅实现了简单的数据存储与展示，随着用户数据量的不断增加，系统性能逐渐下降。 4、数据库管理与研究问题(数据存储、物理存储和逻辑存储的优化) 随着系统的不断增大，数据库管理员（DBA）的角色未建立，整个系统的数据库开发存在非常大的随意性，而且在数据库自身技术的研究、硬件配置的研究等方面未开展，导致系统硬件、系统软件两方面在数据库管理维护、研究上无充分认可、成熟的技术支持。 5、网络通信因素的问题 随着VPN应用技术的不断推广，在远程数据库应用技术上，我们在实际设计、开发上未充分的考虑网络因素，在数据传输量上的不断加大，传统的开发技术和设计方法已经无法承载新的业务应用需求。 针对以上问题，我们进行了以下几个方面的尝试： 1、修改应用技术模式 2、建立历史数据库 3、利用数据库索引技术 4、利用数据库分区技术 通过尝试效果明显，仅供参考！

SAP系统在AIX下的参数优化

SAP系统在AIX下的参数优化 SAP应用对系统的资源要求较高，如系统的CPU，内存和硬盘，本文介绍如何在AIX操作系统下合理的配置内存参数，使得SAP应用达到最好的性能。 在AIX中缺省的系统内存参数设置，并不适合SAP应用的需求，因此需要进行一些调整。AIX操作系统中，一般将内存的使用分成两个部分，一个部分用于应用程序运行使用，称为计算内存（Computational），另一部分用于文件缓存，称为文件缓存（Non-Comp），AIX操作系统通过 minperm%，maxperm%, maxclient%, strict_maxclient, lru_file_repage，minfree, maxfree, 等参数控制系统的内存使用. 在SAP应用环境下建议将以上参数设置为： vmo -p -o strict_maxclient=0 vmo -p -o lru_file_repage=0 vmo -p -o minperm%=3 vmo -p -o maxclient%=8 vmo -p -o maxperm%=8 vmo -p -o minfree=[CPU数量]*120 vmo -p -o maxfree=[CPU数量]*128 如果CPU数量是12，则minfree=1440, maxfree=1536 使用AIX 并行I/O (Concurrent I/O) 来提高数据库的性能 内容提要: AIX 5L v5.2.0.10( 或称作AIX 5L v5.2 ML01) 在增强的日志文件系统（JFS2) 上引入了并行I/O (Concurrent I/O) 的新的功能。在许多应用环境下，这一新的功能可提高文件系统访问的性能，尤其对于关系型数据库的应用。在JFS2 的文件系统上采用并行I/O (Concurrent I/O) 技术后，可以得到与采用裸设备相似的性能。本文将对并行I/O (Concurrent I/O) 做一个简要的介绍并给出在Oracle 9i 数据库上进行性能比较的结果。 说明: 1. 简介 文件系统长久以来一直是UNIX 存储管理的核心，UNIX 的用户通过系统命 令和系统接口对存储在文件系统上的数据进行操作和管理。文件系统的使用提供了对数据进行存储的有效手段。 如同使用其它方式一样，文件系统的使用是对于性能与易用性平衡的结果。在应用和磁盘之间传输数据最快的方式是直接进行访问，如使用裸设备。而使用文件系统来存数数据会产生很多额外开销，如串行访问，缓存和数据拷贝。这些都将对性能产生影响。使用裸设备进行数据的存储虽然能减少这些额外开销，但对用户的技术水平要求较高，而且不同应用程序对裸设备的使用方式也不同，需

大数据性能优化之Hive优化

Hive性能优化 1.概述 本人在工作中总结Hive的常用优化手段和在工作中使用Hive出现的问题。下面开始本篇文章的优化介绍。 2.介绍 首先，我们来看看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;这是通用的算法优化，但算法优化有时不能适应特定业务背景，开发人员了解业务，了解数据，可以通过业务逻辑精确有效的解决数据倾斜问题。 ?数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题。 ?对小文件进行合并，是行至有效的提高调度效率的方法，假如所有的作业设置合理的文件数，对云梯的整体调度效率也会产生积极的正向影响。 ?优化时把握整体，单个作业最优不如整体最优。 而接下来，我们心中应该会有一些疑问，影响性能的根源是什么？ 3.性能低下的根源

安卓性能优化方案

随着技术的发展，智能手机硬件配置越来越高，可是它和现在的PC相比，其运算能力，续航能力，存储空间等都还是受到很大的限制，同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由，足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时，我们应该时刻牢记，写出高效代码的两条基本的原则：（1）不要做不必要的事；（2）不要分配不必要的内存。 我从去年开始接触Android开发，以下结合自己的一点项目经验，同时参考了Google的优化文档和网上的诸多技术大牛给出的意见，整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如：Nexus o ne 对每个软件的内存限制是24M)，同时Java语言本身比较消耗内存，d alvik虚拟机也要占用一定的内存空间，所以合理使用内存，彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现，新版

（Android2.2+）将换成JIT编译器实现。性能测试显示，在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.wendangku.net/doc/8d3271614.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐，世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则： 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个Stri ngBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。 一个更极端的例子是，把多维数组分成多个一维数组： int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[]

优化AIX 7内存性能 第二部分 监视内存情况并分析结果【ps+sar+svmon +vmstat】

优化AIX 7内存性能第二部分监视内存的使用情况并分析其结果【ps+sar+svmon +vmstat】 简介 内存子系统调优中最重要的部分并不涉及实际的调优工作。在对系统进行调优之前，必须弄清楚主机系统的实际运行情况。要做到这一点，AIX? 7 管理员必须知道应该使用何种工具以及如何对将要捕捉的数据进行分析。 再次重申前面的调优文章（见 参考资料）中所介绍的原则：必须先监视主机，才能对系统进行正确地调优，无论它是作为逻辑分区 (LPAR) 运行还是在自己的物理服务器上运行。可以使用许多命令来捕捉和分析数据，所以需要了解这些命令，以及其中的哪些命令最适合想要进行的工作。在捕捉了数据之后，需要对结果进行分析。有些问题初看起来像是 CPU 的问题，但是经过分析之后，可以诊断出是内存或 I/O 问题，前提是使用合适的工具捕捉数据并知道如何进行分析工作。只有在正确地完成了这些工作之后，才可以考虑对系统进行实际的更改。如果医生不了解病史和目前的症状，就无法诊治疾病；同样，也需要在优化子系统之前对其进行诊断。如果在出现 CPU 或者 I/O 瓶颈的情况下对内存子系统进行优化，这将是毫无帮助的，甚至可能会影响主机的正常运行。 本文将帮助您理解正确地进行诊断的重要性。您将看到，性能调优远不只是实际的调优工作本身。在您将要学习的工具中，有一些是通用的监视工具，所有版本的 UNIX? 都提供这些工具，另外一些工具是专门为 AIX 7 编写的。必须获得基准数据；这是已知环境的关键数据，调优决策都以此作为基础。 不要等到用户开始向服务台抱怨糟糕的性能时，才开始监视系统。应该在将服务器投入生产环境中后尽快捕捉数据。如果做到了这一点，那么就可以积极主动地进行调优，其目标是在用户指出问题之前找到它。如果不了解系统正常运行时的数据，那么就无法确定所查看的数据是否表示存在性能问题。这是所有适当的性能调优方法的一部分；必须有效地捕捉数据，并正确地分析结果和趋势。我们来仔细地讨论内存监视。 UNIX 通用的内存监视 在本节中，我们概述在所有 UNIX 发行版中都可以使用的一些通用 UNIX 工具，包括 ps、sar 和 vmstat。其中的大多数工具都允许快速地对性能问题进行故障排除，但是它们并不适用于进行历史趋势研究和分析。 大多数管理员不经常使用 ps 命令对可能存在的内存瓶颈进行故障排除。但是，ps 可以提供关于系统运行情况的大量信息，因此有助于了解使用内存的情况。ps 最常用的功能是查看系统中正在运行的进程（见 清单 1）。 清单 1. 使用 ps 查看系统中正在运行的进程 # ps -ef | more UID PID PPID C STIME TTY TIME CMD root 1 0 0 Jul 30 - 0:01 /etc/init

系统性能调优方案

第1章系统性能调优方案 1.1系统的性能扩展模型介绍 在进行性能指标设计工作前，必须从理论上对性能指标的可实现性进行分析。理论上，系统的扩展模型可以分成两类，系统可扩展模型和不可扩展模型，如下图所示： 两种性能扩展模型 以上左图代表了系统随着并发用户量的增加系统响应时间呈现线性增长的 趋势，是一种可扩展的情况；但对于系统右边的方式则是不可扩展的，它将随着用户数量的增大而响应时间大大急剧增加，这种模型是完全不可控制的。 通过系统压力实验，我们发现，即使是遵循可扩展模型设计的系统的响应性能和并发用户量并不能成永远的线性关系，在系统压力超过一定的值之后，如100并发，系统响应时间增加非常快，我们把这个点称为拐点。在拐点以下，系统性能呈现良好的线性特性，在拐点以上，则呈现出非线性的特征，同时CPU 和内存出现相当大的增长，甚至100%占用。这种现象的出现，说明系统的性能 不仅仅取决于软件系统，而也同时取决于承载系统的硬件基础环境，如计算能力和内存大小。 为此，系统性能设计的目的就是为系统设置合理的拐点并发值，而不可能无限制的追求无限大的并发下系统响应仍旧呈现线形特征。

1.2对响应时间的技术保障手段 金税三期工程第二阶段河南地税建设项目财务管理子系统对系统的性能要求是比较高的，为了满足这个要求，在系统实现上必须要采用一系列的技术措施才能达到，具体来说将采用下面方式进行： 1、预处理技术的应用 预处理技术是一种在预定计划上由系统激发主动执行的计算模式，它对于一些处理内容固定，处理方式固定的功能非常有效，通过提前处理，实现数据生成时间和数据访问时间的隔离，在数据访问的时候不再需要为拿到结果而执行任何的计算，只需要简单的查询结果即可，这样可以大大增强系统的访问性能，有效的利用系统闲置时间。 2、变动态内容查找为静态数据访问 一些情况下，经过各种调优手段仍不能满足要求，就需要将一些动态的内容进行静态化处理，如可以将复杂的动态报表转化成HTML网页并发布在WEB服务器上，这种方式可以大大减轻应用服务器的访问压力，进一步减少用户等待的时间。例如，对一段历史时期的数据的汇总报表结果的查询，复杂报表结果等查询。 3、异步功能调用模式 对一些耗时较长的处理内容，如果必须由人工进行启动，那么，可以采用这种方式，用户调用程序的时候，实际上只是发送了一个消息给后台服务器，并在服务器端注册信息处理完后需要回馈的客户端，然后系统提示用户系统正在或很快处理这个任务，这样，立刻就能够解放用户，用户可以利用在后台处理的时间去处理其他的任务，在系统处理完后，采用推技术(push)，将处理结果提示给用户，从而完成功能的调用全过程。 4、浏览器显示时采用分页、分时显示技术 用户从数据库查询得到的数据如果行数比较多，比如大于100行。在IE端显示就需要花费很长时间，有时让查询人员无法忍受。分页技术，就是利用先显示结果的一部分，一般结果的前50条记录，后面的记录通过翻页的功能去显示其余部分。比如在查询正常计划详细列表页面时，通过查询得到1000条记录，

aix磁盘性能调优-3

本系列共有三篇文章（见 参考资料），介绍 AIX? 磁盘和 I/O 子系统，重点关注在优化磁盘 I/O 性能时遇到的各种挑战。尽管磁盘调优很可能没有 CPU 或者内存优化那么激动人心，但它是优化服务器性能的关键方面。事实上，部分原因是因为磁盘 I/O 是最薄弱的子系统环节，与任何其他子系统相比，可以通过更多的措施提高磁盘 I/O 性能。 简介 本系列的 第 1 部分 和 第 2 部分 讨论了设计系统架构的重要性，它对整体系统性能的影响，以及一个新的 I/O 优化工具 lvmo，可以使用该工具对逻辑卷进行调优。在这个部分中，将研究如何使用 ioo 命令优化系统，该命令可以对大多数 I/O 调优参数进行配置，显示所有 I/O 调优参数的当前值或下一次启动值。还将学习如何以及何时使用filemon 和 fileplace 工具。通过使用增强型日志文件系统（AIX 中的默认文件系统），提高整体文件系统性能、优化文件系统以及让JFS2 产生最好的性能，这些都是调优技术的重要部分。甚至还将研究一些可能影响性能的文件系统属性，比如顺序访问和随机访问。 文件系统概述 本节讨论 JFS2、文件系统性能以及对 JFS 所做的特定性能改进。正如您所知道的，在 AIX 中有两种类型的内核。它们是 32 位内核和 64位内核。尽管它们共享一些共同的库、大多数的命令及实用工具，但了解它们的区别以及内核与整体性能调优之间的关系是非常重要的。JFS2针对 64 位内核进行了优化，而 JFS 则针对 32 位内核进行了优化。尽管日志文件系统可以提供更高的安全性，但在以前往往会带来性能方面的开销。在更重视性能（以牺牲可用性为代价）的情况下，可能会禁用元数据日志记录功能以提高 JFS 的性能。对于 JFS2，也可以通过禁用日志记录（在 AIX 6.1 和更高版本中）帮助提高性能。可以在挂载文件系统时禁用日志记录功能，这意味着不需要担心修改或重新配置文件系统。只需修改挂载选项。例如，使用以下命令禁用文件系统上的日志记录功能：mount -i log=NULL /database。 尽管 JFS2 为提高元数据操作（即通常由日志记录框架处理的那些操作）的性能做了优化，但是对于文件修改和创建/删除操作比例很高的文件系统，关闭日志记录功能仍然会显著提高性能。例如，对于开发文件系统，可能会看到性能提升。对于使用比较静态的文件的数据库，性能改进可能不太显著。 但是，对于使用压缩功能，应该谨慎。尽管压缩可以节省磁盘空间（因为对磁盘物理地读写的数据更少，还会减少磁盘读写操作），但是会加重系统的 CPU 负载，实际上会降低性能。

MySQL大数据量的查询提高性能优化

最近一段时间参与的项目要操作百万级数据量的数据，普通SQL查询效率呈直线下降，而且如果where中的查询条件较多时，其查询速度简直无法容忍。之前数据量小的时候，查询语句的好坏不会对执行时间有什么明显的影响，所以忽略了许多细节性的问题。 经测试对一个包含400多万条记录的表执行一条件查询，其查询时间竟然高达40几秒，相信这么高的查询延时，任何用户都会抓狂。因此如何提高sql语句查询效率，显得十分重要。以下是结合网上流传比较广泛的几个查询语句优化方法： 基本原则：数据量大的时候，应尽量避免全表扫描，应考虑在where 及order by 涉及的列上建立索引，建索引可以大大加快数据的检索速度。但是，有些情况索引是不会起效的，因此，需要下面的做法进行优化： 1、应尽量避免在where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 2、应尽量避免在where 子句中对字段进行null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 3、尽量避免在where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20 可以这样查询： select id from t where num=10 union all select id from t where num=20 4、下面的查询也将导致全表扫描：

22提供性能优化方案---Google-Code

Linux系统性能测试与分析 1、前言 通过对系统中和性能相关的各个环节的介绍，使大家知道出现性能问题时可以从那些方面入手去查，而分析典型应用对系统资源使用的特点，让大家对应用和系统资源的依赖有了更直观的认识。大多数的硬件性能问题主要和CPU、磁盘、内存相关，还没有遇到因为开发语言的运行效率对整个应用的性能造成影响，而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是，大多数情况下，虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。当你阅读完了这遍文档以后就会有一个对系统分析的思路。 2、性能分析的目的 2.1找出系统性能瓶颈 1.硬件瓶颈 2.软件瓶颈 2.2提供性能优化方案 1.升级硬件 2.改进系统结构 达到合理的硬件和软件配置，使系统资源使用达到平衡。但遗憾的是解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待 CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销） 3、性能相关的各个环节 3.1 硬件资源 3.1.1、CPU ⒈ 是否使用SMP。 ⒉ 单颗CPU的性能对依赖CPU的某些应用的影响很严重，比如数据库的查询处理。 3.1.2、内存

Unix,Linux 磁盘 IO 性能监控命令

Unix/Linux 磁盘I/O 性能监控命令 磁盘I/O 性能监控指标和调优方法 在介绍磁盘I/O 监控命令前，我们需要了解磁盘I/O 性能监控的指标，以及每个指标的所揭示的磁盘某方面的性能。磁盘I/O 性能监控的指标主要包括： 指标1：每秒I/O 数（IOPS 或tps） 对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘I/O, 磁盘的IOPS 就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时，该指标有重要参考意义。 指标2：吞吐量（Throughput） 指硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。其单位一般为Kbps, MB/s 等。当传输大块不连续数据的数据，该指标有重要参考作用。 指标3：平均I/O 数据尺寸 平均I/O 数据尺寸为吞吐量除以I/O 数目，该指标对揭示磁盘使用模式有重要意义。一般来说，如果平均I/O 数据尺寸小于32K，可认为磁盘使用模式以随机存取为主；如果平均每次I/O 数据尺寸大于 32K，可认为磁盘使用模式以顺序存取为主。 指标4：磁盘活动时间百分比（Utilization） 磁盘处于活动时间的百分比，即磁盘利用率，磁盘在数据传输和处理命令（如寻道）处于活动状态。磁盘利用率与资源争用程度成正比，与性能成反比。也就是说磁盘利用率越高，资源争用就越严重，性能也就越差，响应时间就越长。一般来说，如果磁盘利用率超过70%，应用进程将花费较长的时间等待I/O 完成，因为绝大多数进程在等待过程中将被阻塞或休眠。 指标5：服务时间（Service Time） 指磁盘读或写操作执行的时间，包括寻道，旋转时延，和数据传输等时间。其大小一般和磁盘性能有关，CPU/ 内存的负荷也会对其有影响，请求过多也会间接导致服务时间的增加。如果该值持续超过20ms，一般可考虑会对上层应用产生影响。 指标6：I/O 等待队列长度（Queue Length） 指待处理的I/O 请求的数目，如果I/O 请求压力持续超出磁盘处理能力，该值将增加。如果单块磁盘的队列长度持续超过2，一般认为该磁盘存在I/O 性能问题。需要注意的是，如果该磁盘为磁盘阵列虚拟的逻辑驱动器，需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目，以获得平均单块硬盘的I/O 等待队列长度。 指标7：等待时间（Wait Time） 指磁盘读或写操作等待执行的时间，即在队列中排队的时间。如果I/O 请求持续超出磁盘处理能力，意味着来不及处理的I/O 请求不得不在队列中等待较长时间。 通过监控以上指标，并将这些指标数值与历史数据，经验数据以及磁盘标称值对比，必要时结合CPU、内存、交换分区的使用状况，不难发现磁盘I/O 潜在或已经出现的问题。但如果避免和解决这些问题呢？这就需要利用到磁盘I/O 性能优化方面的知识和技术。限于本文主题和篇幅，仅列出一些常用的优化方法供读者参考： 1.调整数据布局，尽量将I/O 请求较合理的分配到所有物理磁盘中。 2.对于RAID 磁盘阵列，尽量使应用程序I/O 等于条带尺寸或者为条带尺寸的倍数。并选取合适 的RAID 方式，如RAID10，RAID5。 3.增大磁盘驱动程序的队列深度，但不要超过磁盘的处理能力，否则，部分I/O 请求会因为丢失 而重新发出，这将降低性能。 4.应用缓存技术减少应用存取磁盘的次数，缓存技术可应用在文件系统级别或者应用程序级别。

Linux 性能调优的几种方法

Linux 性能调优的几种方法 按照传统，Linux不同的发行版本和不同的内核对各项参数及设置均做了改动，从而使得系统能够获得更好的性能。下边将分四部分介绍在Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server系统下，如何用以下几种技巧进行性能的优化： 1、Disabling daemons （关闭daemons) 2、Shutting down the GUI (关闭GUI) 3、Changing kernel parameters (改变内核参数） 4、Kernel parameters （内核参数） 5、Tuning the processor subsystem（处理器子系统调优） 6、Tuning the memory subsystem （内存子系统调优） 7、Tuning the file system（文件系统子系统调优） 8、Tuning the network subsystem（网络子系统调优） 1 关闭daemons 有些运行在服务器中的daemons (后台服务)，并不是完全必要的。关闭这些daemons可释放更多的内存、减少启动时间并减少CPU处理的进程数。减少daemons数量的同时也增强了服务器的安全性。缺省情况下，多数服务器都可以安全地停掉几个daemons。 Table 10-1列出了Red Hat Enterprise Linux AS下的可调整进程. Table 10-2列出了SUSE LINUX Enterprise Server下的可调整进程

注意：关闭xfs daemon将导致不能启动X，因此只有在不需要启动GUI图形的时候才可以关闭xfs daemon。使用startx命令前，开启xfs daemon，恢复正常启动X。

Java程序性能优化方案

Java程序性能优化方案 StringTokenizer比String.split()方法效率高 更优化的方式 Java代码 while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } 比String.startsWith和endsWith性能更优的方式：Java代码 int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c');

int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c'); StringBuffer(int capacity)指定初始容量可以减少扩容的操作

Weblogic性能调优-通过Thread Dump调优JAVA应用程序

理解和探查内存不足/内存泄漏OutOfMemoryError/Memory Leak Analyze & Utilities Demonstrate II(AIX)

理解和探查内存不足/内存泄漏 听完这次Webinar，您将能够： q了解Java基本内存管理基本概念 q了解发生内存不足/内存泄漏错误的原 因和症状 q了解如何解决内存不足/内存泄漏错误

MENU ?Java内存管理的基本概念 ?内存不足和内存泄漏错误的原因和症状 ?使用分析工具解决内存不足和内存泄漏错误?预防内存不足和内存泄漏?OutOfMemory分析实例

…Java内存 –Java堆内存（heap） …Java堆内存(heap)： –是JVM用于分配Java对象的内存，包含活动对象和不可用对象 –堆大小通常是在服务器启动时使用java命令中的 –Xms(最小)–Xmx（最大）标志来定义。

…本地内存(native memory)： –是JVM用于其内部操作的本地内存（非Java内存）–JNI代码和第三方本地模块（例如，本地JDBC驱动 程序）也使用本地内存 –最大本地内存大小取决于以下因素： ?操作系统进程内存大小限制 ?已经指定用于Java堆的内存 …进程内存大小： –32位操作系统，理论最大值2的32次方＝4G –进程内存＝ Java内存＋本地内存 ＋加载的可执行文件和库＋操作系统保留内存

…垃圾回收 (Garbage Collection, GC)：–JVM自动检测和释放不再使用的内存。 –Java运行时JVM会执行GC，这样程序员不再需要显 式 释放对象。 –通常在空闲内存降低到某一水平或内存分配达到某一 数量后自动触发。 …以下OutOfMemory简称OOM …以下Memory Leak简称ML …Heap简称“堆”

大数据分析应用最多的9个关键领域

大数据分析应用最多的9个关键领域 随着企业开始利用大数据，我们每天都会看到大数据新的奇妙的应用，帮助人们真正从中获益。大多数企业和社会都会受到大数据分析的影响，但大数据是究竟是如何帮助增加价值呢? 下面让我们来看看9个高价值大数据应用，这些都是大数据分析应用的关键领域： 1. 理解、定位客户，以及为客户提供服务 这是现在最大的最广为人知的大数据应用领域之一。这里的重点是使用大数据来更好地了解客户以及他们的行为和喜好。企业都热衷于收集社交媒体数据、浏览器日志、文本分析和传感器数据，来更全面地了解他们的客户。在大多数情况下，这里的总的目标是创建预测模型。例如美国零售商Target通过利用大数据分析，他们现在可以非常准确地预测他们的客户什么时候想要小孩。另外，通过使用大数据，电信公司现在可以更好地预测客户流失，沃尔玛可以更好地预测哪些产品将会热卖，汽车保险公司能够了解其客户的驾驶水平，而政府则能够了解选民的偏好。 2. 理解和优化业务流程 大数据也越来越多地用于优化业务流程。通过利用从社交媒体数据、网络搜索趋势以及天气预报挖掘出的预测信息，零售商能够优化其库存。其中广泛应用大数据分析的业务流程是供应链或配送路线优化。在这方面，地理定位或无线电频率识别传感器被用来追踪货物或送货车，并通过整合实时交通数据来优化路线。人力资源业务流程也能够通过使用大数据分析来改进。这包括优化人才招聘，以及使用大数据工具衡量公司文化和人员参与度。 3. 大数据改善每个人的生活 大数据不仅适用于企业和政府，也适用于我们每一个人。我们现在可以利用从可穿戴设备(例如智能手表或智能手链)生成的数据，这让我们可以追踪我们的热量消耗、睡眠模式等。我们还可以利用大数据分析来寻找爱情，大多数网上交友网站都使用大数据工具和算法来帮助我们寻找最合适的对象。 4. 提高医疗和研发 大数据分析的计算能力使我们能够在几分钟内解码整个DNA，并让我们可以找到新的治疗方法，同时更好地理解和预测疾病模式。就像所有人能够受益于智能手表和可穿戴设备产生的数据一样，大数据同样可以帮助病人更好地治病。未