转:Linux 调优基本策略(ulimit)

ulimit -a 用来显示当前的各种用户进程限制。

    Linux对于每个用户，系统限制其最大进程数。为提高性能，可以根据设备资源情况，
    设置各linux 用户的最大进程数，下面我把某linux用户的最大进程数设为10000个：

     ulimit -u 10000

     对于需要做许多 socket 连接并使它们处于打开状态的 Java 应用程序而言，
     最好通过使用 ulimit -n xx 修改每个进程可打开的文件数，缺省值是 1024。
     ulimit -n 4096 将每个进程可以打开的文件数目加大到4096，缺省为1024

     其他建议设置成无限制（unlimited）的一些重要设置是：
     数据段长度：ulimit -d unlimited
     最大内存大小：ulimit -m unlimited
     堆栈大小：ulimit -s unlimited
     CPU 时间：ulimit -t unlimited
     虚拟内存：ulimit -v unlimited
　　
     暂时地，适用于通过 ulimit 命令登录 shell 会话期间。
     永久地，通过将一个相应的 ulimit 语句添加到由登录 shell 读取的文件中， 即特定于 shell 的用户资源文件，如：

 

1)、解除 Linux 系统的最大进程数和最大文件打开数限制：
        vi /etc/security/limits.conf
        # 添加如下的行
        * soft noproc 11000
        * hard noproc 11000
        * soft nofile 4100
        * hard nofile 4100

       说明：* 代表针对所有用户
                    noproc 是代表最大进程数
                    nofile 是代表最大文件打开数

2)、让 SSH 接受 Login 程式的登入，方便在 ssh 客户端查看 ulimit -a 资源限制：
        a、vi /etc/ssh/sshd_config
             把 UserLogin 的值改为 yes，并把 # 注释去掉
        b、重启 sshd 服务：
              /etc/init.d/sshd restart

3)、修改所有 linux 用户的环境变量文件：

vi /etc/profile

ulimit -u 10000
ulimit -n 4096
ulimit -d unlimited
ulimit -m unlimited
ulimit -s unlimited
ulimit -t unlimited
ulimit -v unlimited

 

 

 

/**************************************

 

有时候在程序里面需要打开多个文件，进行分析，系统一般默认数量是1024，（用ulimit -a可以看到）对于正常使用是够了，但是对于程序来讲，就太少了。

修改2个文件。

1./etc/security/limits.conf
vi /etc/security/limits.conf
加上：
* soft nofile 8192
* hard nofile 20480

2./etc/pam.d/login
session required /lib/security/pam_limits.so

**********
另外确保/etc/pam.d/system-auth文件有下面内容
session required /lib/security/$ISA/pam_limits.so
这一行确保系统会执行这个限制。
***********

3.一般用户的.bash_profile
#ulimit -n 1024

重新登陆ok

 

 

-------------

对于solaris

 

其实在系统里面有这样一个命令ulimit，以下是ulimit -a执行的结果：

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 1024
memory(kbytes) unlimited

其中nofiles就是文件描述符的变量值，该值受rlim_fd_cur这个参数的影响，可以用ulimit -n number命令来修改。但不管怎么改,程序仍然不能突破fd=256的限制。在Solaris Tunable Parameters Reference Manua这本书里面能查到以下的资料：

A 32-bit program using standard I/O is limited to 256 file descriptors。
A 64-bit program using standard I/O can use up to 2 billion descriptors。

这也就是说32位的程序是没有办法突破这个限制的，只有64位的程序才能使用高达2亿个文件描述符，SUN的软硬件在很早以前就实现了64位的架构，现在唯一要解决的就是将程序编译成64位程序，为了生成64位程序,就必须要有64位的编译器（其实不是这样的）,如果你去下载64位编译器gcc，网站上没有特别注明是64位的gcc，但是会有个意外的收获，就是该软件的说明里面注明了只要在用gcc编译的时候加上-m64的option就能生成64位程序了。

于是用gcc -m64去编译生成一个64位程序后，用ulimit -n 102400将number of fd设成很大的情况下，所有问题迎刃而解，再也不存在文件描述符不够用的情况。

在/etc/system文件设置rlimi_fc_max和rlim_fd_cur格式如下：

* set hard limit on file descriptors
set rlim_fd_max = 4096
* set soft limit on file descriptors
set rlim_fd_cur = 1024

命令ulimit使用格式如下：

usage: ulimit [ -HSacdfnstv ] [ limit ]
ulimit -a是显示各参数的设置值，ulimit -n是用来设置fd的最大值的。

*************************************************

如何修改文件描述符限制？

Solaris有两个参数控制进程可打开的文件描述符：rlim_fd_max，rlim_fd_cur。前者修改是个硬设置，修改需要权限，后者 是个软设置，用户可以limit或者setrlimit() 修改，该值最大不能超过前者。一般我们在/etc/system里修改这两个参数

set rlim_fd_max = 65535

set rlim_fd_cur = 65535

 

 

A: You have two ways to modify the limit number of files that a process
can open simutanously.
One: modify the /etc/system file add the following entry:
set rlim_fd_cur = #n
#n is the number you want. Should be no more than 1024.
You should reboot the machine.
Two: Use the system command: ulimit
$ulimit -n #n
Note: You should use B-shell.
And using the same terminal session(in the same terminal
window) to run the your application program( to guarantee your
application process is a child process of the setting
terminal.)You can man ulimit to see the detailed usaged.
The disadvantage brought by incread the file limite for a
process or the whole system is increasing the system memory
usage. But, for today\'s machine, this disadvantage is not too
expensive. (William said:) There is no limit for max open
socket number in Java. But the operating system has a limit for
max open file descriptors.A socket resource is treated as a
file descriptor in Unix. The previous email answered your
question. You can try as said.