各位老铁们，大家好，今天由我来为大家分享服务器老了，以及服务器老化是什么意思的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
一、服务器老是慢怎么回事,怎么解决呢易采办
这种情况我们先要利用cmd的命令查看一下当前服务器的ip在传递信息的时候是不是有掉包的现象，有的话那我们就要去看全国的的线路是不是正常的，要是全国的线路都是正常的话，那说明我们本地的线路节点有问题了。遇到这种情况很好解决。
第一，要是本地是拨号上网的话，可以重启启动一下路由器或者拨号上网使用的猫，换一个本地的ip，并且使用ping命令进行监视，这样的话我们能找到一个很不错的本地的ip也就是说我们的这个ip在连接的时候没有出现掉包的现象的话说明我们选择的ip走的线路节点是稳定的。
第二步，ip在本地ping是正常的话，但是到了服务器里面还是卡的厉害的话，我们可以看一下自己的cpu使用情况和内存的使用情况，一般当自己的服务器的内存和cpu资源不够用的时候会出现服务器卡等一系列问题，遇到这样的情况，
1.做的就是清理一下自己的服务器内的垃圾文件，和关闭一些不需要的程序，服务器要是vps的话建议不要安装一些占用大量内存和cpu的软件，还有vps里面不要建设大量的网站。还有就是看看自己的服务器中是不是有的补丁没有打，有的话把自己服务器中的补丁打好之后重启启动一下您的服务器。
2.服务器卡的还有一个原因就是因为服务器本身的系统问题，其实服务器就和我们的电脑是一个道理，当自己电脑上的系统长时间使用，也会出现电脑运转慢，或者是卡机的现象，这时候我们需要做的工作就是及时的备份自己的数据，然后从装一下自己的系统。
3.另外也不排除服务器自身的问题。有时候一台母鸡中的vps服务器有大量的服务器的cpu占用很高，占用的大量的母鸡的cpu也能导致服务器运行慢或者卡死。这个时候我们要做的就是及时联系服务器提供商，让他们检查一下是不是自己服务器所在的母鸡中有服务器占用了母鸡中的大量的资源。如果有的话让他们及时关闭占用资源多的服务器。
4.还有可能就是服务器本身的配置问题了，当你的服务器中的网站数量多的时候，服务器的内存或者cpu不能满足他们自身的运行，就很容易导致卡机，这个时候我们就应该升级一下自己的服务器的配置，或者购买一个高配置的服务器来运行自己的网站。
如果站多的话我还是建议各位站长购买独立服务器，因为独立服务器是和vps是分开的，他们是实体而不是虚拟的。不会受到其他机器的影响。
综合来说服务器卡，多数还是和线路结点有关系，如果国内的线路结点不稳定，很容易导致服务器卡，但是国内的线路节点抽风是不可预知的。也没有好的方法和方式去解决，只能等国内的线路节点恢复正常。
因为服务器的提供商是不可能去解决线路节点的问题的，因为这个不是在他们的能力范围之内。
二、服务器老化是什么意思
服务器老化是服务器配置落后了的意思。
服务器部件一般使用寿命为3~5年，不同厂商的电源基本上差不多，通常服务器购买会有三年保修，三年内出故障几率较低。如果新手暂时不会改端口，千万不要在服务器上试，否则将面临重启服务器后再也进不去的情况。
服务器使用注意：
如果没有安装补丁或者杀*软件，在服务器上浏览网页将可能使服务器感染*或者病*。在服务器上运行没有用过的程序也有同样的危险，或者有可能导致服务器上的默认设置被改变。杜绝非服务器管理人员对机房的进入以及操作访问平台。
三、服务器老是出现停止错误,然后意外关闭,请问各位大侠怎么解决
可能的原因：
一、内存错误
二、某个定时的服务引起死锁
三、病*残留或者*攻击
四、诺顿的文件检查功能
检查及处理过程：
一、由于这是第一次出现类似重启，先不考虑硬件故障。但内存错误仍有另外一个可能*就是对磁盘上的虚拟内存访问出错。先检查虚拟内存所在磁盘，未发现错误。但磁盘中有比较多的文件碎片，考虑到内存文件过于分散有可能会引起偶尔的读错误。所以在凌晨1时左右进行一次全盘的文件碎片整理。
二、根据原因代码，网络上有关于定时服务引起文件死锁的记录，而查询登录日志，离重启最近的访问来自于另一台服务器B，加上出现故障时间与整点比较接近，有可能与某些系统服务有关，所以，将B中的DNS、DHCP等服务关闭，因为这些服务会与故障服务器通讯同步，或者进行某种查询。更进一步地，将服务器和B服务器上的文件跨网络定时复制备份等功能删除。
三、从微软的网站找到有关病*也会引发类似故障的说明（相关网址），按说明查询后排除可能*，然后，再检查可疑的设备驱动，也未发现任何可疑之处。另外，通过查询防火墙日志，在19：03前也未发现有异常的攻击事件。
四、通过网络上上报的事故报告（相关网址）中提到Symantec的版本有关，在Symantec的技术支持网站看到相类似的报告。考虑到离最近的故障时间登录者是B服务器，而我们的B服务器上恰恰安装了Symantec的10.0版，怀疑与故障服务器上的9.0版在升级病*库时产生了冲突，所以将B上的Symantec杀*软件删除，然后安装了一个客户端，由故障服务器统一管理。
进一步分析
用WinDbg对系统崩溃时的内存Dump文件分析，发现系统重启时的引发文件为RapDrv.sys。
这个文件为BlackICE的系统文件，它包括了监视应用程序的变化的相关模块，可参见BlackICE的在线说明
检查RapDrv.sys，文件没有被改变的迹象，可排除被*和病*修改文件的可能*。
对Dump文件进行调试，找到RapDrv.sys出错时的堆栈情况，具体内容如下：
EXCEPTION_CODE:(NTSTATUS) 0xc0000005-"0x%08lx""0x%08lx""%s"
FAULTING_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
TRAP_FRAME: f4c0bb54--(.trap fffffffff4c0bb54)
ErrCode= 00000002
eax=858b8b4c ebx=00000000 ecx=00000000 edx=00000000 esi=858b5000 edi=84e2660c
eip=f535e785 esp=f4c0bbc8 ebp=f4c0bbdc iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
RapDrv+0x9785:
f535e785 894104 mov dword ptr [ecx+4],eax ds:0023:00000004=????????
Resetting default scope
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: blackice.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be
STACK_TEXT:
f4c0b720 8085b4b3 0000008e c0000005 f535e785 nt!KeBugCheckEx+0x1b
f4c0bae4 808357a4 f4c0bb00 00000000 f4c0bb54 nt!KiDispatchException+0x3a2
f4c0bb4c 80835758 f4c0bbdc f535e785 badb0d00 nt!CommonDispatchException+0x4a
f4c0bb6c f5355b93 850ab630 84e2660c 858b5001 nt!Kei386EoiHelper+0x186
WARNING: Stack unwind information not *ailable. Following frames may be wrong.
f4c0bbdc f535aa20 85897900 84e2660c 00000028 RapDrv+0xb93
f4c0bc08 f535b282 00222034 84e26608 00000058 RapDrv+0x5a20
f4c0bc28 f535b2f3 865b5ba0 00000058 86043a70 RapDrv+0x6282
f4c0bc4c 8092d3b9 84ad79d8 858e9028 84ad7968 RapDrv+0x62f3
f4c0bc60 8092e81b 865b5ba0 84ad7968 858e9028 nt!IopSynchronousServiceTail+0x10b
f4c0bd00 80940844 00000160 00000000 00000000 nt!Io*xxControlFile+0x5db
f4c0bd34 80834d3f 00000160 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f4c0bd34 7c95ed54 00000160 00000000 00000000 nt!KiFastCallEntry+0xfc
0012d688 00000000 00000000 00000000 00000000 0x7c95ed54
STACK_COMMAND: kb
FOLLOWUP_IP:
RapDrv+9785
f535e785 894104 mov dword ptr [ecx+4],eax
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: RapDrv
IMAGE_NAME: RapDrv.sys
DEBUG_FLR_IMAGE_TIMES*P: 3f99bc4f
SYMBOL_NAME: RapDrv+9785
FAILURE_BUCKET_ID: 0x8E_RapDrv+9785
BUCKET_ID: 0x8E_RapDrv+9785
Followup: MachineOwner
从上面可以看出，在系统崩溃时，RapDrv正试图作一个IO操作，在IopSynchronousServiceTail调用时出错。在网上查寻相关资料，发现DapDrv有一个系统漏洞（相关资料），这个漏洞目前并没有相关补丁和解决方案，好在它发生的条件比较苛刻，如果是攻击，必须是已经攻入系统，在试图修改应用程序时才会触发。也就是说，如果想用这个漏洞进行攻击，对方必须是已经攻入系统才能利用这个漏洞。
综合上述，原来推测的四个可能*，只有最后一个Symantec的版本问题最有可能，因为其它的文件传输，只要不修改服务器上的可执行程序，是不会引发错误的。而Symantec在B服务器上安装的也是服务器版，它的升级过程中，可能会试图替换故障服务器上Symantec的上的9.0版程序。这才会触发RapDrv对文件进行监控。
目前最终处理方案是：
考虑到这种事故发生时造成的影响较小，在基本排除硬件故障后，决定暂时只处理Symantec的版本问题，然后继续观察服务器的状态，如果不再发生类似事件，则不予理会。如果再一次发生类似情况，就将BlackICE中的文件保护功能关闭，这样可以一劳永逸地解决这类事故。