1、先查看CGI-BIN文件夹下面是否有文件存在，如果没有就上传一个上去。
2、如上传完毕后无法访问执行如下命令进入HOST内查看。
tail /etc/httpd/conf/httpd.conf 查找配置文件
vim /etc/httpd/conf/bizcnnewvhost.conf 进入主机配置文件
more
报错 Option FollowSymLinks not allowe
果错误日志中出现上述提示，请添加以下代码至您的.htaccess文件中：
Options +SymLinksIfOwnerMatch
如果有必要也请注释掉以下代码：
Options +FollowSymLinks
more
在没有找到解决方法之前，我一直在想，php最近虽然慢了点，但至少能运行，说明配置是没有问题；而且，如果现在执行phpinfo()，程序依然能够执行。我再次梳理出错规律，发觉include多的mvc框架就会提示500内部错误。其它简单的程序就能够运行。这说明什么？！说明php已经不能include文件了，为什么？只能是请求这些资源时动了临时文件，而临时文件没有多余空间了。
运行
df -h
发觉果然如此
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 6.8G 6.5G 17M 100% /
…
系统主目录/下已经爆掉了。
于是，查找大文件
find / -type f -size +300M
发觉php插件Xdebug产生了很多性能分析文件，而且都是以100M记。
/tmp/profiler/cachegrind.out.1336
/tmp/profiler/cachegrind.out.1329
….
于是修改php.ini，将分析文件存放在其它地方，或者干脆不保存。
# close xdebug profiler in php.ini
xdebug.profiler_enable = off
再删除xdebug性能分析目录和php var跟踪目录
rm -rf /tmp/profilter
rm -rf /tmp/trace
再次查看硬盘情况，发觉已使用为26%，剩余4.9G。
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 6.8G 1.7G 4.9M 26% /
…
甚至不用重启httpd服务器，刷新web，又正常运行了！！！
为免除后患，我们需要安装一个定时清理软件–tmpwatch，设置/etc/cron.daily/tmpwatch配置里面的定时时间
usr/sbin/tmpwatch “$flags” 30d /var/tmp
改为7d（必须以天为单位）
usr/sbin/tmpwatch “$flags” 7d /var/tmp
一个星期定时清理一次。
df -h
more
转载请注明：(●--●) Hello.My Weicot » linux 500 错误排除