来源: 互联网  发布时间: 2013-12-24

在Apache中, 当不加配置的时候, 对于PHP脚本, AcceptPathInfo是默认接受的, 也就是说:

如果在服务器在存在一个/laruence/index.php

那么, 对于如下请求,

Apache都接受, 都会认为是对info.php的访问, 并会设置PATH_INFO为dummy

而对于Nginx下, 是不支持PATH INFO的, 也就是它不会默认设置PATH_INFO.

而因为默认的配置文件对PHP的支持只是很基础的, 所以对于默认配置来说对于上面的访问也会是404, 提示找不到文件出错.

这对于一些使用PATH_INFO来传递关键信息的PHP框架来说(比如Kohana, Thinkphp), 简直是致命的.

对于这个问题, 一般来说有俩种解决方法, 第一种就是使用rewrite, 但是这个方法的缺点也是很明显的, 需要把PATH_INFO转换成Query String. 此处就不说明这种方法了~

而, 第二种方法就是我今天要提的, 模拟PATH_INFO:

首先 , 我们知道在Nginx中, 是通过对文件名的扩展名匹配, 来决定是否要交给php cgi服务器去解释的. 在nginx.conf中一般都有如下的默认配置段:

所以,对于形如/laruence/info.php/pathinfo这样的文件路径, Nginx是不会正确的交给php cgi服务器的. 所以我们需要改写这段配置为:

现在, 脚本路径已经交由PHP自己处理了. 那怎么增加PATH_INFO呢?

首先, 我们需要打开PHP中cgi.fix_pathinfo配置项, 打开这个配置项以后, PHP会去根据CGI规范来检查SCRIPT_FILENAME中那部分是访问脚本和PATH_INFO(ini配置解释), 并根据SCRIPT_NAME来修改PATH_INFO(和PATH_TRANSLATED)为正确的值(其实也就是说明, PHP最初对CGI 1.1的支持并不到位)

然后, 就只要添加一个FASTCGI_PARAM项就好了:

现在试试吧…

btw: 当然, 上面的解决方法, 把对路径的分析交给了PHP去处理, 网上也有朋友给出了另外一种配置方法, 这个方法是由Nginx来分析路径(也就不需要fix_pathinfo):

后记, 最近发现的一个安全漏洞(Nginx + PHP CGI的一个可能的安全漏洞)和这个配置有关系, 请大家务必在使用第二种配置的时候,关闭cgi.fix_pathinfo. 另外关于这个漏洞我个人认为这个和Nginx没啥关系, 不属于Nginx的漏洞. 是配置的问题, 现在到处都在说是Nginx的Bug, 不妥不妥.

    

    来源: 互联网  发布时间: 2013-12-24

IIS卸载后重装时提示：

---------------------------
Windows 安装程序
---------------------------
安装程序无法复制一个或多个文件。特定错误码是 0xe0000233。按“确定”以继续；或者按“取消”，停止安装并且再试一次。如果继续，组件可能无法正常运行。
---------------------------
确定 取消
---------------------------

网上找的解决办法都是说没有删除干净，不过服务里iisadmin也没有了。进程里也没有，是删除干净了。服务器重启还是不行，最终我的解决办法是：

C:Inetpub 权限给everyone完全控制。OK，成功安装。

安装程序无法复制一个或多个文件。特定

错误码是 0xe0000233。按“确定”以继续；或者

按“取消”，停止安装并且再试一次。如果继续，

组件可能无法正常运行。

解决办法：

1.打开C/:Inetpub/AdminScripts，如果是上图的结果，那么服务器应该是做安全了。

2.在文件夹右键属性-安全，加入everyone 完全控制权限，在重新安装iis，问题解决。

不过安装到中间的时候又出现了这个提示，那么就可以推算可能是c盘的安全设置导致权限问题。
执行如下命令即可：
将C盘NTFS权限还原为默认命令

    

    来源: 互联网  发布时间: 2013-12-24

解决CPU占用过多：

1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。

