首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Unix编程/应用问答中文版 ---6./etc/system可调资源限制

    本文出自:[url]http://www.nsfocus.com[/url] 维护:小四 6. /etc/system可调资源限制 6.1 Solaris下如何限制每个用户可拥有的最大进程数 6.2 如何配置系统使之支持更多的伪终端 6.3 如何增加每个进程可打开文件句柄数 6.4 6.5 做了setuid()这类调用的程序如何产生core dump 6.6 消息队列调整 -------------------------------------------------------------------------- 6. /etc/system可调资源限制 6.1 Solaris下如何限制每个用户可拥有的最大进程数 A: Casper Dik 在/etc/system设置 set maxuprc = Q: maxusers参数究竟影响了什么 A: Casper Dik 下面以/etc/system语法格式举例说明: * set maxusers = <以MB为单位计的可用物理内存数量> * 系统所允许的最大进程数,通常最多30000 set max_nprocs = 10 + 16 * maxusers * 每个用户可以拥有的最大进程数(为超级用户保留5个) set maxuprc = max_nprocs - 5; # sysdef | sed -n '/System Configuration/,$p' 6.2 如何配置系统使之支持更多的伪终端 A: Argoth 不要试图通过'/usr/bin/adb -k'到达目的。 a. 如果Solaris版本小于7,修改/etc/system,增加如下行 set pt_cnt= 执行/usr/sbin/reboot -- -r,或者Stop-A,执行boot -r b. 对于Solaris 8,支持的伪终端数目根据需要动态改变,系统依然有一个内部限制, 但是这个值非常大。如果"pt_cnt"变量小于这个内部限制,将被忽略。一般情况 下,不再需要指定"pt_cnt"变量。但还是有某些罕见的情形,需要设置"pt_cnt" 变量大于内部限制。 6.3 如何增加每个进程可打开文件句柄数 A: Casper Dik 从Solaris 2.4开始,可以通过修改/etc/system实现 * set hard limit on file descriptors set rlim_fd_max = 4096 * set soft limit on file descriptors set rlim_fd_cur = 1024 软限制超过256时,某些应用程序会出问题,尤其BCP程序。软限制超过1024时,那些 使用select()的应用程序可能会出问题。Solaris 7之前,select()使用的文件句柄 数不能超过1024。Solaris 2.6的RPC代码被重写过了,使用poll()代替select(),可 以使用超过1024的文件句柄。Solaris 2.6之前,如果软限制超过1024,所有RPC服务 很可能崩溃。 Solaris 7下select()可以使用最多达65536的文件句柄,64-bit应用程序缺省情况如 此。如果是32-bit应用程序,需要指定给FD_SETSIZE一个更大的值,重新编译。 如果程序使用标准输入/输出(stdio),或者调用那些使用stdio的库函数,当打开的 文件超过256时,程序可能会出问题,这个限制是stdio的限制。当程序需要大量文件 句柄时,应该想办法保留一些小数字的文件句柄,让stdio使用它们。 Solaris 7下64-bit应用程序不再受这个stdio限制的影响。如果你的确需要超过256 个FILE *,而又不能使用Solaris 7,或者需要运行32-bit代码,考虑使用来自AT&T 的SFIO([url]http://www.research.att.com/sw/tools/sfio/[/url])。 A: [email]qaz@smth.org[/email] 检查当前设置 # ulimit -H -n 1024 # ulimit -S -n 64 # 对于Solaris,建议修改/etc/system后重启 * set hard limit on file descriptors set rlim_fd_max=0x8000 * set soft limit on file descriptors set rlim_fd_cur=0x8000 然后 ulimit -S -n 8192 对于Linux echo 65536 > /proc/sys/fs/file-max 然后 ulimit -S -n 8192 对于FreeBSD 编辑/etc

    03

    Laravel学习笔记之bootstrap源码解析

    说明:Laravel在把Request通过管道Pipeline送入中间件Middleware和路由Router之前,还做了程序的启动Bootstrap工作,本文主要学习相关源码,看看Laravel启动程序做了哪些具体工作,并将个人的研究心得分享出来,希望对别人有所帮助。Laravel在入口index.php时先加载Composer加载器:Laravel学习笔记之Composer自动加载,然后进行Application的实例化:Laravel学习笔记之IoC Container实例化源码解析,得到实例化后的Application对象再从容器中解析出Kernel服务,然后进行Request实例化(Request实例化下次再聊),然后进行Bootstrap操作启动程序,再通过Pipeline送到Middleware:Laravel学习笔记之Middleware源码解析,然后经过路由映射找到对该请求的操作action(以后再聊),生成Response对象经过Kernel的send()发送给Client。本文主要聊下程序的启动操作,主要做了哪些准备工作。

    00

    Laravel5.3之bootstrap源码解析

    说明:Laravel在把Request通过管道Pipeline送入中间件Middleware和路由Router之前,还做了程序的启动Bootstrap工作,本文主要学习相关源码,看看Laravel启动程序做了哪些具体工作,并将个人的研究心得分享出来,希望对别人有所帮助。Laravel在入口index.php时先加载Composer加载器:Laravel5.2之Composer自动加载,然后进行Application的实例化:Laravel5.3之IoC Container实例化源码解析,得到实例化后的Application对象再从容器中解析出Kernel服务,然后进行Request实例化(Request实例化下次再聊),然后进行Bootstrap操作启动程序,再通过Pipeline送到Middleware:Laravel5.3之Middleware源码解析,然后经过路由映射找到对该请求的操作action(以后再聊),生成Response对象经过Kernel的send()发送给Client。本文主要聊下程序的启动操作,主要做了哪些准备工作。

    05

    zabbix监控常见系统报错

    CPU触发器: 1)Processor load is too high on {HOST.NAME} {HOST.NAME}上处理器负载太高 触发器表达式:{Zabbix server:system.cpu.load[percpu,avg1].avg(5m)}>5 告警等级:警告 2)Disk I/O is overloaded on {HOST.NAME} 磁盘I/O在{HOST.NAME}上重载 触发器表达式:{Zabbix server:system.cpu.util[,iowait].avg(1h)}>30 告警等级:警告 3){HOST.NAME} [CPU Idle]-[< 10%] CPU空闲小于百分之10 触发器表达式:{Zabbix server:system.cpu.util[,idle].count(#5,10,"lt")}=5 告警等级:一般严重 General触发器: 1)Hostname was changed on {HOST.NAME} 主机名被更改 触发器表达式:{Zabbix server:system.hostname.diff(0)}>0 告警等级:信息 2)Host information was changed on {HOST.NAME} 主机信息给更改 触发器表达式:{Zabbix server:system.uname.diff(0)}>0 告警等级:信息 3)HOST.NAME} has just been restarted 重新启动主机 触发器表达式:{Zabbix server:system.uptime.change(0)}<0 告警等级:信息 Keepalived触发器 1){HOST.NAME}keepalived进程宕机,请运维人员确认 触发器表达式:({TRIGGER.VALUE}=0 and {Zabbix server:proc.num[keepalived,,,keepalived].change(0)}<0 and {Zabbix server:proc.num[keepalived,,,keepalived].last(0)}=0) or ({TRIGGER.VALUE}=1 and {Zabbix server:proc.num[keepalived,,,keepalived].last(0)}<>3) 告警等级:严重 Memory触发器 1)Lack of free swap space on {HOST.NAME} 主机上缺少自由交换空间 触发器表达式:{Zabbix server:system.swap.size[,pfree].last(0)}<10 告警等级:警告 2)Lack of available memory on server {HOST.NAME} 主机服务器上缺少可用的内存 触发器表达式:{Zabbix server:vm.memory.size[available].last(0)}<20M 告警等级:一般严重 Security触发器 1)/etc/passwd has been changed on {HOST.NAME} 主机密码文件被更改 触发器表达式:{Zabbix server:vfs.file.cksum[/etc/passwd].diff(0)}>0 告警等级:警告 Processes触发器 1)Too many processes running on {HOST.NAME} 在主机上运行的进程太多 触发器表达式:{Zabbix server:proc.num[,,run].avg(5m)}>30 告警等级:警告 2)Too many processes on {HOST.NAME} 在主机上进程太多 触发器表达式:{Zabbix server:proc.num[].avg(5m)}>1000 告警等级:警告 Performace触发器 1)Processor load is too high on {HOST.NAME} 在主机上处理器负载过高(1分钟) 触发器表达式:{Zabbix server:system.cpu.load[percpu,avg1].avg(5m)}>5 告警等级:警告 OS触发器 1)Configured max number of processes is too low on {HOST.NAME} 主机上配置的最大进程数太低 触发器表达式:{Zabbix server:kernel.maxproc.last(0)}<256 告警等级:信息 2)Configured max number of opened files is too low on {HOST.NAME}

    02

    近期业务大量突增微服务性能优化总结-2.开发日志输出异常堆栈的过滤插件

    最近,业务增长的很迅猛,对于我们后台这块也是一个不小的挑战,这次遇到的核心业务接口的性能瓶颈,并不是单独的一个问题导致的,而是几个问题揉在一起:我们解决一个之后,发上线,之后发现还有另一个的性能瓶颈问题。这也是我经验不足,导致没能一下子定位解决;而我又对我们后台整个团队有着固执的自尊,不想通过大量水平扩容这种方式挺过压力高峰,导致线上连续几晚都出现了不同程度的问题,肯定对于我们的业务增长是有影响的。这也是我不成熟和要反思的地方。这系列文章主要记录下我们针对这次业务增长,对于我们后台微服务系统做的通用技术优化,针对业务流程和缓存的优化由于只适用于我们的业务,这里就不再赘述了。本系列会分为如下几篇:

    03
    领券