设置 GDIProcessHandleQuota项设置GDI句柄数量,默认值为2710(16进制)/10000(10进制),该值的允许范围为 256 ~ 16384 ,将其调整为大于默认的10000的值.如果您的系统配置了2G或更多内容,不妨将其设置为允许的最大值 16384(10进制): USERProcessHandleQuota项设置用户句柄数量,默认值同样为2710(16进制)/10000(10进制),该值的允许范围为 200 ~ 18000 ,将其调整为更多的数值.同样地,对于具有2G

在Windows下安装MySQL ,用了官方的配置向导生成了my.ini,本以为很安稳了,谁知十多个小时过去之后,系统响应非常慢,看资源管理器的性能卡,发现句柄数竟然达到了10万!怪不得无论使用什么程序都卡得很.网上搜索一下,大概是说 innodb_buffer_pool_size 这个默认的8M太大,但我已经skip-innodb了啊.后来又看到一个设置innodb_flush_log_at_trx_commit innodb_flush_log_at_trx_commit  (这个很管用)抱

作为程序员,开发程序是基本功,而调试程序也是必不可少的技能之一.软件在主体功能开发完成后会经历各个阶段的测试,才会被发布.在测试过程中,出现较多的可能就是内存泄漏,句柄泄漏,异常崩溃等属于非功能型的软件Bug.而Windows作为一个相当成熟的平台,对于软件的调试也支持很到位.今天想要记录的是这次调查的一个模块的句柄泄漏问题. 关于句柄泄漏的文章网上很多,很多关于调试的书籍中也有说明,而且有些也比较详细.之前也解决过这类的问题,所以毫不在意.先介绍一下基本情况:工作机是Windows 7 64b

最近一二个月以来,我发现服务器的内存占用正按着每天60M的速度增加. 一台windows 2003的服务器(2G内存),刚刚启起时占用内存:600M左右. 运行20天后,内存占用(PF使用):1.8G 其实物理内存使用情况在这20天来并没有太大的变化,但虚拟内存占用明显在不停的增加. 我通过“任务管理器”一直也找不到是哪个进程占用的这么多的内存. 也许是因为“任务管理器”里显示的内存占用仅代表的是“物理内存占用”吧. 今天对比服务器上和本地电脑上的“任务管理器”的显示情况,偶然发现它们之前的一个

写在前面:这里介绍句柄 对于“句柄”,在下一直停留在一知半解的认识层面,近日在下学习Windows编程,决定趁此机会将句柄彻底搞清楚.查阅了一些网络上的资料,发现网络上的讲解大概可以分为两类:一种是以比喻.类比的方式说明,这种方法虽然形象易懂,但并没有从原理上.本质上加以揭示,让人仍然想问“为什么?”.“怎么实现?”.另一种是给出源代码,无可厚非,这当然是最本质的说明了,但这样一来,又显得不够直观,初学者理解起来有一定的难度.鉴于此,在下尽微末之能,结合自己的愚见,在两者之间折中,用图解的方式来

脚本监控: 获取最大句柄数的进程: 链接分析: 脚本片段: case "$handle" in 2) echo "The handle of the process : " echo " " handle | awk '{print $3 "\n" $5 "\n" $7 "\n" $9 "\n" $11 "\n"}' > temp for i

---查看系统默认的最大文件句柄数,系统默认是1024 # ulimit -n 1024 ----查看当前进程打开了多少句柄数 # lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr|more 131 24204 57 24244 57 24231  ........ 其中第一列是打开的句柄数,第二列是进程ID. 可以根据ID号来查看进程名. # ps aef|grep 24204 nginx 24204 24162 99 16:15 ? 00:24:2

windows 端口链接数  查看有效 链接数: netstat -an|find " |find "ESTABLISHED" /c /c 统计: 查看链接信息: 查看当前 IP 的80 链接netstat -an |find "172.0.0.1:80" /c

这几天在做一个性能测试,写了一个模拟发送http的程序.模拟100并发的情况下,随机发http get的请求.放到服务器上运行一段时间抛出Too many open files的异常. 这几天在做一个性能测试,写了一个模拟发送http的程序.模拟100并发的情况下,随机发http get的请求.放到服务器上运行一段时间抛出Too many open files的异常. 异常信息简单的信息如下: I/O exception (java.net.SocketException) caught whe

句柄只是用来标识应用程序中的不同对象和同类中的不同的实例的一个数字,通常情况下,句柄值对普通用户毫无用处,但是句柄数量却可以间接反映出一个程序里产生的对象实例的多少.句柄数越多,代表程序里new 出来的对象越多.但是在c#里,经常会遇到句柄数莫名其妙的增加. DateTime lastTime1 = DateTime.Now.AddHours(); while (true) { var a = lastTime1 - DateTime.Now; ) { break; } //DoSomethin

