В течение долгого времени я хотел узнать, как MySQL масштабируется по мере увеличения объема памяти на сервере. Мы искали баланс между максимальным использованием оборудования, ограничением сложности системы и снижением соотношения цены и производительности. .Пожалуйста, предложите правильное решение этой проблемы.
Не существует универсального решения для каждой среды, но процесс настройки производительности всегда один и тот же. Настройка производительности - это итеративный процесс:
По мере устранения каждого узкого места вы можете обнаружить, что другая часть системы теперь является ограничивающим фактором. Вот почему вам нужно повторять процесс, пока вы не будете довольны результатом.
Главное, что нужно искать на всех уровнях анализа производительности, - это задержка. Какие занятия занимают больше всего времени? Какие действия находятся на критическом пути активности пользователей? Задержка на критическом пути - это прямая мера боли пользователя, тогда как другие показатели, такие как пропускная способность, iops, процессор и использование памяти, не имеют очевидного значения.
Определите свои медленные запросы и оптимизируйте их - если возможно, перепишите запрос или добавьте индексы, а если нет, добавьте оборудование. Если ваши показатели показывают, что большую часть времени запрос тратит на ожидание чтения с диска, то добавление памяти для увеличения кеша поможет устранить это узкое место. Если большую часть времени тратится на ожидание синхронной записи на диск, приобретите больше дисков или более быстрые диски (например, твердотельные накопители). Если большую часть времени тратится на ожидание процессорного времени или процессора, приобретите больше или более быстрые процессоры.
Если у вас есть возможность запустить свою базу данных в системе с DTrace, прочтите Книга Брендана Грегга по DTrace и будьте просветленными.
Я давно хотел узнать, как MySQL масштабируется, когда вы добавляете на сервер больше памяти.
Очень похоже на Oacle, SQL Server и все другие серверы баз данных. Физика операций с базой данных и условия ACID не меняются.
Мы искали баланс между максимальным использованием оборудования, ограничением сложности системы и снижением соотношения цены и производительности. Пожалуйста, предложите правильное решение этой проблемы.
Какая оптимальная машина?
Тот же ответ: ЭТО ЗАВИСИТ. Вы ничего не сказали, чтобы ответить, проголосовали за закрытие.
Смотри, я запускаю sql-сервер. МАЛЕНЬКАЯ установка - ТОЛЬКО 16 ГБ памяти, 4 ядра, 8 быстрых жестких дисков и 1 загрузочный накопитель ssd +. Да, это мало - в другом мире (другой контракт) я работаю над Oracle Exadata с 21000 ГБ места в базе данных, который стоит больше, чем большинство суперкаров. Потому что нам это нужно. В моем следующем обновлении до моего sql serve r будет место для 80 дисков, 128 ГБ памяти и намного больше ssd. Большинство людей сочтут это большим, я считаю его хорошим сервером начального уровня.
Возможно, вы находитесь в лиге, где считаете, что SSD на 60 ГБ - это дорого. Ты не скажешь. Вы ничего не говорите о том, что вам нужно сделать, сколько у вас нагрузки. Что вы ждете от нас ответа?
Единственный разумный ответ: настройте свои узкие места и планируйте расширение. Например, SuperMicro имеет хорошие серверные корпуса высотой в 4 стойки, вмещающие до 72 дисков, а также передвижную плату. 2 стойки = 24 диска. Один из них обеспечивает масштабируемость компьютера. Получите многопроцессорную плату ЦП, подключите ее. То же самое и с RAM. Устраняйте узкие места по мере их появления. Знайте, что вы делаете;) Уменьшение сложности системы - бесполезная операция, когда вы получаете базу данных более высокого уровня. Это как пятизвездочный повар, говорящий, что он не хочет готовить, а предпочитает полуфабрикаты. Системы баз данных более высокой производительности ЯВЛЯЮТСЯ сложными. Смирись с этим.
Это зависит от используемого вами двигателя. Самый распространенный движок MyISAM в этом отношении довольно тупой - сам по себе не производит значимого управления памятью. Практически все остается на усмотрение операционной системы. Если алгоритм разбиения на страницы O / S способен определить, что движку может понадобиться дальше, он оставит нужные файлы в кеше файловой системы. В противном случае они будут выброшены, и их придется снова загрузить с диска для следующего запроса.
Поскольку операционная система не знает о структурах данных MyISAM, она не будет отдавать предпочтение индексным страницам базы данных, кроме как из-за того, что они находятся среди «самых последних использованных» данных базы данных. Любая другая «правильная» СУБД в мире вычислений будет осуществлять собственное управление памятью, иногда даже собственное управление потоками поверх операционной системы в качестве мер оптимизации производительности - таким образом, отдавая приоритет индексным таблицам при кэшировании и оставляя измененные страницы строк данных в памяти на некоторое время перед записью их на диск («ленивый писатель»).
Таким образом, определенная мера для базы данных MyISAM, в основном читаемой, будет заключаться в увеличении объема оперативной памяти в системе, чем размер обслуживаемой базы данных - таким образом вы можете быть уверены, что кэшируете все страницы индекса и уменьшите дорогостоящие операции ввода-вывода.
И если вы ищете сбалансированную и настраиваемую производительность с «реальными» запросами (больше, чем «SELECT * from A LIMIT 10», используемый для приложений PHP), вам определенно следует поискать другую СУБД.