设置了应用程序池的内存限制，为什么内存使用能超过

1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的CPU监视，不超过25%（服务器为4CPU），每分钟刷新，超过限制时关闭。
根据w3wp取得是哪一个应用程序池：
1、在任务管理器中增加显示pid字段。就可以看到占用内存或者cpu最高的进程pid
2、在命令提示符下运行iisapp -a。注意，第一次运行，会提示没有js支持，点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。（iisapp实际上是存放在C:\windows\system32目录下的一个VBS脚本，全名为iisappvbs，如果你和我一样，也禁止了Vbs默认关联程序，那么就需要手动到该目录，先择打开方式，然后选“Microsoft （r） Windows Based Script Host”来执行，就可以得到PID与应用程序池的对应关系。）
3、到iis中察看该应用程序池对应的网站，就ok了，做出上面的内存或CPU方面的限制，或检查程序有无死循环之类的问题。
解决内存占用过多，可以做以下配置：
1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的回收时间，默认为1720小时，可以根据情况修改。再设置当内存占用超过多少（如500M），就自动回收内存。
我的设置如下：
首先是对CPU的限制：在启用cpu监视后，我设置该应用程序池最大的cpu使用率为50%。设置刷新cpu时间为1分钟，设置 *** 作为“关闭”。最大工作进程数设置为1。这个意思是，IIS刷新检测该独立池的CPU使用情况时间为1分钟，如果超过设置的cpu限制50％，就会发出关闭池的指令，要求池在指定的时间内关闭。如果池成功在这个时间内关闭，IIS会重启动一个新池，此段时间很短，一般不会有什么感觉，池就重新开启了，对于访问网站的人基本是不会有感觉的。但如果池没有在指定时间内关闭，IIS就会强行关闭它一个刷新CPU时间。在这个停止的时间内，网站无法访问，提示“Service Unavaliable”。
关闭时间和启动时间间隔设置：设短一些比如10秒，这样当您的网站程序大量占用系统资源时IIS自动快速回收进程并且快速启动进程，您的网站暂时还可以将就着工作。
对内存的限制及进程回收时间的设置：我设置为内存占用超过800M就自动回收内存，虚拟内存没有做限制。进程回收时间我保持默认没有修改。各位可以根据自己的情况设置更短的时间。对应用程序池最大虚拟内存也可以在此进行设置，超过了设置的最大虚拟内存，该池会就被回收。
最后综合落伍wlmmc的一些经验，总结一些需要注意的问题：
1、 要限制一个站点的CPU使用，必须将该站点设置为独立应用程序池，共用应用程序池是无法限制单个站点的。IIS独立应用程序池，就需要独立的进程，非常消耗内存。独立池越多，就有越多的W3WP进程。对于每个站点均要独立应用程序池的服务器，在一般的普通P430 2G内存 的普通服务器上，建议不要超过50个站点，最好30以内，不然服务器压力非常大。在配置上，我一般把资源消耗较大的网站独立一个池，一般普通BBS或者生成HTML的系统大概5个站一个池。普通网站以及一些企业站点均共用一个池。
2、根据wlmmc的经验，在服务器硬件允许的情况下，一般不要限制站点内存使用，这样能够保证网站运行，不会出现用户掉线情况。需要限制某站的最大虚拟内存不要小于64M，不然可能出现一些未知的错误。
3、这些都不是根本解决办法，它的根本问题是网站程序有问题，要解决根本问题还要从程序查起。根据本文开头提到的方法查到具体的应用程序池，找到使用此应用程序池的网站，解决网站程序存在的问题，如死循环之类。
4、除了w3wpexe, 在调用数据库进行大量查询 *** 作的时候，也会大量占用CPU资源，这是难免的（数据库方面的语句及结构优化不在本文讨论范围之内）。个人认为，只要不是CPU长时间占用100%， 一般在75%左右都是正常的。

