|
|
Задавайте вопросы, мы ответим
Вы не зашли.
в официальной документации нашёл только довольно очевидные рекомендации про использование huge pages и swappines/overcommit.
плюс поскольку mysql thread based, ему ещё нужна хорошая реализация тредов, но в самых популярных операционках на которых ставят mysql с этим вроде всё в порядке (имеется в виду Solaris и Linux с 2.6 ядрами).
Но нигде не нашёл ничего про такие штуки как o_direct/aio, подбор размера блока ФС/страйпа рейда.
Где можно почитать толковое описание что mysql ждёт от операционки, возможно какие-то фичи/настройки лучше не использовать, какие-то только в опредеолённых ситуациях (ndb вроде умеет общаться с sql через shm)?
И ещё такой вопрос.
Насколько я знаю, mysql не очень хорошо масштабируется "вертикально", и что оптимальная конфигурация - 4 ядра, а 8 уже скорее всего будут использоваться не очень эффективно.
Насколько распространена практика биндить mysqld на ядра одного сокета (с помощью taskset например)?
Неактивен
Ничего себе у Вас вопросы 
Начать, наверное, проще с конца. Если Ваша база упирается в процессор, это плохо.
Процессор — это лишние сортировки в памяти, лишние временные таблички — надо
подкручивать приложения, а не базу. В большинстве случаев база — IO-bound.
Теперь что касается IO. Если Вас интересуют такие оптимизации, то, разумеется,
нельзя об этом думать «в общем». Если у Вас NDB — надо подкручивать систему под
NDB. Если у Вас InnoDB — под нее. Идеальной конфигурации «подо всё» не бывает
В случае с NDB влияет канальность памяти, скорость работы ОС с сетью... кстати,
вот тут процессор может тоже влиять, т.к. скорость передачи информации из ОЗУ
высокая.
В случае с InnoDB — стандартный размер страницы InnoDB 16k, соответственно, размер
блока/страйпа нужно подбирать кратным этому значению. В случае с чем-то типа десятки,
наверное, 8к страйп будет идеальным — два диска будут в точности читать страницу.
Разумеется, InnoDB надо пускать на голые диски без ФС — файловой системе не место
при таких оптимизациях 
А вообще, конечно, это все микрооптимизации. Хорошо если 5% производительности
такими настройками удастся накрутить. Грамотное выделение памяти и расстановка
индексов куда эффективнее.
Кстати, если нужны именно такие тонкости — смотрите в сторону XtraDB, он дас тоже
процентов десять (ну и учтите, что у него размер блока меняется ).
Неактивен
Относительно многопоточности, посмотрите доклад Константина Осипова на Highload++ http://www.highload.ru/papers2008/7650.html
Его рекомендация - отключить Query Cache, так как он использует глобальный lock и ограничивает многопоточность.
Неактивен
Also: в 5.1 была бага, связанная с тем, что даже отключенный QC все равно берет
глобальный лок 
Не знаю, починили ли.
Неактивен
paulus написал:
Ничего себе у Вас вопросы
Начать, наверное, проще с конца. Если Ваша база упирается в процессор, это плохо.
Процессор — это лишние сортировки в памяти, лишние временные таблички — надо
подкручивать приложения, а не базу. В большинстве случаев база — IO-bound.
да уж какие есть 8)
у меня ещё пока что ничто никуда не упирается, я пока что читаю документацию, статьи, смотрю записи со всяких конференций, жду пока доедут заказанные книжки и совсем немножко кое-чего делаю в тестовой песочнице.
Про то, что в большинстве случаев эффективнее тюнить приложение/запросы/индексы добавлять - про это я в курсе.
Про то что упираться в проц хуже чем упираться в IO - был не в курсе, думал когда вся база в памяти - это круто 8).
paulus написал:
Теперь что касается IO. Если Вас интересуют такие оптимизации, то, разумеется,
нельзя об этом думать «в общем». Если у Вас NDB — надо подкручивать систему под
NDB. Если у Вас InnoDB — под нее. Идеальной конфигурации «подо всё» не бывает
Да, я это прекрасно понимаю и "в общем" об этом думать не собираюсь. Тем не менее наверняка есть общие issues, а есть специфические для каждого конкретного движка с его движковыми нюансами.
Это есть где-то в одном месте собранное? А то приходиться по мелким крошечкам то там то там собирать.
Может ссылочкой на whitepaper/статью/презентацию поделитесь?
paulus написал:
В случае с NDB влияет канальность памяти, скорость работы ОС с сетью... кстати,
вот тут процессор может тоже влиять, т.к. скорость передачи информации из ОЗУ
высокая.
Скорость работы с сетью - это как я понимаю rmem/wmem буферы, таймауты, всякие там jumbo frames и т.д.
А вот скорость передачи - если и sql и ndb на одной машине, они, как я вычитал, могут общаться не через tcp, а через shared memory.
Тут есть нюансы/issues?
paulus написал:
В случае с InnoDB — стандартный размер страницы InnoDB 16k, соответственно, размер
блока/страйпа нужно подбирать кратным этому значению. В случае с чем-то типа десятки,
наверное, 8к страйп будет идеальным — два диска будут в точности читать страницу.
Разумеется, InnoDB надо пускать на голые диски без ФС — файловой системе не место
при таких оптимизациях
Эм...
Тут я многого не понял.
Размер блока ФС делать кратным размеру блока движка?
У ФС они ведь зачастую меньше 16к, типично - 4к для ext2/3.
Размер же страйпа (ну или allocation unit-а) зачастую сильно больше (256к-1М) и обычно автоматом кратен размеру блока.
У mysql, насколько я понял, нет различия между одноблочным/многоблочным чтением, т.е. и full scan и через index он "физически" будет читать одинаковыми кусочками, и соответственно размер страйпа/ALU под большие чтения подстраивать не нужно.
paulus написал:
А вообще, конечно, это все микрооптимизации. Хорошо если 5% производительности
такими настройками удастся накрутить. Грамотное выделение памяти и расстановка
индексов куда эффективнее.
Кстати, если нужны именно такие тонкости — смотрите в сторону XtraDB, он дас тоже
процентов десять (ну и учтите, что у него размер блока меняется
Да не нужны мне совсем уж тонкости и выжимать единицы процентов производительности такими настройками я не собираюсь.
Мне нужны best practices и general recomedations, желательно с объяснением почему это нужно 8).
Про O_DIRECT для innodb кстати уже нашёл.
Ничего себе микрооптимизация - кешировать данные один раз в кеше БД или два раза ещё и в кеше страничек ФС.
Про aio ничего не нашёл.
Что innodb свои чекпойнты в файлы данных синхронно делает? А в сколько потоков это обычно происходит? Что-то не нашёл параметра типа innodb_writers или innodb_flushers.
Неактивен
rgbeast написал:
Относительно многопоточности, посмотрите доклад Константина Осипова на Highload++ http://www.highload.ru/papers2008/7650.html
Его рекомендация - отключить Query Cache, так как он использует глобальный lock и ограничивает многопоточность.
ага, очень интересно
спасибо большое
сразу захотелось почитать чего там гугл с примитивами синхронизации напатчил 8)
а один mutex на большой кеш - это конечно жестоко
оракл вон дробит латчи на довольно коротки cache buffer chains, чтобы на цепочку был не один латч, а несколько мелких и тем самым параллельность просмотров-модификаций блоков повышалась
Неактивен
По традиции — снизу
1. innodb_file_io_threads; под *nix захардкожено в 4
2. O_DIRECT спасает хуже, чем отсутствие ФС
3. Обычно доступ к базе — это random IO. Увеличить скорость тут можно
путем чтения с нескольких дисков одновременно. Для этого нужно, чтобы
читаемая страничка (она читается всегда целиком) была физически на
разных дисках Отсюда маленький размер чанка.
4. FTS, разумеется, все равно, какие размеры чанков… хотя, на больших
блоках читается быстрее
5. Про shmem лучше ответит rgbeast, чтобы я не наврал в этом месте, но
точно скажу, что кластер на одной ноде не запускают, а на >1 ноде Вы
будете упираться не в локальный IO, а в сеть.
6. Сеть — это не только буферы, но и ядро, например. Говорят, что в этом
месте FreeBSD все еще лучше Linux. Не в плане ядра в целом, а именно
в стеке tcp.
7. Whitepaper не поделюсь, т.к. не знаю такого Опять же, может знать
rgbeast
Неактивен
> 1. innodb_file_io_threads; под *nix захардкожено в 4
и как, хватает?
> 2. O_DIRECT спасает хуже, чем отсутствие ФС
разве в mysql можно держать данные на raw/блочных устройствах?
> 3. Обычно доступ к базе — это random IO. Увеличить скорость тут можно
> путем чтения с нескольких дисков одновременно. Для этого нужно, чтобы
> читаемая страничка (она читается всегда целиком) была физически на
> разных дисках Отсюда маленький размер чанка.
Да ладно вам.
При random IO большинство времени уходит на позиционирование головки и прокручивание шпинделя.
После того как спозиционировались разница прочитать 4к блок или 32к блок настолько мизерная на фоне seek time, что им смело можно пренебречь.
Это когда мы пару сотен мегабайт прочитать хотим - тут да, скорость чтения решает и лучше с нескольких шпинделей тянуть.
> 4. FTS, разумеется, все равно, какие размеры чанков… хотя, на больших
> блоках читается быстрее
ну если такого понятия как "многоблочное чтение" нету, то да, всё равно
если есть, то лучше чтобы логическая порция для чтения которую запрашивает БД и stripe size совпадали
> 5. Про shmem лучше ответит rgbeast, чтобы я не наврал в этом месте, но
> точно скажу, что кластер на одной ноде не запускают, а на >1 ноде Вы
> будете упираться не в локальный IO, а в сеть.
на одной не запускают, но можно же сделать чтобы на одной ноде был и sql и ndb со всем набором партиций (на втором - второй sql и второй ndb с полным набором), тут никакой сети тогда не надо, если все живы-здоровы?
Если локальный ndb умрёт, тогда да, пойдём по сети к соседу.
> 6. Сеть — это не только буферы, но и ядро, например. Говорят, что в этом
> месте FreeBSD все еще лучше Linux. Не в плане ядра в целом, а именно
> в стеке tcp.
ну это как раз доли процентов оптимизации.
мы ж не фаервол с сотнями правил собираем
Неактивен
Хватает; можно; ssd; кластер не отличает «родную» и «удаленную» ноды; это всё
доли процентов, я Вам об этом говорю с самого начала
Неактивен
ладно ок;
круто!;
нууу ssd, это пока что заморская диковинка, для народа всё ещё IO=магнитные шпиндели;
вон в случае координации транзакций - различает, а тут что, не различает кто к нам ближе?;
это с tcp-стеком ядра микро, у нас всё же не фаервольный пакетрейт, а с буферами и jumbo frames самолично видел десятки процентов улучшения на иных оракловых ворклоадах
Неактивен
