2、由于机架服务器内部空间限制，扩展性受到“拖累”，例如1U的服务器大都只有1到2个PCI扩充槽。此外，散热性能也是一个需要注意的问题，且还需要有机柜等设备，因此机架服务器多用于服务器数量较多的大中型企业使用，但也有不少企业将服务器托管于服务商。
3、价格方面，机架的网站服务器一般比同等配置的塔式服务器售价高出30%左右。
刀片式：1、刀片服务器是一种高可用高密度的低成本服务器平台，是专门为特殊应用行业和高密度计算机环境设计的，每一块刀片类似于一个个独立的服务器，它们可以通过本地硬盘启动自己的 *** 作系统。在集群模式下，所有的刀片可以连接起来提供高速的网络环境，共享资源，为相同的用户群服务。
2、根据所需要承担的服务器功能，刀片服务器被分成服务器刀片、网络刀片、存储刀片、管理刀片、光纤通道SAN刀片、扩展I/O刀片等等不同功能的刀片服务器。
3、刀片服务器相较机架服务器更节省空间，同时，散热问题也更突出，往往需要在机箱内安装大型风扇来散热。此型服务器虽然空间较节省，但是其机柜与刀片价格都不低，一般应用于大型的数据中心或需要大规模计算的领域，如银行电信金融行业以及互联网数据中心等。
淘机友解答目前常见服务器类型：塔式服务器、机架式服务器、刀片服务器
目前市场是流行的服务器类型主要有塔式服务器、机架式服务器还有刀片服务器这三种类型，塔式服务器和机架式服务器在中小企业中应用非常广泛，日常中就很容易看到。这两种服务器的价格相对刀片服务器便宜，而且能够快速部署。刀片服务器则拥有集群优势，但是其价格昂贵并且需要专业的技术人员维护。下面我们来看一下他们各自的用户和特点：
塔式服务器：塔式服务器如我们平常工作用的PC机结构大体相似，在中小企业中应用非常广泛，其虽然没有特定的规格，但是一般情况下都比较大，所以升级扩展能力较强，但是由于其独立性太强，协同工作和系统管理方面都不方便，这也是塔式服务器的局限性，但是由于其成本较低，所以在中小企业中应用是非常广泛的。
机架式服务器：机架式服务器最常见的是1U、2U、4U机型，整体设计符合19"国际标准，相比塔式服务器，其散热效果可能差一些，但其采用标准的系统、网络、硬盘和电源插头等设计。而且机架式服务器的管理非常方便，适合大访问量的关键应用，但跟塔式服务器一样，其体积相对于刀片服务器占用空间较大，空间利用率不高，而且需要专业的机房放置服务器。
刀片服务器：刀片服务器是一个高密度集成的产品，使得服务器的整体结构更紧凑、灵活，从而简化了企业布线、存储和管理维护，用户可以进行统一的管理，添加网络、SAN和VLAN设置、电源管理等等都可以设置成统一管理。刀片服务器虽然大大降低总体管理成本，但在单品购买方面，机架式服务器一般比同等配置的塔式服务器贵上二到三成。
至于机柜式服务器，是在一些高档企业服务器中由于内部结构复杂，内部设备较多，有的还具有许多不同的设备单元或几个服务器都放在一个机柜中，这种服务器就是机柜式服务器。
刀片服务器没有屏幕。刀片服务器是将传统的架势服务器的所有功能集中在一块高度压缩的电路板中，然后再插入到机箱中，所以是需要连接显示器的，是没有屏幕的。
刀片服务器是一种HAHD，高可用高密度的低成本服务器平台，是为特殊应用行业和高密度计算机环境专门设计的。刀片服务器原理
刀片服务器就是一个卡上的服务器一个单独的主板上包含一个完整的计算机系统，包括处理器、内存、网络连接和相关的电子器件。如果将多个刀片服务器插入一个机架或机柜的平面中，那么该机架或机柜的基础设施就能够共用，同时具有冗余特性。
每一块刀片实际上就是一块系统主板，每块主板通过本地硬盘运行自己的 *** 作系统，类似一个个独立的服务器。使用管理软件，可以将这些主板集合成一个服务器集群。在集群模式下，所有的主板可以连接起来提供高速的网络环境，可以共享资源，为不同的用户群服务。
刀片服务器公认的优点有两个，一是克服了芯片服务器集群的缺点，另一个是实现了机柜优化，根据所需要承担的服务器功能，刀片服务器被分成服务器刀片、网络刀片、存储刀片、管理刀片、光纤通道SAN刀片、扩展IO刀片等等不同功能的相应刀片服务器。
具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。
为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？
相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert *** 作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？
dba此时心中有无限的疑惑，到底是什么原因呢 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？
当数据库出现响应时间不稳定的时候，我们在 *** 作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么 *** 作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？
如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。
在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。
咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。
提问 数据页不在buffer bool 里面该怎么办？
回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 中显示
buffer_read_page函数栈的顶层是pread64(),调用了 *** 作系统的读函数。
buf_read_page的代码
如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的 *** 作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待 *** 作系统完成IO
再接着上面的回答提问：
当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？ 代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。
试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。
通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。
再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。
由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。
再回头来看上面的问题，mysql数据库出现性能下降时，可以看到 *** 作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写 *** 作是不堵塞执行sql的会话线程的。所以，即使看到 *** 作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在 *** 作系统上基本看不到读的IO。 当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）