服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 与5.5版本相比，MySQL 5.5降低了Linux内核3.2的性能
Intereting Posts
Crontab + AWS：“无法find凭据” Azure IO性能 禁用5xx和4xx HTTP状态码的IIS 7.5服务器错误响应 如何在设置LACP后testing增加的带宽？ 如何监控远程机器的TCP / IP（或HTTP）stream量？ 我需要在Linux中为nagios用户创build一个帐户 iptables：限制每天每IP下载的字节数？ CYGWin和sshd。 接受authentication，但不会连接 在SharePoint环境中更改和发布pipe理 设置ulimit和Ubuntu 8.04 shell脚本不能作为cron工作，尝试了每个解决scheme，出于想法 Oracle完全修补安装 如何跟踪窗口服务的CPU利用率？ 计算机尝试从错误的位置加载漫游configuration文件 在无头虚拟机中运行基于gui的桌面软件

与5.5版本相比，MySQL 5.5降低了Linux内核3.2的性能

我们的数据库服务器（主要基于Debian稳定软件包（当前为Wheezy））似乎在内核3.2.0-4-amd64的相同工作负载的情况下比在之前的2.6.32-5-amd64内核中的负载大约多4倍。如果所有的软件包都是相同的，并且在另一个内核中启动，我们可以清楚地看到它们之间的差异，而且我为什么会感到不知所措。问题是，我没有看到太多的IO或CPU负载差异。

将默认的kernel.sched_min_granularity_ns和kernel.sched_latency_ns设置回2.6.32值会有所帮助（三次加载而不是四次），但是不会达到我们想要的水平。 当很多内核设置发生变化时，我们几乎不能盲目地将新内核设置为2.6的旧内核值。

有没有其他人有这方面的经验？ 如果是这样，是什么造成了这一点（理想的情况是：怎么解决的）？

由于它与内核深层有关，所以在sysctl值上的区别也许是有意义的： 这里是2的区别 （为了防止过长的问题，pastebinned）。

编辑 ：目前我们正在调查这个答案 ，看看是否适用。

应避免或升级Linux内核3.0 – 3.8以解决IO性能下降问题

Josh Berkus使用在内核3.2.0的Ubuntu 12.04上针对PostgreSQL 9.3运行的私有基准testing工作负载，演示了Linux内核IO性能下降情况。

“…你真的需要避免每个内核在3.0到3.8之间，虽然RHEL一直坚持2.6内核（它有自己的问题，但不是这样坏），Ubuntu已经发布了12.04的各种3.X内核…升级到内核3.13.0，运行的工作负载也相同…减less了80％的IO，我们可以感谢Linux FS / MM群体中的聪明人，问题“。

请参阅http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html

我在DBA StackExchange中解决了关于内核和日志的问题 。 我在5月份从Percona那里了解到，实际上某种冲洗行为是模拟的。

  • 您可能必须更改日记的完成方式。
  • 你可能不得不调整InnoDB
    • 松开写性能的ACID兼容性（将innodb_flush_log_at_trx_commit设置为0或2）
    • 更大的日志文件
    • 更大的日志缓冲区

也许报告的负载是不正确的，就像这个错误报告： http : //bugs.debian.org/cgi-bin/bugreport.cgi? bug= 693942

你能看到有什么更慢吗？ 还是vmstat看起来像服务器真的在做更多的工作？ 否则我会假设你刚才碰到了那个报告的错误，前一段时间也发生了同样的情况，服务器的性能没有什么不同，只是输出的负载平均值较高。

我没有声誉使这个评论..但是当你升级内核你也升级的MySQL版本？ 你能列出你正在运行的MySQL 5.5.X吗？

具有讽刺意味的是，一些较新版本的MySQL实际上已经使性能明显变差了。当然，他们已经解决了这些问题，但在我的应用程序中进行更改时，确实为我创造了一个重​​要的红色听觉。

“InnoDB：Bug＃17699331的修复引起了很高的读取/写入locking创build和销毁率，导致了性能回归（错误＃18345645，错误＃71708）”

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-19.html

“InnoDB：由Bug＃14329288引入的一个回归会导致压缩的表不适合内存时的性能下降。”（错误＃18124788，错误＃71436）“

http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-17.html

..等等

5.5也是一样的：

“InnoDB：由Bug＃14329288引入的一个回归会导致压缩的表不适合内存时的性能下降。”（错误＃18124788，错误＃71436）“

http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-37.html

升级到更新的MySQL是否会将其恢复到合理的性能？

MySQL也有一些内核特定的代码：

“某些Linux内核版本的tmpfs不支持asynchronousI / O，解决办法是closuresinnodb_use_native_aio设置或使用其他临时目录，如果检测到临时文件，InnoDB会自动closuresinnodb_use_native_aio设置目录不支持asynchronousI / O（错误＃13593888，错误＃11765450，错误＃58421）“

“ http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-5.html

所以我会确保你正在运行最新版本。

另外考虑一下MySQL 5.6.X（现在已经正式稳定并且已经有一段时间了），“对于Linux，MySQL 5.6的TPS吞吐量比MySQL 5.5高出150％” http：//dev.mysql。 COM /技术资源/文章/ MySQL的-5.6-rc.html

我有巨大的MySQL性能问题，从Debian W /内核2.6和MySQL 5.1到Debian W /内核3.2和MySQL 5.5（wheezy）。

什么解决了mysql的问题在/ etc / fstab中是barrier = 0。 看看https://wiki.archlinux.org/index.php/Ext4