нуждается ли Debian 7 с 32ГБ RAM в тюнинге

Эээ.. 32Гб это ни о чем, вот с 256Гб это да :))

Если нужна оптимизация только под MySQL - то увеличь кэши (если это innodb, то размер пула) до 80-90% оперативки - это основное.

По поводу остальных параметров читай профильные манулы.

видимо отстал от жизни :)

но всё равно, может и можно что-то оптимизировать в ОС.

Можно свап вырубить, остальные моменты твоё ядро разрулит.

оптимизации под MySQL

переходи на Postgresql - вот это будет реальный тюнинг

а смысл вырубать свап? в смысле что от этого изменится?

Оно уже умеет нормальную кластеризацию?

нуждается ли Debian 7 с 32ГБ RAM в тюнинге

добавь еще 32. )))

Оно уже умеет нормальную кластеризацию?

нормальную это какую?

Master-Master например на минимум трех нодах.

а смысл вырубать свап? в смысле что от этого изменится?

по умолчанию в своп данные вытесняются когда памяти еще до фига, лучше не своп вырубать а вот такое применять при загрузке:

echo 99 > /proc/sys/vm/swappiness;

Master-Master например на минимум трех нодах.

если честно конкретно на SQL мне не нужно - не смотрел, но прогресс с этим за последние годы большой. сомневаюсь что ТС нужно. кто лучше в теме?

не 99, а 0

а ты проверь и то и то

а зачем он вообще? Это винда не может без него жить будь там хоть 300экзебайт оперативы... А на линуксе с 8+ гигами своп ИМХО совершенно не нужен

Я уже давно юзаю этот параметр. А еще умею читать доки:

swappiness

This control is used to define how aggressive the kernel will swap
memory pages.  Higher values will increase agressiveness, lower values
decrease the amount of swap.  A value of 0 instructs the kernel not to
initiate swap until the amount of free and file-backed pages is less
than the high water mark in a zone.

он нужен хотя бы для того, чтобы система раком не стала, когда память кончится

чем можно забить 32 гига?)))

Я уже давно юзаю этот параметр. А еще умею читать доки:

Я его пользую лет 5. Интересно. Толи я его не правильно пользую, толи его поведение изменилось.

Скорее первое, поведение не менялось после его появления.

ok, поставил 0 и сразу появился swap - тут явно что-то не так

Да, что-то не так.

У меня на двух серверах:

# sysctl -a | grep -i swap
vm.swappiness = 0
# free | grep -i swap
Swap:      3905532          0    3905532

# sysctl -a | grep -i swap
vm.swappiness = 60
# free | grep -i swap
Swap:      3905532     112400    3793132

Сразу видна разница :)

нельзя, сколько бы памяти не было своп должен быть

Спорно.

У меня много серверов без свопа, например iSCSI/FC хранилища, там он даже в принципе понадобиться не может.

Да и особой разницы между память или память+свап нет - если какое-то приложение начнёт течь мозгами, или плодить процессы, то свап только оттянет неизбежное + затормозит сервер, вместо того, чтобы при окончании кабеля сработал ООМ и убил процесс.

Clusterfuck waiting to happen. Знаем, плавали.

да это мой косяк, echo в cron было. спасибо

Да там по-моему ведро совсем без свапа странно себя вести начинает. Хоть 128М, но оставляем.

wat?

чтобы система раком не стала, когда память кончится

Встанет и со свопом и без него, дурик.

Без свопа при резкой течке система повиснет, ООМ не сработает

Мускуловский master-master работает через жопу. И лучше его не использовать.

резкой

Хороший технический термин.

система повиснет

Под системой понимается? Ядро, наверное.

при резкой течке система повиснет, ООМ не сработает

Пруф на багзиллу ядра.

Оно уже умеет нормальную кластеризацию?

В mysql есть нормальная кластеризация? =DDD

А в чём суть? При таком сценарии своп не спасёт ни разу.

Фуфло.

Я вот на сервере с 256Гб памяти запустил на днях memtest под дебианом, он начал зохавывать память и делать ей mlock() (это его нормальное поведение ессесно, на то он и мемтест)

Памяти я мемтесту указал чуть больше чем надо и ядро его убило через ООМ вполне успешно, хотя уж что что, а память он хавал на максимальной скорости.

А вот бы такой же эксперимент, но со свопом...

отдай 16 гб бедным

mlock() помечает области памяти как не подлежащие скидыванию в свап, так что бессмысленно :)

man galera

man galera x2

https://bugs.launchpad.net/galera

на физической машинке с таким объёмом памяти

С таким объёмом памяти имеет смысл располагать сервисы в виртуальных машинах.

Аа, не знал.

и?

может и можно что-то оптимизировать в ОС.

Чтобы понять, что можно оптимизировать, надо сначала найти то, что не устраивает. Лучшее - враг хорошего.

И нет, это НЕ нормальная кластеризация.

С постгресом не сравнить, однако в некоторых ситуациях этого достаточно.

Данными. Единицами и нулями, если быть точным. Кэш запросов, индексы там всякие, дисковый кэш опять-же.
Выжрать можно любое количество RAMы, просто смирись с этим.

У меня есть подозрение что РСУБД в принципе не умеют нормальную кластеризацию. Слишком сложные.

У меня свопа нет на десятке машин с разным количеством оперативы. Объяснишь мне, зачем он нужен?

Последнее ядро с PAE.