Наши серверы баз данных (в основном основанные на стабильных пакетах Debian (= в настоящее время Wheezy), похоже, примерно в 4 раза больше Больше нагрузка для той же рабочей нагрузки в ядре 3.2.0-4-amd64 то в предыдущем 2.6.32-5-amd64 ядро. Когда все пакеты одинаковы и загружаются в другое ядро, мы можем ясно видеть разницу, и я не понимаю, почему. Проблема в том, что я не вижу такой большой разницы в загрузке ввода-вывода или процессора.
Установка по умолчанию kernel.sched_min_granularity_ns & kernel.sched_latency_ns назад к этому 2.6.32 values немного помогает (втрое больше нагрузки вместо 4х раз), но не до желаемого уровня. Поскольку многие настройки ядра изменились, мы не можем просто слепо установить новое ядро на старые значения по умолчанию 2.6 один.
У кого-нибудь еще был опыт с этим? Если да, то чем это вызвано (и в идеале: как это можно решить)?
Поскольку это глубоко связано с ядром, возможно, может быть интересна разница в значениях sysctl: вот разница 2 (вставлено, чтобы не задавать слишком длинный вопрос).
редактировать: в настоящее время мы исследуем этот ТАК ответ чтобы увидеть, применимо ли это.
Ядра Linux 3.0 - 3.8 следует избегать или обновлять для устранения снижения производительности ввода-вывода.
Ухудшение производительности ввода-вывода ядра Linux, продемонстрированное Джошем Беркусом, используя частную тестовую рабочую нагрузку, работающую с PostgreSQL 9.3 в Ubuntu 12.04 с ядром 3.2.0.
"... вам действительно нужно избегать всех ядер между 3.0 и 3.8. Хотя RHEL придерживался ядер 2.6 (у которых есть свои проблемы, но не так уж и плохо), Ubuntu выпустила различные ядра 3.X для 12.04 ... обновлен ... до ядра 3.13.0, и выполнял ту же самую рабочую нагрузку ... снижение ввода-вывода на 80%. Мы можем поблагодарить умных людей из группы Linux FS / MM за то, что они сильно снизили производительность вопросы."
Посмотри пожалуйста http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html
Я рассмотрел проблему в DBA StackExchange о ядре и журналировании. Я узнал об этом от Percona еще в мае, что на самом деле моделируется определенное поведение смыва.
Возможно, заявленная нагрузка просто неверна, как в этом отчете об ошибке: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693942
Вы видите, что на самом деле есть что-то более медленное? или vmstat выглядит так, будто сервер действительно выполняет больше работы? в противном случае я бы предположил, что вы только что столкнулись с этой сообщенной ошибкой, то же самое случилось со мной некоторое время назад, производительность сервера не изменилась, только выводимая средняя нагрузка была выше.
У меня нет репутации, чтобы сделать это комментарием ... но, когда вы обновляли ядро, вы также обновляли версию MySQL? Можете ли вы указать, какой MySQL 5.5.X вы используете?
По иронии судьбы ошибки в некоторых новых версиях MySQL на самом деле заметно ухудшили производительность ... они, конечно же, исправили их, но это действительно вызвало у меня серьезную тревогу при внесении изменений в мое приложение.
«InnoDB: исправление ошибки № 17699331 вызвало высокую скорость создания и разрушения блокировок чтения / записи, что привело к снижению производительности. (Ошибка № 18345645, ошибка № 71708)»
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-19.html
«InnoDB: регрессия, введенная ошибкой № 14329288, приведет к снижению производительности, если сжатая таблица не помещается в память. (Ошибка № 18124788, ошибка № 71436)»
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-17.html
..и т.д
То же самое и для 5.5:
«InnoDB: регрессия, введенная ошибкой № 14329288, приведет к снижению производительности, если сжатая таблица не помещается в память. (Ошибка № 18124788, ошибка № 71436)»
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-37.html
Вернет ли обновление до новой версии MySQL к разумной производительности?
В MySQL тоже есть код, специфичный для ядра:
"асинхронный ввод-вывод не поддерживается в tmpfs в некоторых версиях ядра Linux. Обходной путь состоял в том, чтобы отключить параметр innodb_use_native_aio или использовать другой временный каталог. Исправление заставляет InnoDB автоматически отключать параметр innodb_use_native_aio, если он обнаруживает, что временный файл каталог не поддерживает асинхронный ввод-вывод. (Ошибка № 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 до 150% по сравнению с MySQL 5.5». http://dev.mysql.com/tech-resources/articles/mysql-5.6-rc.html
У меня были огромные проблемы с производительностью mysql при переходе с debian с ядром 2.6 и mysql 5.1 на debian с ядром 3.2 и mysql 5.5 (wheezy).
Что решило проблему для mysql, так это "" "" барьер = 0 "в / etc / fstab. Проверять, выписываться https://wiki.archlinux.org/index.php/Ext4