Используя Linux/proc/meminfo, чтобы не перегружать сервер через свопинг
Нет никакого единого ответа на масштабирующийся MySQL. Несколько общих советов:
Масштабируйтесь "по диагонали", пока Вы можете, т.е. сохранять вещи на единственном сервере MySQL, пока Вы все еще можете работать на потребительском оборудовании. Это, вероятно, означает 2 x четырехъядерных центральных процессора, 64 + RAM ГБ, 8 дисков RAID 10 - или выше. Верхний конец того, что является "потребительским оборудованием", становится быстрее каждый год.
Взгляните на презентации Brad Fitzpatrick о масштабировании LiveJournal. Они - в значительной степени классика насколько масштабирующаяся ЛАМПА идет. На странице 25 - 26 этой презентации Вы видите проблему, с которой Вы в конечном счете столкнетесь с репликацией MySQL: записи используют весь доступный диск ввод-вывод.
Считайте "Высокопроизводительный MySQL". Это - действительно хорошая книга авторов, которые видели много установок MySQL высокой загрузки.
Избегайте sharding (распространяющий данные по многим серверам MySQL) максимально долго. При запуске sharding Вы бросаете большинство преимуществ реляционных баз данных, и Вы замедляете разработку. Если необходимо сделать sharding, рассмотрите использование хранилища данных NoSQL со встроенной много моделью сервера вместо этого - fx Riak, Cassandra, HBase, MongoDB. Идеально, сделайте "функциональное разбиение" между MySQL и NoSQL, так, чтобы Вы продолжали использовать MySQL для меньших горячих данных, которые соответствуют хорошо RDBMS, и Вы используете механизм NoSQL для 'горячих' данных, к которым Вы не должны присоединяться с данными MySQL.
возможно, кластер mysql? если так, есть ли какие-либо ловушки или ограничения в переключении базы данных к ndb?
В "веб-Операциях" существует глава по MySQL Baron Schwartz. Он в значительной степени выгоняет, говорит "Нет!" к использованию MySQL Cluster / NDB в среде веб-сайта. Кавычка: ".. это не работает хорошо для соединений и запросов GROUP BY, и для веб-приложений нужны они"..
После экспериментов кажется, что активная память является хорошим индикатором.
Мы наблюдали, что когда объем свободной памяти упал до нуля, происходило очень низкое количество выгрузки страниц, поскольку неактивная память начинала откладываться. отключен (для нашей системы порядка 10–100 с в секунду). Фактическая замена приведет к увеличению количества выводимых страниц в секунду в 10–100 раз. В итоге мы выбрали 1000 страниц в секунду в качестве точки отсечки, чтобы различать вывод неактивной памяти и фактическую подкачку, влияющую на производительность.
Нам не очень повезло с доведением активной памяти до 100% от общего количества, но это в основном из-за формы работы, которую мы делаем (сначала мы ограничиваем ресурсы ЦП). Мы решили, что для нашей рабочей нагрузки все, что превышает 75% активной памяти, означает, что нам больше не следует запускать новый процесс,