内存溢出（out of memory）
是指程序在申请内存时，没有足够的内存空间供其使用。
内存泄漏（memory leak）
是指程序在申请内存后，无法释放已申请的内存空间，占用有用内存。
注：内存泄漏最终会导致内存溢出
简单理解，内存溢出就是要求分配的内存超出了系统所给的。内存泄漏是指向系统申请分配内存进行使用（new），但是用完后不归还（delete），导致占用有效内存。
内存泄漏可分为4类：
1常发性内存泄漏
引起内存泄漏的代码会被很多次执行，每次执行的时候都会导致内存泄漏
2偶发性内存泄漏
在某些特定的环境下执行引起内存泄漏的代码，才会引起内存泄漏
从以上两种内存泄漏的方式来看，测试环境和测试方法在程序生命周期的重要性是不可或缺的。
3一次性内存泄漏
代码只会执行一次，但总有一块内存发生泄漏，多见于构造类的时候，析构函数没有释放内存。
4隐式泄漏
程序运行过程中不断的分配内存，直到结束时才释放内存，但一般服务器程序会运行较长的时间，不及时释放也会导致内存耗尽以至于内存泄漏。
综上所述，一次性内存泄漏对用户的程序维护是没有什么实质性的伤害，但在实际生活中，我们还是尽可能要避免此类的事件发生。
内存越界
是指向系统申请一块内存后，使用时却超出申请范围。比如一些 *** 作内存的函数：sprintf、strcpy、strcat、vsprintf、memcpy、memset、memmove。当造成内存泄漏的代码运行时，所带来的错误是无法避免的，通常会造成
1破坏了堆中内存内存分配信息数据
2破坏了程序其他对象的内存空间
3破坏了空闲内存块
附：如果在之前你的程序运行一切正常，但因为你新增了几个类的成员变量或者修改了一部分代码（前提是保证你的这些修改是完全正确的）而导致程序发生错误，则因考虑是否是内存被破坏的原因了，重点排查内存是否越界。
缓冲区溢出（栈溢出）
程序为了临时存取数据的需要，一般会分配一些内存空间称为缓冲区。如果向缓冲区中写入缓冲区无法容纳的数据，机会造成缓冲区以外的存储单元被改写，称为缓冲区溢出。而栈溢出是缓冲区溢出的一种，原理也是相同的。分为上溢出和下溢出。其中，上溢出是指栈满而又向其增加新的数据，导致数据溢出；下溢出是指空栈而又进行删除 *** 作等，导致空间溢出。