https://github.com/alibaba/p3c/blob/master/阿里巴巴Java开发手册(详尽版).pdf 2. [推荐]调大服务器所支持的最大文件句柄数(File Descriptor,简写为 fd). 说明:主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理,即一个连接对 应于一个 fd.主流的 linux 服务器默认所支持最大 fd 数量为 1024,当并发连接数很大时很 阿里巴巴 Java 开发手册 34/38 容易因为 fd 不足而出现“ope

RedHat对进程打开文件句柄数主要通过设置全局值和登陆用户分别管理.其中/proc/sys/fs下设置全局最大文件句柄数和用户进程能打开的最大文件句柄数,这两个参数一般情况下不需要修改. 对于普通用户或者进程通过/etc/security/limits.conf和/etc/security/limits.d/*.conf进行管理.或者通过ulimit 命令进行设置,但通过ulimit设置只对当前shell启动的进程有效.两者的设置生效范围和设置时机不同,详见三 操作系统limits.conf生

     win2003的话可以从组策略修改: 组策略级别要高于终端服务配置,当启用组策略后终端服务配置中的相应选项会变成灰色不可修改 运行-gpedit.msc-计算机配置-管理模板-Windows组件-终端服务 双击右边的”限制连接数量“-选择”已启用“-填入允许的最大连接数

linux服务器大并发调优时,往往需要预先调优linux参数,其中修改linux最大文件句柄数是最常修改的参数之一. 在linux中执行ulimit -a 即可查询linux相关的参数,如下所示: [root@mongodb11 ~]# ulimit -acore file size          (blocks, -c) 0data seg size           (kbytes, -d) unlimitedscheduling priority             (-e) 0

1.cat /etc/security/limits.confwebuser soft nofile 65535webuser hard nofile 65535webuser soft nproc 65535webuser hard nproc 65535 2.cat /etc/sysctl.confkernel.pid_max = 65535 sysctl -p 3.cat /proc/sys/kernel/pid_max或sysctl kernel.pid_max 实际值 4.cat /p

在.NET编程中,得益于有效的内存管理机制,对象的创建和使用比较方便,大多数情况下我们无须关心对象创建和分配内存的细节,也可以放心的把对象的清理交给自动垃圾回收来完成.由于.NET类库对系统底层对象进行了封装,我们也不需要调用Windows API来操作非托管对象.但不直接操作非托管对象,并不意味着程序不会间接创建这些对象,如果不了解.NET对象与非托管资源的关系,我们很有可能因为不恰当的使用这些托管对象,而导致非托管资源泄露.本文尝试说明Windows对象和句柄的基本概念,以及.NET编程中的

图解说明——究竟什么是Windows句柄 参考资料:http://blog.csdn.net/newjerryj/article/details/4383701 http://www.cnblogs.com/yellowyu/archive/2009/06/07/1497910.html 写在前面: 对于“句柄”,在下一直停留在一知半解的认识层面,近日在下学习Windows编程,决定趁此机会将句柄彻底搞清楚.查阅了一些网络上的资料,发现网络上的讲解大概可以分为两类:一种是以比喻.类比的方式说明,

在上篇文章.NET对象与Windows句柄(二):句柄分类和.NET句柄泄露的例子中,我们有一个句柄泄露的例子.例子中多次创建和Dispose了DataReceiver和DataAnalyzer对象,但由于忘记调用DataAnalyzer的Stop方法,导致产生句柄泄露.本文假定我们已经发现了泄露现象但还不知道原因,讨论如何在这种情况下分析问题. 一.发现问题 在程序运行约一个小时以后,通过任务管理器发现句柄数超过5000,线程数也超过1000.对于一段只需要并行接收和分析数据的简易代码来说,这

上一篇文章介绍了句柄的基本概念,也描述了C#中创建文件句柄的过程.我们已经知道句柄代表Windows内部对象,文件对象就是其中一种,但显然系统中还有更多其它类型的对象.本文将简单介绍Windows对象的分类. 句柄可以代表的Windows对象分为三类,内核对象(Kernel Object).用户对象(GDI Object)和GDI对象,上一篇文章中任务管理器中的“句柄数”.“用户对象”和“GDI对象”计数就是与这几类对象对应的.为什么要这样分类呢?原因就在于这几类对象对于操作系统而言有不同的作用

谈windows中的句柄   每当一个进程打开一个对象,系统就返回一个句柄作为凭证,由此可以想到,句柄是依赖于具体的进程的,换句话说,句柄一定属于某个进程,以后在访问这个对象时就要使用这个凭证!     所以句柄还可以认为是一个进程和一个对象之间建立的一种连接,一座桥梁,一个上下文,就像一个门一样,已经打开.这种连接就持续存在,直到关闭. 一个进程可打开对个对象,就会拥有多个句柄,所以每个进程都拥有一个句柄表,在进程控制块EPROCESS中有个指针ObjectTable是_HANDLE_TABL