Ищу разработчика
Модератор: Модераторы
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
В реале MySQL очень редко использует распараллеливание на запросов на несколько ядер - то есть даже на 2-ядерной машине можно смело ставить другой сервер (тот же Apache), он будет тупо использовать 2-е ядро.
debi12345 писал(а):В реале MySQL очень редко использует распараллеливание на запросов на несколько ядер - то есть даже на 2-ядерной машине можно смело ставить другой сервер (тот же Apache), он будет тупо использовать 2-е ядро.
Много коннектов - каждый запрос в своей нити, на своем ядре (или как ось решила). На скриншоте второй столбец - номер ядра.
Добавлено спустя 2 минуты 40 секунд:
так что если есть возможность sql-серверу отдельную машину дать, надо давать. Без лишних обвесов типа апача.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
так что если есть возможность sql-серверу отдельную машину дать, надо давать
Дополнительные ядра дешевле дополнительных машин (к которым к тому же нужны свои недешевые SmartUPS, мониторинг, место в серверной и т.п.) - иначе эти ядра никто бы не делал, а имеем наоборот наращивание "ядрёности" {даже на десктопах}
А вот гипертрэдинг для SQL-серверов бесполезен - такую сложную и разветвленную задачу, как SQL-запрос, в трэд-функцию не засунешь.Добавлено спустя 11 минут 5 секунд:
А также обмен данными между БД-сервером и апачем. Если все сервера - на одной машине, то имеем скорость обмена данными с LOCALHOST в десятки гигабит/сек, без создания сетевого траффика.
Есть теоретические рассуждения, есть реалии жизни. А реалии таковы, что все надежно и производительно работает 24x7x365, если следовать принципу 1 сервер - 1 прикладной сервис - 1 сисадмин. Это в продакшн. Скриншот, что был выше - как раз с такой системы. Там четыре системных сервисов крутится (init, klogd, syslogd, cron), один коммуникационный (sshd) и один прикладной - собственно mysqld. Держит все вузовские базы данных, к которым обращение ведется с 4-5 внешних апачей, один из которых торчит в интернет. Не падал никогда с 2008 года, все перезагрузки - исключительно по вине электриков.
Другое дело - когда не хватает ресурсов, или на рабочей машине - там всякое бывает, лично у меня ноутбук тот еще комбайн - и апач и майскул и еще вагон сервисов. Ну еще на слабонагруженных или экспериментальных системах.
Другое дело - когда не хватает ресурсов, или на рабочей машине - там всякое бывает, лично у меня ноутбук тот еще комбайн - и апач и майскул и еще вагон сервисов. Ну еще на слабонагруженных или экспериментальных системах.
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Есть теоретические рассуждения, есть реалии жизни.
100%. Как только VMSTAT начинает показывать заметную долю I/O-ожидания в замедлении сервака - нужно думать либо о переходе на скоростной RAID, либо о выносе части сервисов на другую машину
А реалии таковы, что все надежно и производительно работает 24x7x365, если следовать принципу 1 сервер - 1 прикладной сервис - 1 сисадмин
Стэнд-бай-резервирование всей группы сервисов проще сделать для одной машины.
Однако отдельная машина для апп-сервера хороша для разработчиков - например ее зависание от 100% загрузки из-за ошибки программистов на "положит" БД-сервер.