新品网络推广,seo没什么作用了,开福区互动网站建设,景区网站建设 现状优化服务器设置
高级InnoDB设置
innodb_old_blocks_time
InnoDB有两段缓冲池LRU(最近最少使用)链表#xff0c;设计目的是防止换出长期很多次的页面。像mysqldump产生的这种一次性的(大)查询#xff0c;通常会读取页面到缓冲池的LRU列表#xff0c;从中读取需要的行…优化服务器设置
高级InnoDB设置
innodb_old_blocks_time
InnoDB有两段缓冲池LRU(最近最少使用)链表设计目的是防止换出长期很多次的页面。像mysqldump产生的这种一次性的(大)查询通常会读取页面到缓冲池的LRU列表从中读取需要的行然后移动到下一页。理论上两段LRU链表将阻止此页取代很长一段时间内都需要用到的页面被放入年轻(Young)子链表并且只在它被已被浏览过多次后将其移动到年老(Old)子链表。但是InnoDB默认没有配置为防止这种情况因为页内有很多行所以从页面读取的行的多次访问会导致它立即被转移到年老(Old)子链表对哪些需要长时间缓存的页面带来换出的压力。这个变量指定一个页面从LRU链表的年轻部分转移到年老部分之前必须经过的毫秒数。默认情况下将它设置为0将它设为诸如1000毫秒(一秒)这样的小一点的值在基准测试中已被证明非常有效。
线程
MySQL每个连接使用一个线程另外还有一个内部处理线程、特殊用途的线程以及所有存储引擎创建的线程。在MySQL5.5中Oracle提供了一个线程池插件但目前尚不清楚在实际应用中能获得什么好处。无论哪种方式MySQL都需要大量的线程才能有效地工作。MySQL确实需要内核级线程地支持而不只是用户级线程这样才能更有效地使用多个CPU.另外也需要有效的同步原子例如互斥变量。操作系统的线程库必须提供所有的这些功能。 GNU/Linux提供两个线程库:LinuxThreads和新的原生POSIX线程库(NPTL).LinuxThreads在某些情况下仍然使用但现在的发行版已经切换到NPTL并且大部分应用已经不再加载LinuxThreads.NPTL更轻量更高效也不会有哪些LinuxThreads遇到的问题。 FreeBSD会加载许多线程库。从历史上看它对县城的支持很弱但现在已经宾得好多了在一些测试中甚至由于SMP系统上的GNU/Linux。在FreeBSD6和更新版本土建的线程库是libthr,早期版本使用的linuxthreads,是FreeBSD从GNU/Linux上一致的Linux/Threads库。 通常线程问题都是过去的事了现在GNU/Linux和FreeBSD都提供了很好的线程库Solaris和Windows一直对线程有很好的支持尽管直到5.5发布之前MyISAM都不能在Windows下很好地使用线程但5.5里有显著的提升
内存交换区 当操作系统因为没有足够的内存而将一些虚拟内存写到磁盘就会发生内存交换(内存交换有时称为页面交换从技术上来说它们是不同的东西但是人么你通常把它们作为同义词)内存交换对操作系统中运行的进程是透明的。只有操作系统知道特定的虚拟内存地址是在物理内存还是硬盘。 内存交换对MySQL性能影响是很糟糕的它破坏了缓存在内存的目的并且相对于使用很小的内存做缓存使用交换区的性能更差。MySQL和存储引擎有很多算法来区别对待内存中的数据和硬盘上的数据因为一般都假设内存数据访问代价更低。 因为内存交换对用户进程不可见MySQL(或存储引擎)并不知道数据实际上已经移动到磁盘还会以为在内存中。 结果会导致很差的性能。例如若存储引擎认为数据依然在内存可能觉得为短暂的内存操作锁定一个全局互斥变量(例如InnoDB缓冲池Mutex)是OK的。如果这个操作实际上引起了硬盘IO,直到IO操作完成前任何操作都会被挂起。这意味着内存交换比直接做硬盘IO操作还要糟糕。 在GNU/Linux上可以用vmstat来监控内存交换。最好查看si和so列报告的内存交换IO活动这比看swap列报告的交换区利用率更重要。swapd列可以展示那些被载入了但是没有被使用的进程它们并不是真的会称为问题。我们喜欢si和so列的值为0并且一定要保证它们低于每秒10个块。 极端的场景下太多的内存交换可能导致操作系统交换空间溢出。如果发生了这种情况缺乏虚拟内存可能让MySQL崩溃。但是即使交换空间没有移除非常活跃的内存交换也会导致整个操作变得无法响应到这种时候甚至不能登录系统去杀掉MySQL进程。有时当交换空间溢出时甚至Linux内核都会完全Hang住。绝不要让系统的虚拟内存溢出对交换空间利用率做好监控和报警。如果不知道需要多少交换空间就在硬盘上尽可能多地分配空间这不会对性能造成冲击只是消耗了硬盘空间。有些大的组织清楚地直到内存消耗将有多大并且内存交换被非常严格地控制但是对于只有少量多用途的MySQL实例并且工作负载页多种多样的环境通常不切实际。如果后者的描述更符合实际情况确认给服务器一些呼吸的空间分配足够的交换空间。 在特别大的内存压力下经常发生的另一件事是内存不足(OOM)这会导致踢掉和杀掉一些进程。在MySQ进程这很常见。在另外的进程上也挺常见比如SSH甚至会让系统不能从网络访问。可以通过设置SSH进程的oom_adj或oom_score_adj值来避免这种情况。 可以通过正确地配置MySQL缓冲来解决大部分内存交换问题但是有时候操作系统的虚拟内存系统还是会决定交换MySQL的内存。这通常发生在操作系统看到MySQL发出了大量的IO,因此尝试增加文件缓存来保存更多数据时。如果没有足够的内存有些东西就必须交换出去有些可能就是MySQL本身。有些老的Linux内核版本也有一些适得其反鞥多优先级导致本不应该被交换的被交换出去但是在最近的内核都被缓解了。 有些人主张完全禁用交换文件。尽管这样做有时在某些内核拒绝工作的极端场景下是可行的但这降低了操作系统的性能(在理论上不会但是实际上会的)。同时这样做也是很危险的因为禁用内存交换就相当于给虚拟内存设置了一个不可动摇的限制。如果MySQL需要临时使用很大一块内存或者有很耗内存的进程运行在同一台机器(如夜间批量任务)MySQL会内存溢出、崩溃或者被操作系统杀死。 操作系统通常允许对虚拟内存和IO进行一些限制。我们提供过一些GNU/Linux上控制它们的办法。最基本的办法是修改/proc/sys/vm/swappiness为一个很小的值例如0或1.这告诉内核除非虚拟内存完全满了否则不要使用交换区。下面如何检查这个值的例子。这个值显示为0这是默认的设置(范围是0~100),如果它不是0则对服务器而言这是一个跟糟糕的默认值服务器应该设置为0:
另一个选项是修改存储引擎怎么读取和写入数据。例如使用innodb_flush_method0_DIRECT减轻IO压力DirectIO并不缓存因此操作系统并不能把MySQL视为增加文件缓存的原因。这个参数只对InnoDB有效。你也可以使用大页不参与换入换出。这对MyISAM和InnoDB都有效。 另一个选择是使用MySQL的memlock配置项可以把MySQL锁定在内存。这可以避免交换但是也可能带来危险:如果没有足够的可锁定内存MySQL在尝试分配更多内存时会崩溃。这也可能导致锁定的内存太多而没有足够的内存留给操作系统。很多技巧都是对于特定内核版本的因此要小心尤其是当升级的时候。在某些工作负载下很难让操作系统的行为合情合理并且仅有的资源可能让缓冲大小达不到最满意的值