下面我们就来实战如何限制MSSQL内存使用:
第一步:打开企业管理器双击进入要修改的MSSQL
第二步:在左侧MSSQL上点击右键,选择属性,d出SQL Server属性(配置)对话框(最好打上SQL SP4补丁）
第三步:点击内存选项卡 在这里,你会看到MSSQL默认设置为使用最大内存,也就是你所有的内存,根据你的需要,设置它的最大值(一般为物理内存-128M)和最小值(一般为最大内存的1/4)吧
第五步:设置完毕,重启MSSQL服务,配置即可生效!

32G的手机内存卡，只能存不到8G的东西就不能存了，有以下几种可能：
1、买到了扩容卡。也就是说，这个卡实际上是8G的，但被扩容到16G以上销售。因为实际容量是8G，所以，超过8G的部分是假的，当然就不能保存文件了。存了文件也拷贝不出来。
2、读卡器或手机有问题。比如手机不能识别大容量的内存卡，或者读卡器太老不能识别大容量的存储卡。这也是有可能的。
3、如果是保存单个文件大于4G的文件，会提示空间不足。这是因为手机内存卡多数是FAT32的文件系统，这个文件系统的限制就是单个文件不能大于4GB。格成NTFS或EXFAT即可解决。

众所周知，java在处理数据量比较大的时候，加载到内存必然会导致内存溢出，而在一些数据处理中我们不得不去处理海量数据，在做数据处理中，我们常见的手段是分解，压缩，并行，临时文件等方法;例如，我们要将数据库(不论是什么数据库)的数据导出到一个文件，一般是Excel或文本格式的CSV;对于Excel来讲，对于POI和JXL的接口，你很多时候没有法去控制内存什么时候向磁盘写入，很恶心，而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数，所以你不得不去拆分Excel，还好，POI开始意识到这个问题，在384的版本后，开始提供cache的行数，提供了SXSSFWorkbook的接口，可以设置在内存中的行数，不过可惜的是，他当你超过这个行数，每添加一行，它就将相对行数前面的一行写入磁盘(如你设置2000行的话，当你写第20001行的时候，他会将第一行写入磁盘)，其实这个时候他些的临时文件，以至于不消耗内存，不过这样你会发现，刷磁盘的频率会非常高，我们的确不想这样，因为我们想让他达到一个范围一次性将数据刷如磁盘，比如一次刷1M之类的做法，可惜现在还没有这种API，很痛苦，我自己做过测试，通过写小的Excel比使用目前提供刷磁盘的API来写大文件，效率要高一些，而且这样如果访问的人稍微多一些磁盘IO可能会扛不住，因为IO资源是非常有限的，所以还是拆文件才是上策;而当我们写CSV，也就是文本类型的文件，我们很多时候是可以自己控制的，不过你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式写入即可被CSV识别出来;如何写入呢？下面来说说。。。在处理数据层面，如从数据库中读取数据，生成本地文件，写代码为了方便，我们未必要1M怎么来处理，这个交给底层的驱动程序去拆分，对于我们的程序来讲我们认为它是连续写即可;我们比如想将一个1000W数据的数据库表，导出到文件;此时，你要么进行分页，oracle当然用三层包装即可，mysql用limit，不过分页每次都会新的查询，而且随着翻页，会越来越慢，其实我们想拿到一个句柄，然后向下游动，编译一部分数据(如10000行)将写文件一次(写文件细节不多说了，这个是最基本的)，需要注意的时候每次buffer的数据，在用outputstream写入的时候，最好flush一下，将缓冲区清空下;接下来，执行一个没有where条件的SQL，会不会将内存撑爆？是的，这个问题我们值得去思考下，通过API发现可以对SQL进行一些 *** 作，例如，通过：PreparedStatementstatement=connectionprepareStatement(sql)，这是默认得到的预编译，还可以通过设置：PreparedStatementstatement=connectionprepareStatement(sql，ResultSetTYPE_FORWARD_ONLY，ResultSetCONCUR_READ_ONLY);来设置游标的方式，以至于游标不是将数据直接cache到本地内存，然后通过设置statementsetFetchSize(200);设置游标每次遍历的大小;OK，这个其实我用过，oracle用了和没用没区别，因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的，而mysql里头设置根本无效，我上面说了一堆废话，呵呵，我只是想说，java提供的标准API也未必有效，很多时候要看厂商的实现机制，还有这个设置是很多网上说有效的，但是这纯属抄袭;对于oracle上面说了不用关心，他本身就不是cache到内存，所以java内存不会导致什么问题，如果是mysql，首先必须使用5以上的版本，然后在连接参数上加上useCursorFetch=true这个参数，至于游标大小可以通过连接参数上加上：defaultFetchSize=1000来设置，例如：jdbc：mysql：//xxxxxxxxxxxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀，并行2个直接系统就宕了)，还去看了很多源码才发现奇迹竟然在这里，最后经过mysql文档的确认，然后进行测试，并行多个，而且数据量都是500W以上的，都不会导致内存膨胀，GC一切正常，这个问题终于完结了。我们再聊聊其他的，数据拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，还好，这个在我们可控制的范围内，如果文件中的数据最终是可以组织的，那么在拆分和合并的时候，此时就不要按照数据逻辑行数来做了，因为行数最终你需要解释数据本身来判定，但是只是做拆分是没有必要的，你需要的是做二进制处理，在这个二进制处理过程，你要注意了，和平时read文件不要使用一样的方式，平时大多对一个文件读取只是用一次read *** 作，如果对于大文件内存肯定直接挂掉了，不用多说，你此时因该每次读取一个可控范围的数据，read方法提供了重载的offset和length的范围，这个在循环过程中自己可以计算出来，写入大文件和上面一样，不要读取到一定程序就要通过写入流flush到磁盘;其实对于小数据量的处理在现代的NIO技术的中也有用到，例如多个终端同时请求一个大文件下载，例如视频下载吧，在常规的情况下，如果用java的容器来处理，一般会发生两种情况：其一为内存溢出，因为每个请求都要加载一个文件大小的内存甚至于，因为java包装的时候会产生很多其他的内存开销，如果使用二进制会产生得少一些，而且在经过输入输出流的过程中还会经历几次内存拷贝，当然如果有你类似nginx之类的中间件，那么你可以通过send_file模式发送出去，但是如果你要用程序来处理的时候，内存除非你足够大，但是java内存再大也会有GC的时候，如果你内存真的很大，GC的时候死定了，当然这个地方也可以考虑自己通过直接内存的调用和释放来实现，不过要求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率;其二为假如内存足够大，无限制大，那么此时的限制就是线程，传统的IO模型是线程是一个请求一个线程，这个线程从主线程从线程池中分配后，就开始工作，经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程线程都是被挂住的，所以这部分资源非常有限，而且如果是大文件 *** 作是属于IO密集型的 *** 作，大量的CPU时间是空余的，方法最直接当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般来讲一个进程的线程池一般会受到限制也不建议太多的，而在有限的系统资源下，要提高性能，我们开始有了newIO技术，也就是NIO技术，新版的里面又有了AIO技术，NIO只能算是异步IO，但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程，但是不会去关心中途的响应)，还未做到真正的异步IO，在监听connect的时候他是不需要很多线程参与的，有单独的线程去处理，连接也又传统的socket变成了selector，对于不需要进行数据处理的是无需分配线程处理的;而AIO通过了一种所谓的回调注册来完成，当然还需要OS的支持，当会掉的时候会去分配线程，目前还不是很成熟，性能最多和NIO吃平，不过随着技术发展，AIO必然会超越NIO，目前谷歌V8虚拟机引擎所驱动的nodejs就是类似的模式，有关这种技术不是本文的说明重点;将上面两者结合起来就是要解决大文件，还要并行度，最土的方法是将文件每次请求的大小降低到一定程度，如8K(这个大小是经过测试后网络传输较为适宜的大小，本地读取文件并不需要这么小)，如果再做深入一些，可以做一定程度的cache，将多个请求的一样的文件，cache在内存或分布式缓存中，你不用将整个文件cache在内存中，将近期使用的cache几秒左右即可，或你可以采用一些热点的算法来配合;类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样)，它在处理下载数据的时候未必是连续的，只要最终能合并即可，在服务器端可以反过来，谁正好需要这块的数据，就给它就可以;才用NIO后，可以支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时请求一个线程的服务器，正常的WEB应用是第一个文件没有发送完成，第二个请求要么等待，要么超时，要么直接拒绝得不到连接，改成NIO后此时100个请求都能连接上服务器端，服务端只需要1个线程来处理数据就可以，将很多数据传递给这些连接请求资源，每次读取一部分数据传递出去，不过可以计算的是，在总体长连接传输过程中总体效率并不会提升，只是相对相应和所开销的内存得到量化控制，这就是技术的魅力，也许不要太多的算法，不过你得懂他。类似的数据处理还有很多，有些时候还会将就效率问题，比如在HBase的文件拆分和合并过程中，要不影响线上业务是比较难的事情，很多问题值得我们去研究场景，因为不同的场景有不同的方法去解决，但是大同小异，明白思想和方法，明白内存和体系架构，明白你所面临的是沈阳的场景，只是细节上改变可以带来惊人的效果。

---