1、配置每个进程可以打开的文件数

ulimit -a 或者 ulimit -n

2、系统总的可打开的文件数 # cat /proc/sys/fs/file-max

man proc，可得到file-max的描述：

/proc/sys/fs/file-max

3、INODE 数目 就是所有文件数，除去目录 如现在有一个25KB的文件，而数据块的大小则为4KB。则此时这个文件会占用7个数据块，但是只占用了一个inode节点。

#df Filesystem 1K-blocks Used Available Use% Mounted on /dev/vda1 41152716 33669260 5737052 86% /

#tune2fs -l /dev/vda1 |grep inodes Free inodes: 2571834

#ulimit -a pending signals (-i) 7913 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 65535 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 7913

修改： 1.在/etc/security/limits.conf 文件里添加如下内容 * soft nproc 65535 #打开进程数 * hard nproc 65535 #打开进程数

cat /proc/sys/kernel/pid_max 在 /etc/sysctl.conf 中添加 kernel.pid_max = 65535

# sysctl kernel.pid_max

kernel.pid_max = 32768 echo 65535 > /proc/sys/kernel/pid_max

所以以上都操作完成后，才算是正确修改了 max user processes 的值

#df -i 查看inode 数量

以 JVM 的 CMS 收集器为例，对于高并发的场景，瞬间产生大量的对象，这些对象的存活时间又非常短

增加新生代；适当调大编程老生代的次数；提前触发老生代； 适当增大新生代的大小，保证新生代有足够的空间来容纳新产生的对象。当然如果老年代设置的过小，会导致频繁的 Full GC。 适当调大新生代向晋升老年代的存活次数，减少无效对象晋升老年代的机率；同时控制新生代存活区的大小，如果设置的过小，很容易造成那些无法容纳的新生代对象提前晋升。 提前触发老年代的 Full GC，因为如果等待老年代满了再开始回收，可能会太晚，这样很容易造成长时间的 Full GC。一般设在 70% 的安全水位进行回收。而且回收的时候，需要触发一次 Young GC，这可以减少重新标记阶段应用暂停的时间，另一方面，也防止在回收结束后，有大量无效的对象进入老年代中。 设置需要进行内存压缩整理的 GC 次数，内存整理，很多时候是造成长时间 GC 的主要原因。因为内存整理是采用 Serial Old 算法，以单线程的方式进行处理，这个过程会非常慢。尤其是在老年代空间不足的情况下，GC 的时间会变得更长。