AIX 5L 网络性能优化 第 2 部分
AIX 5L 网络性能优化: 第2 部分
这个有关AIX? 网络的系列共分三个部分，重点关注优化网络性能方面的各种挑战。第 1 部分提供了有关网络的概述，并且还介绍了监视硬件所需的一些工具（包括netstat、netpmon、entstat 和nmon）。第2 部分则重点关注优化NFS。您将了解诸如nfsstat 和nmon 之类的监视实用工具，并且您还将使用nfso 进行优化。本系列文章还提供了网络I/O 性能优化的一些最佳实践。
引言
在考虑使用网络文件系统(NFS) 时，性能优化往往被人忽视。您专注于正确地配置您的文件系统，并确保系统的安全性，以至于可能常常会忘记NFS 中的N 所代表的是网络。不幸的是，如果您没有认真地进行NFS 优化，那么您的网络文件系统就可能无法高效地工作。而幸运的是，IBM 集成了包括nffstat 和nfsmo 在内的几种工具，以帮助您在AIX 中对网络文件系统进行监视和优化。本文对相关监视和优化操作进行了介绍。
您必须同时对客户端和服务器进行优化。本文说明了如何使用netpmon 来监视NFS 客户端以及NFS 服务器的读取子例程和写入子例程。您还可以使用nmon 对NFS 活动进行快照，并且您可以了解如何使用nmon 来分析历史数据。使用netstat，您可以验证您的网络是否处于良好的状态，因为糟糕的网络使用率（或者没有进行仔细的配置）可能会导致低下的NFS 性能。本文还研究了一些可用于NFS 特定版本的实用工具，如nfs4cl。并且您将了解一些最佳实践，包括如何将I/O 分散到尽可能多的磁盘上。在这种情况下，你希望成为瓶颈的是CPU 负载，而不是您的I/O 系统。
与您在本系列文章中进行优化的其他领域有所不同，对于NFS 来说，您必须监视（并且很可能进行优化）包括CPU、内存、I/O 和网络在内的所有子系统。从客户端的角度来看，NFS 文件系统使用了远程连接的磁盘。任何影响所装入的磁盘性能的因素，都将影响NFS 客户端的性能。本文还介绍了一些重要的守护进程，如nfsd 和biod，以及它们是如何对自身进行优化的。您可以看到客户端和服务器之间的基本交互，以帮助您了解底层所执行的工作。最后，本文强调指出，无论您正在优化哪一个子系统，系统优化都将是一个持续不断的过程。当然，最好是从一开始，在您遇到问题并且用户开始抱怨之前，就开始监视您的系统。因为有许多因素都可能会影响NFS 的性能，所以一次只进行一项更改，这样一来，您就可以准确地评估您的更改所带来的效果。
回顾NFS
这个部分提供了与AIX 相关的网络文件系统的概述。您可以了解客户端和服务器之间如何相互关联、以及影响NFS 性能的各种因素。
Sun Microsystems 在1984 年发布了NFS，它允许客户端通过网络访问各种文件，就好像这些文件与磁盘一样是在本地进行连接的。1989 年引入了版本2，该版本只能通过UDP 进行操作。1995 年引入了版本3，该版本添加了对TCP 的支持，从而真正地使得NFS 在WAN 中大行其道。2000 年引入了版本4，这是由Internet Engineering Task Force（在Sun 放弃了对NFS 的开发控制之后）所开发的第一个版本。2003 年，RFC3530 中的NFS 得到了进一步增强，这也正是AIX 所支持的版本。AIX 5.3 支持 3 种NFS 版本：版本2、3 和4。缺省版本是版本3。请注意，Red Hat Linux? 的缺省NFS 版本是版本4。
您可以在实际装入文件系统的时候选择版本类型，并且您可以在服务器中运行不同的NFS 版本。现在，NFS 同时支持TCP 和UDP。因为UDP 的速度更快（它所进行的工作更少），所以对于某些需要在LAN 中实现最佳性能（而不是可靠性）的环境来说，使用UDP 的性能
可能会更好一些。TCP 则更加可靠（通过建立连接），并且它还可以在WAN 中提供更好的性能，因为它可以进行流量控制以帮助最大限度地减少网络延迟。
NFS 有一个优点，它的行为与具体的计算机类型和操作系统无关。它通过使用远程过程调用(RPC) 来实现这项功能，如图1 中所示。
图 1. 客户端和服务器之间的交互
图1 显示了NFS 客户端 A 和 B 如何访问位于NFS 服务器Z 的数据。首先，客户端计算机通过挂载文件系统，请求访问导出的数据。然后，当客户端线程尝试处理NFS 挂载的文件系统中的数据时，将这些数据重定向到biod，后者会通过LAN 将数据传递到NFS 服务器及其nfsd 守护进程。服务器使用nfds 来导出可供其客户端使用的目录。
正如您可以看到的，您将需要优化网络和I/O 参数。如果服务器Z 性能低下，那么这显然会影响其所有的NFS 客户端。如果可能的话，对服务器进行专的优化，以使其作为NFS 服务器（稍后将介绍更多相关内容）。
biod 守护进程又是启什么作用的呢？执行预读入和延迟写请求都需要这个守护进程。biod 守护进程提高了整体NFS 性能，因为它可以充当与客户端应用程序之间的中间环节，既可以清空缓冲区缓存，也可以填满缓冲区缓存。如图 1 中所示，biod 守护进程将请求发送给服务器。另一方面，nfsd 是将NFS 服务提供给客户端的中间环节。当服务器接收到客户端的biod 通信时，服务器将使用nfsd 守护进程，直到完成请求为止。
NFS 直到版本4 才是有状态的，尽管它早在版本2 中就可以使用TCP，这又是为什么呢？图2 显示了NFS 相对于TCP/IP 堆栈和OSI 模型而言所处的位置。
图 2. OSI - TCP/IP - NFS
因为NFS 使用了远程过程调用(RPC)，所以NFS 并不位于传输堆栈中。RPC 是一个过程库，允许客户端和服务器进程执行系统调用，就好像它们是在自己的地址空间中执行这些系统调用一样。在典型的UDP NFS 版本2 或者3 实现中，NFS 服务器在其客户端得到授权共享卷之后，向客户端发送某种类型的cookie。这将有助于最大限度地降低网络流量。但问题是，如果服务器宕机了，那么客户端将继续使用请求塞满网络。这正是为什么使用TCP 作为首选项的原因。只有版本 4 可以使用有状态的连接，并且只有版本 4 使用TCP 作为其传输协议。
NFS 版本4 没有与portmapper 或者其它的守护进程（如lockd 和statd）进行交互，因为它们合并到了内核中。在除版本 4 之外的其他版本中，portmapper 用于注册RPC 服务，并且提供客户端和服务器之间用于通信的端口号。外部数据表示形式(XDR) 提供了一种这样的机制，RPC 和NFS 可以使用这种机制来确保在客户端和服务器之间进行可靠的数据交换。它为二进制数据交换采用了一种平台独立的方式，以实现这些任务。这样做可以解决各种系统以不同方式来表现数据的可能性。使用XDR，可以正确地对数据进行解释，即使是在完全不同的平台中。
监视
这个部分提供了关于一些工具的概述，您可以使用这些工具来监视您的NFS 系统。这些工具允许您快速地对性能问题进行故障排除，并获取相关的数据以便进行历史趋势研究和分析。其中一些工具通常用于服务器，而其它工具则通常用于客户端。这部分内容将介绍nmon、topas、nfsstat、nfs、nfs4cl 和netpmon。
nmon 和topas
对于NFS 优化，您最初可以使用诸如topas 或者nmon 之类的工具，因为它提供了一个很好的全面视图，其中说明了您的系统中正在进行的工作。请记住，NFS 性能问题可能与您的NFS 子系统根本没有任何关系。您的瓶颈可能出现在网络中，或者从服务器的角度来
看，在您的CPU 或者磁盘I/O 中。运行诸如topas 或者nmon 之类的工具，可以使您迅速地了解真正的问题所在。本文中的示例系统有2 个CPU，并且它正在运行AIX 5.3 TL6。图3 从NFS 的角度显示了nmon 的输出。
图 3. nmon 输出
使用nmon，可以从NFS（客户端和服务器）的角度查看到所有可用的信息。在这个系统中，当前不存在任何瓶颈。尽管最近topas 已经提高了捕获数据的能力，但是nmon 可能仍然是更好的选择。尽管nmon 提供了类似于topas 的前端，但是nmon 更适合于长期趋势研究和分析。而且，nmon 为系统管理员提供了将数据输出到Microsoft? Excel 电子表格的能力，从而生成非常漂亮的、且清楚地说明您的瓶颈的图表（适用于高级管理和功能团队）。这些工作可以通过一个称为nmon analyzer的工具来完成，该工具提供了到nmon 的接口。可以免费下载nmon 分析程序（请参见参考资料）。
如何使用nmon 来捕获数据，并将其导入到该分析程序呢？使用sudo，首先运行nmon 3 个小时，每60 秒进行一次快照：# sudo nmon -f -t -r test1 -s 60 -c 180。然后，对所创建的输出文件进行排序：# sort -A systemnfs_yymmdd.nmon > systemnfs_yymmdd.csv。
接下来，使用ftp 将.csv 文件传输到您的计算机，启动nmon 分析程序（启用宏），并且单击analyze nmon data。
nfsstat
nfsstat 工具很可能是您进行相关工作时所使用的最重要的工具。这个命令可以显示有关NFS 和RPC 调用的所有类型的信息。可以将nfsstat 作作为一种监视工具来使用，以便对问题进行故障排除和性能优化。根据您所使用的标志，您可以使用nfsstat 来显示NFS 客户端或者服务器的信息。它还可以显示文件系统操作的实际使用计数。这有助于您详细地了解各个文件系统的使用情况，这样一来，您就可以了解如何最好地对您的系统进行优化。
首先来研究一下客户端标志（c）。r 标志可以提供RPC 信息（请参见清单1）。
清单1. 运行带 c 标志的nfsstat
root@lpar24ml162f_pub[/] > nfsstat -cr
Client rpc:
Connection oriented
calls badcalls badxids timeouts newcreds badverfs timers
14348 1 0 0 0 0 0
nomem cantconn interrupts
0 0 0
Connectionless
calls badcalls retrans badxids timeouts newcreds badverfs
23 0 0 0 0 0 0
timers nomem cantsend
0 0 0
root@lpar24ml162f_pub[/] >
这意味着什么呢?下面是一些面向连接的参数：
?calls —接收到的RPC 调用的数目
?badcalls —RPC 层拒绝的调用的数目
?badxids —收到的、不对应于任何未完成的调用的服务器应答次数
?timeouts —等待服务器应答超时的调用的次数
?newcreds —身份验证信息的刷新次数
?badverfs —由于响应中的错误验证而失败的调用的次数
如果您发现timeouts 或者badxids 的值很大，那么可以通过使用mount 命令增大timeo 参数来进行解决（稍后将详细描述）。.
nfs
现在来研究清单2 中的nfs 信息（n 标志）。
清单2. nfs n 标志信息
这意味着什么呢?版本 3 包括下面这些参数：
?calls —接收到的NFS 调用的数目
?badcalls —NFS 层拒绝的调用的数目
?clgets —接收到客户端句柄的次数
?cltoomany —没有未使用条目的客户端句柄的次数
nfs4cl
如果您正在运行NFS 版本4，那么您可能会更多地使用nfs4cl。这个命令可以显示NFS 版本4 的统计信息和属性。
清单3. 使用nfs4cl
在运行了这个命令之后，您将看见没有任何输出。运行mount 命令，以查看更详细的情况。
清单4. 运行mount 命令
正如您可以看到的，其中并没有使用NFS 版本 4 装入的文件系统，仅使用了NFS 版本3。与大多数性能优化命令不同，nfs4cl 还可以用于优化您的系统。通过使用setfsoptions 子命令优化NFS 版本4，您可以完成这项操作。还有一个参数您可以进行优化，即timeo，该参数指定了对服务器的RPC 调用的超时值。清单5 向您介绍了如何进行这项操作。
清单5. 使用nfs4cl 优化timeo
请记住，您还可以使用mount 命令来优化timeo。
netpmon
可以使用netpmon 命令帮助对NFS 瓶颈进行故障排除。除了监视许多其他类型的网络统计信息之外，netpmon 还可以监视客户端：包括读取和写入子例程、以及NFS RPC 请求。对于服务器，netpmon 可以监视读取和写入请求。netpmon 将启动跟踪并在后台运行，直到您停止它为止。
清单6. 使用netpmon
清单7 向您介绍了如何停止跟踪。
清单7. 停止跟踪
输出文件
现在来研究一下这个输出文件中所提供的NFS 特定的信息。
清单8. 输出文件中的NFS 特定的信息
NFSv3 Client RPC Statistics (by Server):
----------------------------------------
Server Calls/s
----------------------------------
p650 126.68
------------------------------------------------------------------------
Total (all servers) 126.68
Detailed NFSv3 Client RPC Statistics (by Server):
-------------------------------------------------
SERVER: p650
calls: 5602
call times (msec): avg 1.408 min 0.274 max 979.611 sdev 21.310
COMBINED (All Servers)
calls: 5602
call times (msec): avg 1.408 min 0.274 max 979.611 sdev 21.310
使用netpmon，您可以看到每台服务器的NFS 版本 3 客户端统计信息。请注意，虽然netpmon 是一个很有用的跟踪实用工具，但是性能开销有时甚至会超过其作用；因此在使用这个实用工具时请多加小心，特别是在可以采用其他方式获得类似信息的情况下。
使用nfsmo 和mount 进行优化
这个部分描述了特定的nfs 优化命令。使用nfsmo 以设置并显示您的nsfstat 优化参数。使用mount 优化基于NFS 服务器的资源，而这只有在挂载了NFS 文件系统之后才能生效。客户端
biod 守护进程在连接性方面起到了很重要的作用。当biod 自我优化线程数量（该守护进程根据需要创建和删除线程）时，可以根据整体负载，对biod 线程的最大数目进行优化。这里有一个非常重要的概念需要理解，仅增大线程的数目并不能减轻由CPU、I/O 或者内存瓶颈所引起的性能问题。例如，如果您的CPU 使用率接近100%，那么增大线程数量对您并没有任何
帮助。当多个应用程序线程访问同一个文件、并且不存在任何其他类型瓶颈的时候，增大线程数目可以起到帮助作用。使用lsof 可以进一步帮助您确定哪些线程正在访问哪些文件。
在前面的优化文章中，您可能还记得虚拟内存管理器(VMM) 的参数minperm 和maxperm。与优化数据库服务器有所不同，对于NFS 来说，您希望允许VMM 使用尽可能多的RAM 来进行NFS 数据缓存。大多数NFS 客户端对于工作段页面的需求很少。为了确保所有的内存都用于文件缓存，可以将maxperm和maxclient设置为100%。
请注意，如果您的应用程序使用了数据库，并且它可以从执行自己的文件数据缓存的应用程序中获益，那么在这种情况下，您不应该将maxperm 和maxclient 设置为100%。在这个实例中，将这些数值设置得较低，并且使用NFS 中的并行I/O 模式挂载文件系统。另外还请注意，NFS 在每个客户端系统中维护缓存，其中包含最近访问的文件和目录的属性。mount 命令可以控制在缓存中保存这些条目的时间长度。对于mount 命令的参数，您可以更改下面几项：
?actimeo
?acregmin
?acregmax
?acdirmin
?acdirmax
例如，acregmin参数可以指定在实际更新之后，文件条目将要保留的最短时间。在更新文件的时候，将根据这个参数的具体值，将其从缓存中删除。使用mount 命令，您还可以指定希望进行的是硬装入还是软装入。使用软装入，如果出现了错误，那么将立即对请求的程序进行报告；而对于硬装入，NFS 将不断地进行重试。这些重试本身可能会导致性能问题。从可靠性的角度而言，推荐使用硬装入读取和写入目录，以防止可能对数据造成的破坏。
mount 参数rsize和wsize分别定义读取和写入目录的RPC 包的最大值。缺省值是32768 个字节。对于NFS 版本3 和4，如果在高速网络中挂载您的NFS 卷，那么您应该将这个值增大到65536。另一方面，如果您的网络速度非常缓慢，那么您可能会为了通过发送较短的包来减少包碎片的数量，而考虑减少这个缺省值。然而，如果您减少这个缺省值，那么将需要发送更多的包，这可能会增加整体网络的使用率。了解您的网络，并对其进行相应的优化！
服务器
在分析特定的NFS 参数之前，尝试减少网络中的负载，同时分析CPU 和I/O 子系统。瓶颈通常会导致一些看似NFS 特定的问题。例如，NFS 既可以使用TCP，也可以使用UDP，这取决于您所使用的版本和您的偏好。请确保将您的tcp_sendspace和tcp_recvspace值设
置得高于缺省值，因为这可能会通过增加网络性能而对您的服务器产生影响。不能使用nfso 对这些内容进行优化，而是使用no。
如果您正在运行NFS 的版本4，那么请确保您启用了nfs_rfc1323（请参见清单11）。这允许TCP 窗口的大小大于64KB。同样在客户端中进行这样的设置。
或者，您还可以使用nfso 来设置rfc1323。
使用nfso 设置rfc1323，将TCP 窗口设置为只影响NFS（与no 相反，no 将其设置为整个范围）。如果您已经使用no 进行了设置，那么您不需要对其进行更改。
与客户端类似，如果服务器是专门的NFS 服务器，那么请确保您对VMM 参数进行了相应的优化。将maxperm和maxclient参数更改为100%，以确保VMM 在进程中使用尽可能多的内存来控制页面文件的缓存。在服务器中，优化多线程的nfsd，就像优化biod（您可以优化的其他守护进程，包括rpc.mountd 和rpc.lockd）一样。与biod、nfsd 的自我优化一样，这取决于具体的负载情况。使用nfso 命令增加线程的数目。一个这样的参数是
nfs_max_read_size，该参数将设置读取应答RPC 的最大大小。
分析清单13 中nfs_max_read_size 的设置。
现在，将它增加到64K（以字节为单位）。
您将这个值更改为所允许的最大值。如果您希望保留这些值，那么可以将其放入到
/etc/tunables/nextboot 文件中，这样一来，在重新启动系统之后，它们将仍然保持为经过更改的值。
您可以对更多的参数进行修改。要列出所有的这些参数，可以使用-a或者-L标志。-L可以采用更好的格式显示更详细的信息。
udpchecksum 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_socketsize 600000 600000 600000 40000 1M Bytes D --------------------------------------------------------------------------------
nfs_tcp_socketsize 600000 600000 600000 40000 1M Bytes D --------------------------------------------------------------------------------
nfs_setattr_error 0 0 0 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_gather_threshold 4K 4K 4K 512 8K+1 Bytes D
--------------------------------------------------------------------------------
nfs_repeat_messages 0 0 0 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_udp_duplicate_cache_size
5000 5000 5000 5000 100000 Req I
--------------------------------------------------------------------------------
nfs_tcp_duplicate_cache_size
5000 5000 5000 5000 100000 Req I
--------------------------------------------------------------------------------
nfs_server_base_priority 0 0 0 31 125 Pri D
--------------------------------------------------------------------------------
nfs_dynamic_retrans 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_iopace_pages 0 0 0 0 64K-1 Pages D
--------------------------------------------------------------------------------
nfs_max_connections 0 0 0 0 10000 Number D
--------------------------------------------------------------------------------
nfs_max_threads 3891 3891 3891 5 3891 Threads D
--------------------------------------------------------------------------------
nfs_use_reserved_ports 0 0 0 0 1 On/Off D
----------------------------------------------------------------------------
----
nfs_device_specific_bufs 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_server_clread 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_rfc1323 0 0 0 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_max_write_size 32K 32K 32K 512 64K Bytes D --------------------------------------------------------------------------------
nfs_max_read_size 64K 32K 32K 512 64K Bytes D
--------------------------------------------------------------------------------
nfs_allow_all_signals 0 0 0 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_v2_pdts 1 1 1 1 8 PDTs M
--------------------------------------------------------------------------------
nfs_v3_pdts 1 1 1 1 8 PDTs M
--------------------------------------------------------------------------------
nfs_v2_vm_bufs 10000 10000 10000 512 50000 Bufs I --------------------------------------------------------------------------------
nfs_v3_vm_bufs 10000 10000 10000 512 50000 Bufs I --------------------------------------------------------------------------------
nfs_securenfs_authtimeout 0 0 0 0 60 Seconds D --------------------------------------------------------------------------------
nfs_v3_server_readdirplus 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
lockd_debug_level 0 0 0 0 10 Level D
--------------------------------------------------------------------------------
statd_debug_level 0 0 0 0 10 Level D
--------------------------------------------------------------------------------
statd_max_threads 50 50 50 1 1000 Threads D
--------------------------------------------------------------------------------
nfs_v4_fail_over_timeout 0 0 0 0 3600 Seconds D --------------------------------------------------------------------------------
utf8_validation 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_v4_pdts 1 1 1 1 8 PDTs M
--------------------------------------------------------------------------------
nfs_v4_vm_bufs 10000 10000 10000 512 50000 Bufs I --------------------------------------------------------------------------------
server_delegation 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
nfs_auto_rbr_trigger 0 0 0 -1 1M MB D
--------------------------------------------------------------------------------
client_delegation 1 1 1 0 1 On/Off D
--------------------------------------------------------------------------------
n/a means parameter not supported by the current platform or kernel
Parameter types:
S = Static: cannot be changed
D = Dynamic: can be freely changed
B = Bosboot: can only be changed using bosboot and reboot
R = Reboot: can only be changed during reboot
C = Connect: changes are only effective for future socket connections
M = Mount: changes are only effective for future mountings
I = Incremental: can only be incremented
Value conventions:
K = Kilo: 2^10 G = Giga: 2^30 P = Peta: 2^50
M = Mega: 2^20 T = Tera: 2^40 E = Exa: 2^60
root@lpar24ml162f_pub[/tmp] >
现在，您获得了列出可修改的参数的列表！
总结
本文介绍了网络文件系统(NFS)，包括其历史和不同版本。本文定义并介绍了NFS I/O 堆栈、以及该堆栈与OSI 模型和TCP/IP 堆栈模型之间的关系。本文还介绍了在NFS 环境中进行磁盘配置和VMM 优化的最佳实践。
您研究了对客户端和服务器进行优化的区别。您对整体网络进行了监视，并且在监视的过程中深入地分析了NFS 层。而且，您使用nfso 和mount 优化了您的系统。
在本系列文章的下一个部分中，您将深入地研究实际的网络包。其中将包括对netstat 的更加详细的介绍。您还将了解如何使用no 实用工具来优化您的网络子系统。
性能优化的方法和技巧
性能优化方法和技巧：概述 性能优化有三个层次： ?系统层次 ?算法层次 ?代码层次 系统层次关注系统的控制流程和数据流程，优化主要考虑如何减少消息传递的个数；如何使系统的负载更加均衡；如何充分利用硬件的性能和设施；如何减少系统额外开销（比如上下文切换等）。 算法层次关注算法的选择（用更高效的算法替换现有算法，而不改变其接口）；现有算法的优化（时间和空间的优化）；并发和锁的优化（增加任务的并行性，减小锁的开销）；数据结构的设计（比如lock-free的数据结构和算法）。 代码层次关注代码优化，主要是cache相关的优化（I-cache, D-cache相关的优化）；代码执行顺序的调整；编译优化选项；语言相关的优化技巧等等。 性能优化需要相关的工具支持，这些工具包括编译器的支持；CPU的支持；以及集成到代码里面的测量工具等等。这些工具主要目的是测量代码的执行时间以及相关的cache miss, cache hit等数据，这些工具可以帮助开发者定位和分析问题。 性能优化和性能设计不同。性能设计贯穿于设计，编码，测试的整个环节，是产品生命周期的第一个阶段；而性能优化，通常是在现有系统和代码基础上所做的改进，属于产品生命周期的后续几个阶段（假设产品有多个生命周期）。性能优化不是重新设计，性能优化是以现有的产品和代码为基础的，而不是推倒重来。性能优化的方法和技巧可以指导性能设计，但两者的方法和技巧不能等同。两者关注的对象不同。性能设计是从正向考虑问题：如何设计出高效，高性能的系统；而性能优化是从反向考虑问题：在出现性能问题时，如何定位和优化性能。性能设计考验的是开发者正向建设的能力，而性能优化考验的是开发者反向修复的能力。两者可以互补。
网络优化解决方案
网优中心 针对多厂家交换数据的装置 基于数据仓库技术的元数据驱动设计及多维分析方法 基于 基于数据仓库多维分析方法的网络性能分析、指标（ 网络运行性能、运行资源、运行收益及客户满意度的综合分析网络关键数据的自动发布、监控告警体系 网络容量、性能、负荷等运行趋势分析、预测 网络资源、负荷、话务等均衡优化 基于 用户自定义的多维报表体系 为网络的中高级领导层提供管理决策支持 为网络的综合监测、网络优化、网络规划提供服务
参数高速的跟踪分析，发现影响网络性能的关键参数及参数最优设置 运行参数与设计参数的对比分析，指导参数的设置和检查规划数据的合理性不同时期的参数对比分析，发现影响网络性能的关键参数及参数最优设置可视化、地理化的参数查询 运行参数自动合理性检查 适应网络体系结构的变化，可以进行基站割接、增加和删除等操作 根据不同的用户设置不同的权限 方便的网优维护日志管理 针对多厂家话务数据的装载 主要网元（ 可由用户自定义的网络性能指标体系和计算公式 多维度的指标分析、追踪 异常网元的定位 网络性能指标的地理化分析 实时自动生成用户定义的动态报表体系 自动生成专业的分析报告 针对典型网络问题的专家分析 用户定义的网络性能监控与报警 针对单个或多个呼叫过程的跟踪、分析 失败事件的统计、跟踪和分析，根据失败信令点的无线环境和 小区无线指标分布分析（ 小区无线统计报告 移动网络测试优化分析系统
带有数字化电子地图实时地理导航 测试和回放时所有窗口实时关联、互相对应测试时自动识别网络 广播信道 时隙测试功能 CQT
强制切换测试和锁频测试 可同时对移动 实时邻频干扰载干比测试 GSM 测试和回放时测试点与服务主小区实时连线 扫频支持： 支持 主叫自动拨号、被叫自动应答 CDD 地理化描述无线网络的各项测试参数 专题分析无线下行覆盖、干扰、切换等网络问题 话务数据的地理化观测 准确的双网关对比统计报告，用户可选的强大综合统计报告空闲 频率复用的地理化观测 利用高速扫频数据做信号传播及干扰分析 主小区的 六个邻小区信息 三层信令信息 信道和无线 SQI 网络参数信息（ 信令事件实时显示和统计 采集事件实时显示和统计 GSM/DCS 协议支持 对于 连续信道场强扫频速度 设备尺寸长 移动网络室内测试系统
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/3c12696308.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、利用数据库分区技术 通过尝试效果明显，仅供参考！
无线网络优化方案.
无线网络优化方案 调整 AP 覆盖方向或天线角度 应用说明: 在设备的工程安装过程中,合理选择 AP 的位置,合理调整 AP 的覆盖方向或外置天线的角度,尽量减少覆盖盲点和同频干扰,改善信号覆盖质量。目标覆盖区域的信号覆盖强度目标 -65dBm~-70dBm。 信道规划 应用说明: 信道规划和功率调整将是 WLAN 网络的首要的、最先实施的优化方法。在实际的安装部署中, 通常一个 AP 的信号覆盖范围可能很大, 但为了提高覆盖信号质量以及接入密度,又必须部署相应数量的 AP ,造成 AP 的覆盖范围出现重叠, AP 之间互相可见。如果所有的 AP 都工作在相同信道,这些 AP 只能共享一个信道的频率资源,造成整个 WLAN 网络性能较低。 WLAN 协议本身提供了一些不重叠的物理信道,可以构建多个虚拟的独立的 WLAN 网络, 各个网络独立使用一个信道的带宽, 例如使用 2.4G 频段时可以使用 1、 6、 11三个非重叠信道构建 WLAN 网络。 同时信道规划调整需要考虑三维空间的信号覆盖情况,无论是水平方向还是垂直方向都要做到无线的蜂窝式覆盖,最大可能的避免同楼层和上下楼层间的同频干扰。 强烈推荐:802.11n 网络在实际部署时,无论是 2.4G 频段或 5G 频段,建议都采用20MHz 模式进行覆盖,以加强信道隔离与复用,提升 WLAN 网络整 体性能。 功率调整
应用说明: 信道规划和功率调整将是 WLAN 网络的首要的、最先实施的优化方法。完成信道规划就相当于完成了多个虚拟 WLAN 网络的构建。 AP 发射功率的调整需要逐个关注每个虚拟 WLAN 网络,通过调整同一信道的 AP 的发射功率, 降低这些 AP 之间的可见度, 加强相同信道频谱资源的复用, 提高 WLAN 网络的整体性能。 禁止弱信号终端接入 应用说明: 在 WLAN 网络中, 信号强度较弱的无线客户端, 虽然也可以接入到网络中,但是所能够获取的网络性能和服务质量要比信号强度较强的无线客户端差很多。如果弱信号的无线客户端在接入到 WLAN 网络的同时还在大量地下载数据,就会占用较多的信道资源,最终必然对其他的无线客户端造成很大的影响。 禁止弱信号客户端接入功能,通过配置允许接入的无线客户端的最小信号强度门限值,可以直接拒绝信号强度低于指定门限的无线客户端接入到 WLAN 网络中,减少弱信号客户端对其他无线客户端的影响,从而提升整个 WLAN 网络的应用效果。 对于信号强度比较弱的终端,或者距离比较远的终端,关闭低速率应用后可能会出现丢包现象。但是正常的室内覆盖,信号强度可以保证,所以要求在室内覆盖情况下此功能为必选项。 低速率用户限制,对于典型的“占着信道不使用的情况”进行限制,这个 数值建议在 -75到 -80,前提是要做好信号覆盖: 调整 Beacon 帧发送间隔 应用说明:
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/3c12696308.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条记录，
网络性能优化
网络性能优化总结 网络性能优化的目的是减少网络系统的瓶颈、设法提高网络系统的运行效率。对于不同的网络硬件环境和软件环境，可以存在不同的优化方法和内容。例如，在一个配置比较落后而又需要提供各种新服务的网络中，管理员往往需要对内存、CPU、磁盘、网络接口和服务器等分别进行优化处理，以便适应新的网络运行要求。但是，在一个网络服务比较少而硬件配置比较高的网络中，管理员不需要考虑整个网络的性能问题，只要利用一些性能和网络监视工具对系统进行监视，然后对发现的问题进行专项处理即可。下面对网络性能优化过程中的重要内容分别进行介绍。 7.2.1 内存优化 内存是操作系统中的重要资源，不仅操作系统的运行需要它，而且各种应用程序和服务都需要调用它才能使用。从应用的角度来看，系统内存是引起各种系统问题的重要原因，是需要用户和管理员着重考虑的优化对象。 1. 合理使用内存 在内存一定的情况下，合理地使用内存可以提高网络的性能。这要求管理员必须对系统中的内存使用情况非常了解，对于那些不再需要的功能、应用程序或服务应及时关闭，以便释放内存给其他应用程序和服务。另外，管理员还可以通过系统设置来决定内存的主要优化对象。一般，服务器的主要优化对象应该是后台服务，而工作站和单个计算机的主要优化对象应该是前台应用程序。 要选择内存优化的主要对象，可执行下面的操作步骤： (1) 打开“控制面板”窗口，右击“系统”图标，从弹出的快捷菜单中选择“打开”命令，打开“系统特性”对话框。 (2) 单击“高级”标签，切换到“高级”选项卡，然后单击“性能”选项组中的“性能选项”按钮，打开“性能选项”对话框，如图7-1所示。 图7-1 “性能选项”对话框
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、内存
网络优化基本方法
随着CDMA技术在国内运营商的成熟应用，CDMA的网络优化成为运营商、设计单位和设备商共同关注的焦点。CDMA网络优化有其自身特点，CDMA特有的软切换方式使基站信号的控制比其他移动通信系统更为重要，这也增加了控制难度，如果信号控制不当，可能造成导频污染、强干扰等致使网络性能下降的问题。在实际工程中，应对出现的网络问题进行归纳总结，结合实地勘察、路测和OMC报表分析得出原因，不断积累网络优化的工程经验，打造精品网 络。 前向链路干扰问题 一是邻集列表丢失。解决方案：将该PN添加到激活扇区的邻集列表内。若该PN已经在 邻集列表内，则将其优先级提升。 二是突发强PN干扰。解决方案：引入软切换消除突发强PN干扰小区，可以通过增大导频功率，将突发PN顺利软切换，也可通过调整天线方向角、导频功率等措施，将信号发射至原来的阻挡区域以造成覆盖，或是降低切换参数T_ADD。还可适当增大SRCH_WIN_x窗口，以便手机发现该PN。消除突发PN的方法还有，先通过降低导频功率清除突发PN，或是通过调整天线方向、下倾角、更换天线等物理方法进行优化。 三是共PN干扰。解决方案：改变其中一个基站的PN值。定期对PN进行重新调整，这是一个长期艰难的工作，但对系统有很大好处。 边缘覆盖问题 由于该区域噪声电平Io通常很低，因而即使信号很弱，Ec/Io仍然较好。这种情况下的服务小区通常在网络的边缘，在网络建设期，为了增大覆盖，这些基站一般来说较高。可能的解决方案：如果是小区覆盖范围过大，则可以加大天线下倾角，减小导频功率，更换低增益天线，必要时在基站发射天线的馈线上加一个衰减器；如果希望增加小区覆盖范围，则可以增加导频功率，更换高增益天线；如果反向链路受限，小区天线加装塔放会有一定效果。 覆盖空洞 这种情况通常由于覆盖不够引起，可能是服务基站太远，或者服务基站被阻挡，FFER 在一些地区是好的，但在某些场所较差。解决方法：增加某一扇区的导频功率使之有主导频；对一个或多个服务扇区的物理参数进行优化(如天线方位角、倾角及天线类型)；在容量不受限的情况下，使用直放站增加覆盖；增加新站来覆盖空洞；在高话务区增加载波；采用波瓣跨度较窄、增益较高的天线来覆盖某一建筑物；建筑密集区可用六扇区方式来解决，但要根 据路测结果来调整天线的物理参数。 导频污染 有超过三个的导频信号强度差不多，而Ec/Io值大于-12dB，则认为是导频污染。解决方案：控制无线环境从而减少导频过覆盖；降低不需要的导频功率；优化天线的物理参数；减少导频污染的方法：在该区域画出所有基站的导频覆盖图，注明所有过覆盖的PN，或是
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.应用缓存技术减少应用存取磁盘的次数，缓存技术可应用在文件系统级别或者应用程序级别。