线程死锁
由多线程带来的性能改善是以可靠性为代价的,主要是因为这样有可能产生线程死锁。线程死锁时,第一个线程等待第二个线程释放资源,而同时第二个线程又在等待第一个线程释放资源。我们来想像这样一种情形:在人行道上两个人迎面相遇,为了给对方让道,两人同时向一侧迈出一步,双方无法通过,又同时向另一侧迈出一步,这样还是无法通过。双方都以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去,这样就不难理解为何会发生死锁现象了。
解决死锁没有简单的方法,这是因为使线程产生这种问题是很具体的情况,而且往往有很高的负载。大多数软件测试产生不了足够多的负载,所以不可能暴露所有的线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易,所以 Java程序员中使用线程的人数更多,线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用,这样可以减少死锁,但这样做也会影响性能。如果负载过重,数据库内部也有可能发生死锁。
如果程序使用了永久锁,比如锁文件,而且程序结束时没有解除锁状态,则其他进程可能无法使用这种类型的锁,既不能上锁,也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。
服务器超载
Netscape Web服务器的每个连接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起,而不为已存在的连接提供任何服务。如果有一种负载分布机制可以检测到服务器没有响应,则该服务器上的负载就可以分布到其它的 Web服务器上,这可能会致使这些服务器一个接一个地用光所有的线程。这样一来,整个服务器组都会被挂起。操作系统级别可能还在不断地接收新的连接,而应用程序(Web服务器)却无法为这些连接提供服务。用户可以在浏览器状态行上看到connected(已连接)的提示消息,但这以后什么也不会发生。
解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值,这样如果越过 RqThrottle的值,就不会接收新的连接。那些不能连接的服务器将会停止工作,而连接上的服务器的响应速度则会变慢,但至少已连接的服务器不会被挂起。这时,文件描述符至少应当被设置为与线程的数目相同的数值,否则,文件描述符将成为一个瓶颈。
数据库中的临时表不够用
许多数据库的临时表(cursor)数目都是固定的,临时表即保留查询结果的内存区域。在临时表中的数据都被读取后,临时表便会被释放,但大量同时进行的查询可能耗尽数目固定的所有临时表。这时,其他的查询就需要列队等候,直到有临时表被释放时才能再继续运行。
这是一个不容易被程序员发觉的问题,但会在负载测试时显露出来。但可能对于数据库管理员(DataBase Administrator,DBA)来说,这个问题十分明显。
此外,还存在一些其他问题:设置的表空间不够用、序号限制太低,这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且,大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。
另外,还有许多因素也极有可能导致Web站点无法工作。如:相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无意间锁住了关键的表。
文章来源于领测软件测试网 https://www.ltesting.net/