Как можно снизить нагрузку и потребление памяти на веб сервер статистики (MySQL)?
Дано:
Есть сервер статистики ,который крутится на php + mysql .
Http Server: apache .
Тоисть с определенной страницы (скажем так) приходит http запрос ,из которого извлекается вся нужная инфа ( IP , SEO-попадания , время жизни и тд) ,после этого вся эта инфа записываеться в БД .
Сервер крутиться на инстансе RDS amazon'а .При добавлении новых записей ,всё это дело индексируеться по нескольки полях . Логично , что memory usage растет . Но когда записей стало уж очень много 3.2 Млрд. память закончилась , с ней и виртуальная тоже . В итоге сервер статистики упал ( освободил память с индексами) и потом опять начал "загружать" все эти индексы обратно в память.В итоге я имел где-то 2-часовой простой ,когда нельзя было доступиться на чтение или запись ( попросту очень долго не могло найти элементы без индексации ) .
Я понял,что нужно менять архитектуру и маштабировать всё это дело.Подскажите , как правильно сделать оптимизацию для моего случая(распределение и/или оптимизация).Сразу скажу ,что к сей системе отношения не имею , а столкнулся с ней через "иди ,посмотри что там".
Если тебя (заказчика) не парит аптайм, то просто добавьте на инстанс еще памяти - быстрое решение, до следующего момента
Если все же хочется сделать нормальо, то стоит для начала
- вынести субд на отдельную машину
- настроить там cgroups и oom killer
- изучить структуру проекта и сделать шардирование - не уверен как оно работает в мускуле
Вообще выносишь базу на несколько машин, предварительно разбив ее. Т.е. делаешь разветвление (правильно сказать - репликация), при том поля раскидай по этим базам, тогда тебе не придется перелопачивать по всем 3млрд записей со всеми полями сразу.
Но здесь тебе нужно будет изменить логику запросов к БД - для поиска нужного поля.
Мне кажеться , что репликация ничего не даст,ибо это инструмент по-сути резервного копирования(Master-slave,master-master)..Возможно Вы имели в виду шардирование?
ну как экстренная мера - действительно тупо нарастить память.
далее проверьте индексы - все ли нужны. Хотя 3.2 млр строк - не слабо в любом случае.
По личному опыту стоит посмотреть на параметры запросов - что-то мне подсказывает, что далеко не все 3,2 лярда строк нужны всегда. И часть( обычно - бОльшую) наверняка можно перенести в "архив".
Ну и если уж все совсем не поможет - подумайте в сторону elasticsearch.
Простой