2、设置应用程序池的CPU监视，不超过25%（服务器为4CPU），每分钟刷新，超过限制时关闭。

根据w3wp取得是哪一个应用程序池：

1、在任务管理器中增加显示pid字段。就可以看到占用内存或者cpu最高的进程pid

2、在命令提示符下运行iisapp -a。注意，第一次运行，会提示没有js支持，点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。（iisapp实际上是存放在 C:windowssystem32目录下的一个VBS脚本，全名为iisapp.vbs，如果你和我一样，也禁止了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进程。对于每个站点均要独立应用程序池的服务器，在一般的普通P43.0 2G内存的普通服务器上，建议不要超过50个站点，最好30以内，不然服务器压力非常大。在配置上，我一般把资源消耗较大的网站独立一个池，一般普通BBS或者生成HTML的系统大概5个站一个池。普通网站以及一些企业站点均共用一个池。

2、根据wlmmc的经验，在服务器硬件允许的情况下，一般不要限制站点内存使用，这样能够保证网站运行，不会出现用户掉线情况。需要限制某站的最大虚拟内存不要小于64M，不然可能出现一些未知的错误。

3、这些都不是根本解决办法，它的根本问题是网站程序有问题，要解决根本问题还要从程序查起。根据本文开头提到的方法查到具体的应用程序池，找到使用此应用程序池的网站，解决网站程序存在的问题，如死循环之类。

4、除了w3wp.exe, 在调用数据库进行大量查询操作的时候，也会大量占用CPU资源，这是难免的（数据库方面的语句及结构优化不在本文讨论范围之内）。个人认为，只要不是CPU长时间占用100%， 一般在75%左右都是正常的。

服务器正常运行CUP一般应该都在60%以下,有时候CUP出现上下波动很大,或者是服务器突然很卡,或很慢.查看任务管理器,可以发现很多的w3wp.exe消耗CPU,结束后立即有新的w3wp.exe出现占CPU,管管理员在这种情况.只好重新启动IIS服务，奇怪的是，重新启动IIS服务后一切正常，但可能过了一段时间后，问题又再次出现了。

直接原因：

有一个或多个ACCESS数据库在多次读写过程中损坏，微软的MDAC系统在写入这个损坏的ACCESS文件时，ASP线程处于BLOCK状态，结果其他线程只能等待，IIS被死锁了，全部的CPU时间都消耗在w3wp.exe中。

解决办法：1

在iis管理器里面设置多个应用程序池， 并把虚拟主机站点分别加入应用程序池。在多应用程序池的情况下，每个应用程序池会对应生成一个w3wp.exe文件。通过任务管理器可以查看到所有w3wp.exe占用cpu利用率情况。 通过iis管理器打开应用程序池，可以逐个停掉应用程序池。一边停应用程序池，一边在任务管理器里面观察哪个w3wp.exe的cpu利用率一下子从降下来，cpu利用率恢复正常。这样可以判断是那个应用程序池出了问题。然后可以再建立多个应用程序池，每一个应用程序池对应一个站点。这样逐个停应用程序池，就可以确定到底是哪个网站出问题。最有问题的往往是计数器类的ACCESS文件，例如：“**COUNT.MDB” ，“*COUNT.ASP”，找到这个文件后，可以删除它，或下载下来，用ACCESS2000修复它，问题就解决。

解决办法：2

w3wp.exe占用cpu过高查询方法,很多web提供商最头疼的问题,在任务管理器经常出现w3wp.exe占cup过高,导致整台服务器受影响.解决办法如下:

1.先把任务管理器打开,发现那个w3wp.exe占cup关高就结束进程

2.在我的电脑-管理-事件查看器-系统-会找到关w3wp.exe的错误报告,把程序池名字记录下,再把具体时间记录下来.(如12.59.56).

3.在到系统上面的安全性.找到对应时间(如12.59.56)登陆过的用户.

4.打开iis找到2中查询到的程序池,和3查询到登陆过的用户,取交集,即可精确查到是那个web占点站cup。