Centos 6 и ядро kernel-ml-3.4.2 - Есть ли смысл?
Коллеги, на форумах по PostgreSQL частенько встречаются отзывы о приросте производительности означенной СУБД на последних ядрах. В центос 6 основное ядро 2.6.хх, новые, серии 3.х, вынесены в отдельный пакет kernel-ml, как я понял, по соображениям совместимости. На epel есть отдельная репа.
Собственно, вопрос к тем, кто пробовал: есть ли смысл ставить на боевой сервер новую ветку ядер? Действительно ли повышается производительность в случае использования аппаратного RAID-контроллера?
В общем, поделитесь, пожалуйста, опытом.
Собственно, вопрос к тем, кто пробовал: есть ли смысл ставить на боевой сервер новую ветку ядер? Действительно ли повышается производительность в случае использования аппаратного RAID-контроллера?
В общем, поделитесь, пожалуйста, опытом.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Вы знаете, основное предназначение FC и Centos - тестирование кода для включения в коммерческий RHEL. Отсюда делаем выводы, что с размаху в продакшн то, что даже не включено в основную поставку некоммерческого дистрибутива - занятие рискованное.
[quote] Коллеги, на форумах по PostgreSQL частенько встречаются отзывы о приросте производительности означенной СУБД на последних ядрах [/quote]
ссылкой не поделитесь? очень интересно насколько и за счет чего.
[quote] новые, серии 3.х, вынесены в отдельный пакет kernel-ml, как я понял, по соображениям совместимости [/quote]
Возможно, также по соображениям неустойчивости. Помнится ядро 2.6 до ума доводили довольно долго, а здесь вообще старший номер поменялся, а младенцу еще и года нету. В общем это все пока что не для 1С.
ссылкой не поделитесь? очень интересно насколько и за счет чего.
[quote] новые, серии 3.х, вынесены в отдельный пакет kernel-ml, как я понял, по соображениям совместимости [/quote]
Возможно, также по соображениям неустойчивости. Помнится ядро 2.6 до ума доводили довольно долго, а здесь вообще старший номер поменялся, а младенцу еще и года нету. В общем это все пока что не для 1С.
(5) beldieff,
Может, не так выразился. Цитирую epel:
(3) wkon,
Самому интересно. Вот тут смотрите: и вот тут подробнее:
Это так, что смотрел недавно. А вообще в соответствующих мэйл-листах есть много информации. За бугром народ потихоньку перелезает, и на вполне приличных производственных системах.
(4) VLMedvedev, Вроде все уже довел до ума, во всяком случае, , по тесту Гилева 24 попугая, бывает чуть больше. Очень много баз (более 50), поэтому все время где-то автовакуум работает или индексация, все это прилично жрет ресурсы.
Ядро это ядро и какая может быть совместимость?
Может, не так выразился. Цитирую epel:
The packages are intentionally named kernel-ml so as not to conflict with the RHEL-6 kernels and, as such, they may be installed and updated alongside the regular kernel.
(3) wkon,
ссылкой не поделитесь? очень интересно насколько и за счет чего.
Самому интересно. Вот тут смотрите: и вот тут подробнее:
Это так, что смотрел недавно. А вообще в соответствующих мэйл-листах есть много информации. За бугром народ потихоньку перелезает, и на вполне приличных производственных системах.
(4) VLMedvedev, Вроде все уже довел до ума, во всяком случае, , по тесту Гилева 24 попугая, бывает чуть больше. Очень много баз (более 50), поэтому все время где-то автовакуум работает или индексация, все это прилично жрет ресурсы.
(6)
Так ядро же не в воздухе висит. Системные вызовы к ядру реализуются через системные библиотеки. Вот и совместимость.
Ну не совсем протухший, просто скомпилирован из исходников RHEL чтобы избавиться от ограничений лицензии. Понятно, что с некоторым запозданием относительно релизов RHEL. Кстати, кто хочет то же самое нахаляву и посвежее, может в Scientific Linux заглянуть. Правда по моему опыту, проблем с SL обычно было больше чем с CentOS.
Ядро это ядро и какая может быть совместимость?
Так ядро же не в воздухе висит. Системные вызовы к ядру реализуются через системные библиотеки. Вот и совместимость.
Федора да, а вот Centos это и есть RHEL, только протухший
Ну не совсем протухший, просто скомпилирован из исходников RHEL чтобы избавиться от ограничений лицензии. Понятно, что с некоторым запозданием относительно релизов RHEL. Кстати, кто хочет то же самое нахаляву и посвежее, может в Scientific Linux заглянуть. Правда по моему опыту, проблем с SL обычно было больше чем с CentOS.
Дык загрузка много от чего зависит. wal_buffers и checkpoint_segments, например. У меня их увеличение до 64 МБ и 40 (было сначала 16 МБ и 32) дало заметное ускорение загрузки. Но вообще факторов куча.
Хотя... Вот в том же обсуждении есть ссылка раздел 1.6. Звучит заманчиво. Хотя работает ли это с аппаратным RAID-ом - еще вопрос.
Хотя... Вот в том же обсуждении есть ссылка раздел 1.6. Звучит заманчиво. Хотя работает ли это с аппаратным RAID-ом - еще вопрос.
(11) Если я правильно понял, речь там идет об управлении процессом свопирования виртуальной памяти.
Процесс этот должен быть индиферентен по отношению к аппаратному рейду. Да и к производительногсти СУБД имеет косвенное отношение. Ведь если оперативки в системе достаточно, то своп вообще можно отключить и эта проблема исчезнет.
это я к тому, что наврядли новое ядро радикально что-то изменит.
Процесс этот должен быть индиферентен по отношению к аппаратному рейду. Да и к производительногсти СУБД имеет косвенное отношение. Ведь если оперативки в системе достаточно, то своп вообще можно отключить и эта проблема исчезнет.
это я к тому, что наврядли новое ядро радикально что-то изменит.
(12) wkon, Ага, вот оно что. Точно, Вы правы. Хотя, кроме СУБД на сервере есть еще и 1С. А они, вообще-то, как пауки в банке. Если это хоть 1С-ке поможет, и то спасибо.
Своп отключать (ИМХО) не стоит. Пробовал, поначалу это дает некоторый прирост производительности, но из-за того, что на одном сервере два больших любителя жрать оперативку - Postgre и 1C, при определенных условиях это приводило к неприятным вещам: 1С начинала выгружать огромные массивы в tmp, из-за чего система чуть что не вешалась. Нет, swap нужен.
Что касается оперативки, если бы было чисто серверное железо, думаю, не стал бы париться, купил 128 гиг ECC-шной памяти (8 планок по 16 ГБ, по деньгам порядка 70 т.р., решаемо) и все базы преспокойно поместились бы в ней, и общение с диском свелось бы, в сущности, к записи в логи и WAL. А так - к сожалению, что есть, то есть.
Ладно, в любом случае, наверное, пока оставлю все как есть, работает, и хорошо.
Спасибо!
Своп отключать (ИМХО) не стоит. Пробовал, поначалу это дает некоторый прирост производительности, но из-за того, что на одном сервере два больших любителя жрать оперативку - Postgre и 1C, при определенных условиях это приводило к неприятным вещам: 1С начинала выгружать огромные массивы в tmp, из-за чего система чуть что не вешалась. Нет, swap нужен.
Что касается оперативки, если бы было чисто серверное железо, думаю, не стал бы париться, купил 128 гиг ECC-шной памяти (8 планок по 16 ГБ, по деньгам порядка 70 т.р., решаемо) и все базы преспокойно поместились бы в ней, и общение с диском свелось бы, в сущности, к записи в логи и WAL. А так - к сожалению, что есть, то есть.
Ладно, в любом случае, наверное, пока оставлю все как есть, работает, и хорошо.
Спасибо!
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот