Желалось бы поделиться экспериментом по применению MySQL с сбережением этих в памяти, но не на диске. Сие дозволило нам сжать load average сервера, какой благодаря операций с диском стал сильно вырастать.
В некоем плане мы употребляем MySQL с движком MyISAM под Debian Lenny. Всеобщие данные загружаются в оперативку беса на С++, а пользовательские исходные всего один раз заниматся при логине и переодически хранятся на протяжении работы юзера. Вдобавок сохраняются при логауте (или по таймауту). По причине описаной схемы select-ов очень менее, нежели update-ов (select: 24%, delete: 4%, update: 61%, insert: 11.
В принципе эта неувязка — не админская, а обусловлена не вовсе успешным подбором прибора. Очень вероятно, нам бы подошел InnoDB, который употребляет row-level locking (блокировка по записям), а не table-level locking (блокировка всей таблицы при записи) как около MyISAM. Впрочем размер данных записываемых на диск сие едвали сжало бы. Если посмотреть с другой стороны, нам SQL особенно не необходим и мы склоняемся к портированию проекта на NoSQL (к кое-каким из представителей мы давненько присматриваемся (Сassandra), а отдельные (tokyo tyrant, Berkeley DB) мы деятельно используем для логирования пользовательских усилий). Однако отметить время на перевод хранилища данных на другой движок/базу не было, благодаря чему разрешили употреблять администратор. ресурс.
С ростом численности юзеров и введением новоиспеченного контента мы встретились с проблемкой роста load average на сервере базы данных (2-3 la на восьми ядерном сервере отслеживалось только при четиреста запросах в секунду). При чем память была недогружена, также как процессор. Неувязка была в великом огромным размером записи данных на диск (повышение iowait). В некоторые моменты система приступала косноязычить и некоторые простые требования учили 2 моменты, а то и больше. В обычном режиме подобные запросы проделываются за милисекунды.
Мы чуть-чуть соптимизировали настройка MySQL (применяя как самодействующие скрипты типа mysqltuner, так и прирученную настройку), однако это подало только маленькое уменьшение перегрузки (% на 10-15). По огромной доли характеристики, отвечающие за кеширование этих, нам не то что надо, так как у нас главная перегрузка — обновление данных, а не чтение. Основа искается на SAS диске, но быстроты все одинаково не хватает. Двоичные логи ищутся на ином диске (употребляются для бекапа базы со слейва).
Убыстрить работу атриторной системы покупав полный RAID нам не то что надо из-за его высокой стоимости. Но сам сервер практически томится, если не обдумывать диски. Способности сжатия данных в памяти до записи на диск в MyISAM недостает, но и перебегать на другой движек нету покуда способности (Falcon это обязан был мочь, но его закинул Oracle после приобретения MySQL)
База у нас занимает возле 2-2.пятого Gb (в tar.gz 700mb) и мы теснее давно распробовали использовать MySQL в tmpfs (способом основанном на mylvmbackup), что дозволяло не грузить диск и адаптировать творение бекапа. По счастью мы на так давно провели очистку базы, путем прибавления куща, который устраняет престарелых юзеров, какие почти не воспользовались планом и буква разу не уплатили. Помимо этого мы почистили престарелые исходные, которые брали для статистики и ставили им жизненный цикл распорядка 2 месяцев.
В качестве скорого решения даной проблемки появилась мысль перевести основную основание на tmpfs. Что у нас вышло:
1. сервер А (военная основа куда стучатся бесы (около нас на нем 8Г оперативки ))
2. сервер Буква (другой сервер на именно этой площадке со независимой эксплуатационной (у нас 8Г из их 5Г вольно))
три. сервер В (на другой площадке заточен под бекапы абсолютно всех планов с максимум оперативки (у нас 16Г))
Так же не забываем в конфигах базы составить чтобы бин логи писались на оддельный независимый диск (знаток без них не трудится), а под перегрузкой база сможет строчить в данные логи до 1М в сек. Мы бережём эти комп.данные не более 7 суток (больше и не надо т.к. для востановления базы если что имеется слайвы)
Соответсвено стартуем базу как знаток. Сервер под самими жескими перегрузками не сходит из 1ЛА и по памяти не более 6Г. Посредственная быстрота исполнения запроса вызросла в 10-ки раз, если ранее было 0,1-0,3 сек то стало 0.1-3 мсек
Дальше на сервере Б так же поднимаем первоначальный слейв также в tmpfs здесь не стоит забывать об опциях relay-log т.к. если в слайве станет опечатка, а мастер будет доступен в эти логи он будет писать запросы которые были на мастере… В итоге это может определятся десятками гигобайт за ночь, прежде чем вы отремонтируете слайв, у нас это около 8-10 гб за час. Бекапим данную базу снапшотами ночкой 1-2 раза в день когда нагрузка на демоны мала. Подобной слейв жрет максимум 0.2-0.3 ЛА и чуток плюс к этому что тянет база.
Также на сервере В у нас подняты одновременно несколько слайвов на tmpfs под наши планы, споконо живут разом особо не загружая сервер и при всем этом бекапятся снапшотом раз в 10 мин. (если это время разложить то снапшот поделается около 3 сек (базы вес какой 2,5 гига) ну и зжатие в картотека около 6-7 мин.) и правда же при этом на сервере ЛА не привышает 2, и когда бекапы пересикаются по времени. Судя по всему кол-во бекап слейвов на одном сервере оприделяется габаритом баз и кол-вом оперативки. Бекапы храним по 10 минут — заключительные 24 часа, каждые 6 часов — храним 30 суток, любые тридцать дней — постоянно.
Далее если внезапно падает слайв Б либо В возвысить его с другым из бекапов с другово слайва не трогая мастер без особых проблем ели даже пара падают поднять не касаясь мастер 10 минут — скорость переписывания бекапов.
Если падает мастер то есть на это 2 слейва с отставанием максимум 1-2 апдейта от профессионалы (не разу ни видали чтоб Slave Delay(отставание от профессионалы) превосходил 0 сек), при этом спешное заключение проблемы это в течении 5 минут из слейва Б делать знаток… и пересоздать бесы, при исследованиях они безмятежно живут на одном сервере и не препятствуя друг дружке.
В итоге чтоб одновремено свалились 3 автомобиля на 2 различных площадках это весьма малюсенько возможно, поднять базу при другом подении сервера или площадки одолжит не более 10 минут.
Непременно настраиваем оповещалки (munin, nagios, zabix — кому что более по душе) на 2 площадках с измерением отставания слайва, возможно по смс или по мылу, у нас нагиос наблюдает за данным и при этом мунин его страхует и при этом пишет графики по каким все очень убедительно виодно что и как и кого.
Load average на серверах уменьшится осень сильно, теперь же главную нагрузку принимает процессор и память, а не диск. Вот графики которые мы сбросили при очередного переводе сервера сейчас:
Стоит отметить что после перевода базы, были так же уменьшены интервалы сохранения пользовательских данных в С++ — по этой причине число апдейтов возросло.
В общем один-единственная возможная проблема — это рост базы. Но теперь память в серваках довольно недорогая и повысить ее не составит проблем (на части машин у нас 16Gb, на части 8Gb, однако, в какой мере ми общеизвестно, можно ставить в потолке 128Gb). В любом случае кластеризацию базы никто не отменял и у нас появится возможность разпределить базу на несколько сервов с идентичной конфигурацией.
Имеется недоверие, что это не совсем верно, что ли. Но вынести базу в память было сделать намного проще, чем вводить иные базы данных / движки. Если есть какието замечания буду рад ознакомится с ними в комментариях.
В любом случае, вероятно, этот эксперимент неизвестно кому понадобиться.
InnoDB — MyISAM — Сassandra — tokyo tyrant — Berkeley DB — mysqltuner — Falcon — tmpfs — mylvmbackup —