查看内存使用情况，可以使用命令 free -m
其结果大致如下：
total used free shared buffers cached
Mem: 32108 30681 1426 0 123 21165
-/+ buffers/cache: 9392 22715
Swap: 34287 1262 33025
在第一部分Mem 行中有如下参数：
total: 内存总数，即32108 MB
used: 已经使用的内存数，即 30681 MB
free: 空闲的内存数：即 1426MB
shared：当前已废弃不用，总是 0
buffers Buffer: 缓存内存数，即 123 MB
cached Page: 缓存内存数，即 421MB
其中，内存总数与已经使用内存数和空闲内存数的关系是：
total (32108) = used (30681) + free (1426)
在第二部分内容(-/+ buffers/cache)中个参数如下所示：
（-buffers/cache）: 真正使用的内存数，即9392M，他指的是第一部分的 used - buffers - cached
（+buffers/cache）: 可用的内存数，即22715M，他指的是第一部分的 free + buffers + cached
其含义可以理解为：-buffers/cached 反映的是被程序实实在在用掉的内存，而 +buffers/cached反映的是可以被使用（或者说挪用）的内存总数。
不要对那些同步等待其它任务结果的任务排队。这可能会导致上面所描述的那种形式的死锁，在那种死锁中，所有线程都被一些任务所占用，这些任务依次等待排队任务的结果，而这些任务又无法执行，因为所有的线程都很忙。
在为时间可能很长的 *** 作使用合用的线程时要小心。如果程序必须等待诸如 I/O 完成这样的某个资源，那么请指定最长的等待时间，以及随后是失效还是将任务重新排队以便稍后执行。这样做保证了：通过将某个线程释放给某个可能成功完成的任务，从而将最终取得某些进展。
理解任务
要有效地调整线程池大小，您需要理解正在排队的任务以及它们正在做什么。它们是 CPU 限制的（CPU-bound）吗？它们是 I/O 限制的（I/O-bound）吗？您的答案将影响您如何调整应用程序。如果您有不同的任务类，这些类有着截然不同的特征，那么为不同任务类设置多个工作队列可能会有意义，这样可以相应地调整每个池。
调整池的大小
调整线程池的大小基本上就是避免两类错误：线程太少或线程太多。幸运的是，对于大多数应用程序来说，太多和太少之间的余地相当宽。
请回忆：在应用程序中使用线程有两个主要优点，尽管在等待诸如 I/O 的慢 *** 作，但允许继续进行处理，并且可以利用多处理器。在运行于具有 N 个处理器机器上的计算限制的应用程序中，在线程数目接近 N 时添加额外的线程可能会改善总处理能力，而在线程数目超过 N 时添加额外的线程将不起作用。事实上，太多的线程甚至会降低性能，因为它会导致额外的环境切换开销。
线程池的最佳大小取决于可用处理器的数目以及工作队列中的任务的性质。若在一个具有 N 个处理器的系统上只有一个工作队列，其中全部是计算性质的任务，在线程池具有 N 或 N+1 个线程时一般会获得最大的 CPU 利用率。
对于那些可能需要等待 I/O 完成的任务（例如，从套接字读取 >一、对外表现
1应用访问速度慢、应用报错(WAS性能差)
2应用(server)停止对外服务无法访问(WAS服务挂起或者服务器宕机)
二、xxx系统我们发现过的问题
1WAS内存处理大对象内存分配bug(大报文(20M)-小报文(20M)-20M)
2内存回收碎片(java heap free memory很多，一个很小的报文都申请不到内存)
3WAS MDB侦听MQ队列问题
三、排查思路
思路：
1查看收集服务器性能指标，内存使用、CPU使用包括磁盘I/O等。
2查看收集 *** 作系统级日志。
3根据服务器的性能指标以及 *** 作系统级日志，基本定位是否存在影响性能的瓶颈，通过排除那些不是导致问题发生的因素，以缩小问题的范围，可以使问题简单化，并且避免浪费时间。举例：
CPU使用不高，用户感觉交易响应时间很长，可以断定是由于系统的某一小部分造成了瓶颈，导致了所有的请求都在等待。我们可以考虑，线程池的数量开的太小，导致所有的请求都在排队等待进入线程池，因为没有可用的线程使用，所以这个交易请求一直在排队，导致交易响应时间很长。数据库连接池开的太小，也会有同样的表现。
CPU使用很高，用户感觉交易响应时间很长，比较复杂。可能的根源之一是硬件资源不够。 根源之二是应用系统中产生了多个大对象。根源之三是程序算法有问题。 解决思路如下：用性能分析器, 对运行环境进行分析，分析哪个类甚至于哪个函数消耗了这么多的CPU，并找到相应的解决方案。
4收集分析WAS日志
当应用服务器发生挂起、或者发生out-of-memory等现象时，为了更好的全面分析问题，则需要收集一定的日志信息，一般情况下我们需要收集以下这些日志：
1)收集垃圾回收日志native_stderrlog或者native_stdoutlog。
2)收集应用服务器(install_root/profiles/profile_name/logs/server_name)下所有的日志(systemout)。
3)收集install_root/profiles/profile_name/目录下的JavaCore文件和Heapdump文件，如果没有这些文件，可以在服务器没有响应的时候，运行命令来生成这些文件，对于IBM JDK中可以运行kill -3 PID_Java_jvm，然后每隔两分钟，重复执行该命令，至少3次，通过该命令生成的JavaCore文件会在install_root/ profiles目录下。
4)收集首个故障数据捕捉日志/logs/ffdc。
5)收集Web server服务器，插件Plug-in(plugin-cfgxml and >以下几篇文章有讨论这个话题：
根据CPU核心数确定线程池并发线程数
如何合理地估算线程池大小？
引用某知乎同学的总结如下： 原文链接
一般说来，大家认为线程池的大小经验值应该这样设置：（其中N为CPU的个数）
如果一台服务器上只部署这一个应用并且只有这一个线程池，那么这种估算或许合理，具体还需自行测试验证。但是，IO优化中，这样的估算公式可能更适合：
下面举个例子：
比如平均每个线程CPU运行时间为05s，而线程等待时间（非CPU运行时间，比如IO）为15s，CPU核心数为8，那么根据上面这个公式估算得到：((05+15)/05)8=32。这个公式进一步转化为：1，Linux下可以在/proc/cpuinfo中看到每个cpu的详细信息。但是对于双核的cpu，在cpuinfo中会看到两个cpu。常常会让人误以为是两个单核的cpu。
其实应该通过Physical Processor ID来区分单核和双核。而Physical Processor ID可以从cpuinfo或者dmesg中找到 flags 如果有 ht 说明支持超线程技术 判断物理CPU的个数可以查看physical id 的值，相同则为同一个物理CPU
2，查看内存大小:
cat /proc/meminfo |grep MemTotal
3，其他一些可以查看详细linux系统信息的命令和方法:
uname -a # 查看内核/ *** 作系统/CPU信息的linux系统信息命令
head -n 1 /etc/issue # 查看 *** 作系统版本，是数字1不是字母L
cat /proc/cpuinfo # 查看CPU信息的linux系统信息命令
hostname # 查看计算机名的linux系统信息命令
lspci -tv # 列出所有PCI设备
lsusb -tv # 列出所有USB设备的linux系统信息命令
lsmod # 列出加载的内核模块
env # 查看环境变量资源
free -m # 查看内存使用量和交换区使用量
df -h # 查看各分区使用情况
du -sh # 查看指定目录的大小
线程池的最大线程数：
1、net40，32位机器最大线程数，每核1023个
2、net40，64位机器最大线程数，每核32768个
3、net30，最大线程数，每核250个
4、net20，最大线程数，每核25个
默认的最小线程数是每核1个。在服务器端环境，比如iis下的aspnet最小线程数会更大可能超过50。
线程池是一种多线程处理形式，处理过程中将任务添加到队列，然后在创建线程后自动启动这些任务。线程池线程都是后台线程。每个线程都使用默认的堆栈大小，以默认的优先级运行，并处于多线程单元中。如果某个线程在托管代码中空闲（如正在等待某个事件），则线程池将插入另一个辅助线程来使所有处理器保持繁忙。如果所有线程池线程都始终保持繁忙，但队列中包含挂起的工作，则线程池将在一段时间后创建另一个辅助线程但线程的数目永远不会超过最大值。超过最大值的线程可以排队，但他们要等到其他线程完成后才启动。
组成部分：
服务器程序利用线程技术响应客户请求已经司空见惯,可能您认为这样做效率已经很高，但您有没有想过优化一下使用线程的方法。该文章将向您介绍服务器程序如何利用线程池来优化性能并提供一个简单的线程池实现。
1、线程池管理器（ThreadPoolManager）：用于创建并管理线程池。
2、工作线程（WorkThread）：线程池中线程。
3、任务接口（Task）：每个任务必须实现的接口，以供工作线程调度任务的执行。
4、任务队列：用于存放没有处理的任务。提供一种缓冲机制。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）