第一，内存泄漏
C/C++程序还可能产生另一个指针问题:丢失对已分配内存的引用。当内存是在子程序中被分 配时，通常会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要 *** 作系统还在运行中，则进程就会一 直使用该内存。这样的结果是，曾占用更多的内存的程序会降低系统性能，直到机器完全停止工作，才会完全清空内存。
第二，C指针错误
用C或C++编写的程序，如Web服务器API模块，有可能导致系统的崩溃，因为只要间接引 用指针(即，访问指向的内存)中出现一个错误，就会导致 *** 作系统终止所有程序。另外，使用了糟糕的C指针的Java模拟量(analog)将访问一个空的 对象引用。Java中的空引用通常不会导致立刻退出JVM，但是前提是程序员能够使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但 使用Java对可靠性进行额外的度量则会对性能产生一些负面影响。
第三，数据库中的临时表不够用
许多数据库的临时表(cursor)数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。
第四，线程死锁
由多线程带来的性能改善是以可靠性为代价的，主要是因为这样有可能产生线程死锁。线程死锁 时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形:在人行道上两个人迎面相遇，为了给对方让 道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续 下去，这样就不难理解为何会发生死锁现象了。
第五，磁盘已满
导致系统无法正常运行的最可能的原因是磁盘已满。一个好的网络管理员会密切关注磁盘的使用情况，隔一定的时间，就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带)。
日志文件会很快用光所有的磁盘空间。Web服务器的日志文件、SQLNet的日志文件、 JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。可以采取措施将日志文件保存在与 *** 作系统不同的文件系统中。日志文件系统空间已 满时Web服务器也会被挂起，但机器自身被挂起的几率已大大减低。
第六，服务器超载
Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应，则该服务器上的负载就可以分布到其 它的Web服务器上，这可能会致使这些服务器一个接一个地用光所有的线程。这样一来，整个服务器组都会被挂起。 *** 作系统级别可能还在不断地接收新的连接， 而应用程序(Web服务器)却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected(已连接)的提示消息，但这以后什么也不会发生。
总之，还有许多因素也极有可能导致服务器租用或服务器托管站点无法工作。有许多种原因可能导致Web站点无法正常工作，这使得系统地检查所有问题变得很困难。
飞书官方对于这一次的网络服务器崩溃还是非常重视的，在当天下午的一点就已经给出了回复，表示之所以会出现故障，主要就是因为机房网络瘫痪导致他们的服务器没有办法正常的运行，目前服务器已经被修复完毕。说句实在话，整个维修过程还是非常快速的，从这里就可以看出，他们的技术团队还是非常强力的，今天就跟大家来探讨一下，这一次的服务器崩溃。
第一，具体是什么原因导致服务器的崩溃？飞书官方对外并没有进行多的解释，他们只是表示是因为网络的故障导致服务器瘫痪，没有办法进行正常的交互使用，才导致部分功能没有办法运营。而且这一次影响的范围其实并不大，在当时还是有很多的用户是可以正确的使用飞书软件的。其实从这里就可以看出，他们把自己的服务器进行了分流，从而保证在出现问题的时候，不至于全面瘫痪。
第二，维修的时间是非常快速的。在当天上午的时候出现网络故障，在下午1点的时候，官方网站就已经给出了解释，并且表示已经进行了维修，从这里就可以看出，他们的技术团队反应速度非常快。当然在互联网这个领域，其实我国的发展是非常迅速的，可能是后起之秀，也让我们在很多的软件和硬件上进行了更新。
第三，如何看待这一次的网络故障？我认为服务器出现这样的网络故障是非常正常的，毕竟像飞书以他背后的公司，每天都要处理数10亿以上的文件交流信息的流量是非常大的，服务器自然也是需要有多个元器件参与到其中的。任何的断电或者温度上升以及网络波动都可能会导致其运营出现问题。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）