Ищу разработчика

[debi12345]

В реале MySQL очень редко использует распараллеливание на запросов на несколько ядер - то есть даже на 2-ядерной машине можно смело ставить другой сервер (тот же Apache), он будет тупо использовать 2-е ядро.

[xdsl]

В реале MySQL очень редко использует распараллеливание на запросов на несколько ядер - то есть даже на 2-ядерной машине можно смело ставить другой сервер (тот же Apache), он будет тупо использовать 2-е ядро.

Много коннектов - каждый запрос в своей нити, на своем ядре (или как ось решила). На скриншоте второй столбец - номер ядра.

htopmysql.png

Добавлено спустя 2 минуты 40 секунд:
так что если есть возможность sql-серверу отдельную машину дать, надо давать. Без лишних обвесов типа апача.

[debi12345]

так что если есть возможность sql-серверу отдельную машину дать, надо давать

Дополнительные ядра дешевле дополнительных машин (к которым к тому же нужны свои недешевые SmartUPS, мониторинг, место в серверной и т.п.) - иначе эти ядра никто бы не делал, а имеем наоборот наращивание "ядрёности" {даже на десктопах} А вот гипертрэдинг для SQL-серверов бесполезен - такую сложную и разветвленную задачу, как SQL-запрос, в трэд-функцию не засунешь.

Добавлено спустя 11 минут 5 секунд:
А также обмен данными между БД-сервером и апачем. Если все сервера - на одной машине, то имеем скорость обмена данными с LOCALHOST в десятки гигабит/сек, без создания сетевого траффика.

[xdsl]

Есть теоретические рассуждения, есть реалии жизни. А реалии таковы, что все надежно и производительно работает 24x7x365, если следовать принципу 1 сервер - 1 прикладной сервис - 1 сисадмин. Это в продакшн. Скриншот, что был выше - как раз с такой системы. Там четыре системных сервисов крутится (init, klogd, syslogd, cron), один коммуникационный (sshd) и один прикладной - собственно mysqld. Держит все вузовские базы данных, к которым обращение ведется с 4-5 внешних апачей, один из которых торчит в интернет. Не падал никогда с 2008 года, все перезагрузки - исключительно по вине электриков.

Другое дело - когда не хватает ресурсов, или на рабочей машине - там всякое бывает, лично у меня ноутбук тот еще комбайн - и апач и майскул и еще вагон сервисов. Ну еще на слабонагруженных или экспериментальных системах.

[debi12345]

Есть теоретические рассуждения, есть реалии жизни.

100%. Как только VMSTAT начинает показывать заметную долю I/O-ожидания в замедлении сервака - нужно думать либо о переходе на скоростной RAID, либо о выносе части сервисов на другую машину

А реалии таковы, что все надежно и производительно работает 24x7x365, если следовать принципу 1 сервер - 1 прикладной сервис - 1 сисадмин

Стэнд-бай-резервирование всей группы сервисов проще сделать для одной машины.
Однако отдельная машина для апп-сервера хороша для разработчиков - например ее зависание от 100% загрузки из-за ошибки программистов на "положит" БД-сервер.